Re: fbcon VT (mode) switching issue

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

> This appears to be due to the fact that when changing VTs, set_par (which
> is where neofb changes the hardware video mode) isn't called until
> sometime after the fbcon code uses imageblit to transfer the console text
> to the screen.  The result is that the accelerated imageblit is done with
> the hardware still set to the old screen resolution/depth, and thus the
> neomagic chip writes the data to memory in a form appropriate for the old
> mode, not the new one that we're switching to.

That's weird, we should get a call to fbcon_blank() triggering an
FB_ACTIVATE_FORCE call before anything is drawn (on the switch from
KD_GRAPHICS to KD_TEXT more specifically).

> I've tried to figure out how this whole process works and what the best
> fix for this problem is, but to be honest, trying to follow some of the
> code paths in the framebuffer console system is rather like trying to
> follow Brer Rabbit through the briar patch..  I could use the help of
> somebody a bit more familiar with this part of things, I think.
> 
> I have determined that adding a call to set_par at the beginning of
> fbcon_switch does fix the problem.  Of course it also ends up calling
> set_par twice during the overall switching procedure (with noticeable
> flicker), and I'm not really sure this is the right place to put it
> anyway, so I wanted to get people's opinion as to what the right fix is..

That's not the right fix.

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