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

[James S. <jsi...@tr...>]

> 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. 

> And AFAIK Al Viro (main ioctl killer) does not require that every current
> fb_*_info field should have its own file. From his posts I understand
> that he is completely satisfied with just some text-based extensible API,
> so 
> (
> echo "mode=1024x768-16@60,outputfmt=NTSC,vxres=2048,xoffset=141" >&0
> read a
> echo $a
> ) <> /dev/fb0/control'
> would be enough for him... As there is already couple of comma separated
> list parsers in the kernel (mount options, kernel cmdline), I think that
> it is preferred format - in simplest form you write one line in, and
> get one line back...

Yeap. That is basically what he wants.