Re: LCD scaling type

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Sat, 2003-01-11 at 12:35, Antonino Daplas wrote:
> If you only need to do is turn something on or off, assigning it an
> ioctl may be too much.  The "feature" can be anything, not just a mode
> setting. Also, you will have fbdev drivers writing their own ioctls just
> for these "little" features, and each will need to have its own utility
> written specifically for the driver.  If you have an
> fb_var_screeninfo.tweaks field, you can simply use fbset, and it can be
> used for all drivers.  One can even collect all possible 'hardware'
> tweaks and create a general fb tweaks utility just by using fbset.
> 
> Of course, if the feature requires something more than just turning a
> switch on and off, then an ioctl is more practical.

Hrm... I think this is going too far for var_screeninfo. However,
we do have need for such "tunable" settings, that can be
brightness/contrast/backlight kind of stuff, geometry on some i2c-driven
monitors (iMacs typically) etc...

It may be interesting to think about an API where the fbdev (or the
monitor layer, which is something we currently lack that should probably
sit on top of fbdev) to expose the available "settings" and have std
ioctls to get/set their values. A bit like sound mixer settings work
today maybe.

For my immediate need, however, I still think turning one of the
reserved fields of var_screeninfo into a "mode_flags" would be useful,
we can already define a FB_MFLAG_LCD_FULLSCALE flag that would ask the
driver to not bother keeping aspect ratio (the idea here is that keeping
aspect ratio is the default, so 0, even if that's nor really working yet
in radeonfb or aty128fb).
 

-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>


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