Re: Some questions

From: Thomas Winischhofer <thomas@winischhofer.net>
To: Antonino Daplas <adaplas@pol.net>
Cc: James Simmons <jsimmons@infradead.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux Fbdev development list
	<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: Some questions
Date: Tue, 11 Mar 2003 21:56:58 +0100	[thread overview]
Message-ID: <3E6E4D9A.7060003@winischhofer.net> (raw)
In-Reply-To: 1047407816.1013.182.camel@localhost.localdomain

Antonino Daplas wrote:
> Well, you have info->currcon, fg_console etc...  No mapping is done,
> fbcon will just keep track of the tty's it's currently switched to (vt.c
> does it, and so does fbcon_switch), and fbcon will just look if the vc
> has a valid PID (which means a process installed its own vc) and
> therefore not trust it to completely preserve the graphics state.
> 
> Note that X does something like this to protect itself.  When switch
> from console to X, it refreshes its own registers.

Which does not neccessarily mean that the framebuffer driver must do the 
same, resulting in two mode switches. Not really healthy for LCD panels.

The current implementation (as with James' latest patch) does not show 
any problems with this, even when switching back to a console with a 
different resolution than the one X was started under. Then again, maybe 
that's just due to a all too well working sis driver combination :)

> I think you may need some support for this.  Several have already
> reported that switching from X to a console results in a corrupted
> display which can be cleared by doing an fbset. 
> 
> The choices are:
> 
> 1. refresh the registers at every switch - slowest but guarantees
> hardware state is always preserved 

Bad. Takes long time, especially on LCD displays which always need a 
little delay for backlight and sync stability reasons.

> 2. do not refresh unless var changed - fasted but can result in
> corruption/crash if registers were changed behind the back of fbdev

I think one can rely on tidyness of applications changing the registers. 
Like X does.

> 3. selective refresh - do not refresh if switching between "trusted"
> consoles, refresh if switching from "untrusted" consoles.
> 
> 4. Find a method to detect if the registers were changed behind the back
> of fbdev.

Very time taking on some hardware (such as ... erm... SiS) with more 
than 100 registers for graphic mode setup.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net

-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en