> Hi!
>
> > > 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.
>
> Hmm, really?
Yep. Software-handled console switch is too prone to race conditions
(which is what causes X to fubar occasionally). The situation would
probably be a lot better though if x86 graphics hardware was actually
easily capable of state-recovery (it isn't - and under some conditions
the only state recovery is power-cycle (not reset button)).
FWIW x86 hardware is broken by design (anything capable of VGA is broken.
As is CGA, EGA, hercules-monochrome, ...). x86 graphics hardware is _NOT_
designed for secure and/or multiuser environments.
I don't know how things are on other platforms though - other than
apparently neither Sun nor SGI have this problem.
> > Due (apparently) to signal latency and userspace/kernel transfers this
> > (apparently) will not be possible to fix without GGI....
>
> Ok. Imagine this: When switch from X is attempted, kernel sends signal
> to X. X's does all cleanup it needs to switch into textmode, and when
> it is done (X knows when it is done) it enables console switching,
> causing switch to be actually done.
That's exactly how it works now.
> And now the way back: When switch into X is attempted, kernel disables
> console switching (needs to be done by kernel in order not to create
> races) and then signals X.
That's not how it's done now - the console switches back to X, X disables
the console, then recovers graphic mode. (can you see a race condition?
You're right if you say it's between X switching back and locking the
console....)
What signals? SIGTSTP and the like?
is there anyway to prevent usermode software from sending these signals?
> I believe bug in current system is thta kernel does not do implicit
> console switch disable on console switch.
And it wouldn't make sense. There's no guarantee the program it switches
to can recover anyways. Would be handy for locking people out of their
own boxes if there's a hole here....
... perhaps for suid-only programs (like X).
> > 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)
>
> Hmmmm. Inacceptable. Better workaround might be rm -rf `find . -name
> "*X*"` ;-).
That's a solution, but building a system capable of recovering hardware
problems is better.
Not everyone needs X (I avoid it myself most of the time) but graphics
are a major weakness in linux. This is _HARDWARE_ problems mostly.
(okay - so only 15-20% of the world's population can't use linux without
graphics in their native language... that's enough, right?)
[I'm off on a tangent here...]
G'day, eh? :)
- Teunis