Re: [PATCH] radeonfb(): memmove() fix -- this one works ;-)

[John Zielinski <grim@undead.cc>]

Geert Uytterhoeven wrote:

>So I cannot have a mode that's not in modedb, since it won't survive switching
>VTs.
>
>  
>
It would be possible.  Let's say that the future fbset can modify the 
kernels modedb and that the vt driver can also swtich to a mode by an 
alias string.  All fbset would have to do is create a new modedb entry 
called "vt02_temp_mode" and then tell the vt to switch VT 2 to 
"vt02_temp_mode".  The vt driver remembers that VT 2 is now set to 
"vt02_temp_mode" (via a pointer or a numeric modedb index or something) 
so when you switch to back to VT 2 you get your custom mode again.

The VT's vc_data struct would have an extra pointer/index variable.  If 
it's non zero it uses that to reference the proper modedb entry.  If 
it's zero then it uses it's x,y,Hz,bpp variables to reference the proper 
modedb.  This way you could also have multiple modes with the same 
x,y,Hz,bpp but different timing and sync options.

This approach would also get rid of the need for a special mode set api 
for fbset to tweak the current mode timing.  It would just use the 
standard kernel modedb editing API.

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