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

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

On Wed, 2004-04-28 at 08:33, James Simmons wrote:
> > >The whole var thing is too messy right now. Especially, the lack of a
> > >per-VT var right now makes things even more difficult
> > >  
> > >
> > I'm currently in the middle of adding a per-VT var to my kernel.  
> > They'll be in addition to the fb's current var so that when a fb using 
> > program releases the frame buffer I can restore the VT's var instead of 
> > depending on the app to do it right.  I'll post some patches when I get 
> > things working properly. 
> 
> This breaks the way linux works. It is up to the program to restore the 
> console. The same case for vgacon. The X server is the one that restores 
> the graphics hardware back to the VGA text mode. This patch would not ne 
> accepted for a stable release. 

I don't agree. While it's true that we shouldn't bother saving/restoring
the var for a KD_GRAPHICS VT which is under app control, we should do it
for fbcon controlled consoles.

Right now, it just doesn't work properly and you know it. It's actually
a regression from 2.4 and I don't think his patch will be more invasive
than the rest of the changes you have been doing lately ;)

Face it, the current fbcon resize mecanism is just broken. It cannot
work properly without full mode management in all drivers. A per-VT var
along with fbcon properly adapting it's size to the VT's var would bring
us back to 2.4 level of functionality at least, which is a good thing.

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