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

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

> So if a fb program restores the mode properly then we should do nothing 
> but if it doesn't either because of a bad programming or an unexpected 
> termination then we should reset the mode to what the user has selected 
> for their console.

Which is why I've been adding calls from the VT subsystem to the console
when a program enter/leaves KD_GRAPHICS (via the blank() callback to which
I added a parameter) so fbcon can reprogram the mode & the engine. That
fixed various problems with XFree not cleaning things properly.

The proper policy here is simple. Whoever gets control of a console is
responsible for setting it up the way he needs. When leaving, it is not
requires to restore the mode it got on entry, but it should try at least
to leave the card in a sane state (accel engine not running). Though we
should probably add more security there to the fbdev's so they actually
make sure of that since it's always possible to kill a userland program
without letting it cleanup.

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