As someone just explained it to me: x takes a nap and lets a user
process write directly to card memory. It's a mechanism built
on top of mitshm. [I believe this was posted to debian kernel,
but of the people reading this thread, there are probably a number
who aren't reading every post.]
> > GGI would be like SVGALIB, except GGI programs could run under X as well
> > as on the console. Then again, presumably you could write an SVGALIB
> > which would let programs run under X as well?
> as ggi does?
exactly
> > For example, fbcon doesn't deal with mouse issues (focus, ...). fbcon is
> > a mechanism for stuffing pixels onto the screen.
> yes. but with x it does also make console switching in the kernel,
> doens't it?
But, as Linus pointed out, you can take the console switching out of X
without putting it in the kernel. Also, note that if you keep console
state in the file system (you don't have to flush it, necessarily, you
just want a place where it can be accessed easily), you can recover if
the last process to change the state was accidentally killed.
There may be some cards where you can't recover if the card is in the
process of being updated when a process dies. You manage this by keeping
the danger window as short as possible, and by marking the card state
as being in transit between whatever two states (are there any cards
which actually lock up if you can narrow down its state to one of two
possibilities?). If nothing else, you can issue a warning next time the
machine is rebooted.
My impression is that, if the problem can't be solved this way, it
should be thought of as a hardware problem, not a kernel problem.
-- Raul- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu