> Ocasionaly when I have been in X for a while (eg leave it in X overnight),
> 1) Switching to a different VT (Crtl-Alt-Fn) takes a long time (several
> seconds), and there is a bit of disk-chugging. (My diagnosis: Not a bug.
> The VT-switching code in X is swaped out.)
> 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.)
To exploit: Take machine with 16Meg of RAM, launch X, launch make -j,
switch between text console and X as many times as you can, use
typeahead.
I got mine console into state where Xs were displayed, but normal text
console was active, because Alt-FX switching switched small piece of
graphics inside the screen - probably because linux was thinking its
in text mode.
What I *think* happened. (I'm not X hacker. I'm kernel hacker. If
there's a Xfree hacker around here, contact me, and we may be able to
fix it.) I switch into X. Then I switched back. X got signal and
turned keyboard into raw mode so I could not switch back. Shame, they
were too late and I already *was* away. And now X's started painting
over this emacs :-(.
Pavel
> ---
(Please, use
-- as begining of your signature. Thanx)
-- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).