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

On Fri, 24 Jan 2003, James Simmons wrote:

quoted

quoted

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?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com