Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

[Antonino D. <ad...@po...>]

On Sat, 2003-01-25 at 17:00, Geert Uytterhoeven wrote:
> On Fri, 24 Jan 2003, James Simmons wrote:
> > > > The only problem right now is how do you pass the monitor info to the
> > > > driver?  The best way is to parse the EDID block and use I2C/DDC. 
> > > > Personally, I think passing the monitor info as a boot/module option is
> > > > the simplest and safest method.
> > > 
> > > Through sysfs? echo MY_MONITOR_LIMITS > /proc/...?
> > > 
> > > Since ioctls are considered evil these days, changing the resolution etc. could
> > > work in a similar way as well.
> > 
> > Can you do this with sysfs? This is what I have been waiting for!!! The 
> > proc thing is don't care for tho.
> 
> Yes, you can create a fbdev filesystem, which shows frame buffers and
> information about them. By changing the contents of those virtual files (e.g. a
> file that corresponds to struct fb_var_screeninfo), you can change the video
> mode.  This can also solve the burden of maintaining backwards compatibility in
> struct fb_var_screeninfo. You want a new field? Just add a new virtual file to
> the filesystem.
> 
> One thing I'm still wondering about is how to keep things synchronized. You
> don't want to put all fields of struct fb_var_screeninfo in one file, you want
> separate files for resolution, timings, .... But in the end you usually want to
> change a video mode by changing all parameters at once, so you want the changes
> to the different virtual files to be synchronized. Perhaps some lock file?
> 

>From what I understand about sysfs, you can only have one type per file,
so each field will have to be in separate files.  To synchronize, we can
perhaps use a file ('sync', 'lock', 'update' or whatever) which is
similar in function to fb_var_screeninfo.activate. Only when the user
writes to this file that the new settings are synchronized and we call
fb_set_var() or whatever.

How do you think sysfs support will be written?  Will this mean that the
framebuffer system has to register its own kobject as the top level
entry in sysfs, no?  This would also mean that we need something similar
for the console subsystem if it has to support additional features, ie
rotation?

Tony