Re: [ANNOUNCE]: VM86 Daemon

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

> Actually, using a combination of functions that will be available in
> fbmon.c, the fbdev driver will become independent from userland, such as
> /etc/fb.modes. User-entered timings are still preferred thoug, and only
> when the timings are invalid that the driver will select the nearest
> mode from the database, or calculate one for it.  A theoretical sequence
> will be like this:
> 
> 1. driver rounds off values in var
> 2. timings in var is validated using fb_validate_mode()
> 3. if timings are valid, driver accepts the new timings
> 4. if timings are invalid, it checks if monitor is GTF capable.
> 5. if monitor is GTF capable, it calls fb_get_mode(). 
> 6. if monitor is not GTF capable, it calls fb_find_mode(), passing the
> database created from fb_create_modedb().
> 
> Fbdev needs this independence from userland in order for stty to work,
> primarily, and to make it easier for the user, secondarily.
> 
> You're correct though that it's a good idea to pass a list of modelines
> to userland.  However, the filtering is best done by the driver because
> it has the best knowledge on the limits/capabilities of the chipset.

How do you fit in this picture using scaled modes ? Typically, LCDs
only really using their "native" mode, but any lower-sized mode can
be obtained using the scaler (I've just fixed bugs in radeonfb for
that btw). In this case, what list do we "propose" to userland ?
A list of 'standard' well known modes in addition to the native one ?

Ben.



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/