fbcon & resize

fbcon & resize

[Benjamin Herrenschmidt]

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).

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.

Ben.




-------------------------------------------------------
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

Re: fbcon & resize

[John Zielinski]

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

Re: fbcon & resize

[Benjamin Herrenschmidt]

> >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.

Well, I'm getting complaints regulary when radeonfb refuses a mode
(via set_var) that has out of range timings instead of picking a
closer one. I'm not fully sure this is the right way to do though...

Ben.
 



-------------------------------------------------------
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

Re: fbcon & resize

[John Zielinski]

Benjamin Herrenschmidt wrote:

>Well, I'm getting complaints regulary when radeonfb refuses a mode
>(via set_var) that has out of range timings instead of picking a
>closer one. I'm not fully sure this is the right way to do though...
>  
>

Out of range for the video card or the monitor?  If it's the monitor 
then provide a mechanism for updating the monitor information and that 
solves that problem.  I've seen monitors where the edid had "safe" 
values while the tech specs for the monitor had a larger range.

If it's the hardware and we go the user customizable modedb route then 
that would be part of the customization process.  If a particular mode 
didn't work then root can tweak the modelist so that it works on their 
hardware.  Regular users would then just be able to select from root's 
customized list.  As a bonus, regular users wouldn't be able to push the 
monitor beyone the limits set by root.

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