Re: [Linux-fbdev-devel] re: James's new API post

[Petr V. <VAN...@vc...>]

On 27 Nov 01 at 10:19, James Simmons wrote:
> > Do not forget that current API is atomic, with doing it in multiple
> > steps you can get nasty surprises (as resolution and resolution_virt
> > depends one on another, either changing one changes also another one,
> > or some modes are not accessible without first modifying resolution_virt),
> > besides not being atomic...
> 
> Not really. If you have a accelerated driver and a userland process open
> /dev/fb and changes the video mode the driver could be in the middle of a 
> draw operation. So teh fbdev layer lacks any really type of locking. We
> could add a spinlock or a semaphore but it is more complex then that. The
> accel engine could be busy for sometime. So we have to wait until it is 
> idle. So a clever way of locking has to be done. 

matroxfb uses spinlock around accelerator, and ioctl is serialized by
big kernel lock. But my atomicity requirement is not this. It is that
request for 'xres=1024,yres=768,depth=24,vxres=2048,vyres=100000' should
be refused completely, instead of switching to 1024x768-24 with vxres=2048,
and then realizing that vyres=100000 is incompatible with currently
installed memory. 

And when current mode is 512x384-32, and request is for
'xres=1024,yres=768,depth=8', it should switch at once, and not step by
step, saying that there is not enough memory for 1024x768-32 (because
of it went through 1024x384-32, 1024x768-32, 1024x768-8)... But
I think that there is consensus on this one.
                                                    Petr Vandrovec
                                                    van...@vc...