Re: fbcon & resize

Benjamin Herrenschmidt wrote:

I still think the whole resize stuff is broken, despite your latest
changes. The main problem is blindly using the modedb and not whatever
mode list is provided by the driver (but we need an interface for that).

 

How about making the modedb more like a real database.  It would contain 
the built in standard, vesa, and macmodes lists as well as lists 
provided by the driver and custom lists from the user.  A temp list 
would contain any tweaked modes created by a tweak utility (fbset, etc) 
and also for modes for displays that can take any resolution.  The mode 
displayed on each VT and modes set by applications would just be 
pointers into the database so checking if a mode switch would be very easy.

And it need not be limited to geometries but could also include bit 
formats, supported virtual resolutions, etc.

This is the current approach I'm taking in my own project.

We need to cleanup and generalize a function for matching a mode to
the mode list to be used by drivers for validation in check_var() too,
my current algorithm in radeonfb is a bit broken for CRTs for example,
and has the nasty habit of refusing modes rather than "adapting" them.
 

I'm curious as to what you mean by "adapting" them.

John




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click