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/