Re: X and VT-switching bug?

teunis (teunis@mauve.computersupportcentre.com)
Wed, 10 Dec 1997 12:32:38 -0700 (MST)


On Sun, 7 Dec 1997, Pavel Machek wrote:

> Hi!
>
> > 2) When I get to the new VT, it displays all low-white (eg 010101, binary
> > RRGGBB). Doing a "repaint screen" fixes it (Crtl-L, in most programs (bash
> > & pine, which were all I had up on VTs)). However, VT 12 was fine. (VT 12
> > has no programs running on it - syslog puts all messages out to it (fine so
> > long as I don't accidently hit Crtl-S or ScrLock)). (My diagnosis: No clue,
> > but I think it's kernel, not X.)
>
> I second that, I see similar problem with 3.3.1 on Trident VGA, and
> even on Sparc's in school.
>
> I do not know if there exists solution, but we have a problem. X
> console switching is broken by design, and I'm not sure X can help
> that, it is possible that this is linux design bug. (And while we are
> at it, shifts are not preserved correctly accross into-X switches.)

Solution (afaik - the ONLY solution):
kernel arbitrates console switch between graphical programs.

on non-x86 this isn't all that serious as most such platforms have farely
clean set/recovery methods for graphics.

on x86 this requires kernel graphics support. (there ain't no such thing
as a portable (or even compatible) graphics card on x86....)

Anyone who's been following this problem can remember this is the prime
reason GGI project was created....

Due (apparently) to signal latency and userspace/kernel transfers this
(apparently) will not be possible to fix without GGI....

So go with a workaround for now (GGI doesn't <yet> support older software
such as XFree86 - but will real soon (version 0.0.10 - it's currently in
feature-freeze to produce 0.0.9))

The workaround : Don't do that then. Switch out of X slowly, and use
"reset" et al to recover the textmode if it fubars. Don't switch rapidly
between graphics/text.... (savetextmode/restoretextmode from svgalib are
quite handy)

G'day, eh? :)
- Teunis