fbcon VT (mode) switching issue

fbcon VT (mode) switching issue

[Alex Stewart]

I'm still trying to sort out a few of the little "annoyance" issues still
present in the neofb driver.  One of these is the following:

If I change VT from XFree86 (using its own neomagic driver, not through
fb) to a framebuffer console, and the resolution/bitdepth of the console
screen is different from what the X server was using, the screen is not
initially repainted correctly.

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.

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

-alex




-------------------------------------------------------
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 VT (mode) switching issue

[Benjamin Herrenschmidt]

> 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

Re: fbcon VT (mode) switching issue

[Antonino A. Daplas]

On Wednesday 28 April 2004 04:59, Alex Stewart wrote:
> I'm still trying to sort out a few of the little "annoyance" issues still
> present in the neofb driver.  One of these is the following:
>
> If I change VT from XFree86 (using its own neomagic driver, not through
> fb) to a framebuffer console, and the resolution/bitdepth of the console
> screen is different from what the X server was using, the screen is not
> initially repainted correctly.
>

That's because in 2.6, it's fbcon that decides if the hardware needs to be 
touched again (by calling set_par).  This decision is based on a compare 
between info->var and the var passed to fb_check_var.  If there's none, then 
set_par is not called.  So switching from X to the original console will not 
cause a change in var, so set_par is not called (incorrectly).

There are several solutions:

1. 2.4 approach. Unconditionally call set_par in check_var. (In 2.4, drivers 
decide when to touch the hardware, not fbcon).

2. Find some kind of flag to indicate that hardware has been touched by other 
apps besides fbcon.  KD_TEXT and KD_GRAPHICS, as discussed in a previous 
thread, seems to be a good bet.

Tony





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