> You're right. Honestly I had never thought to do this before, and now
> that I think about it there's really no reason the X server could or
> should restore you to the console in this situation anyway.
> It crashed bigtime when I did this.
Or any svgalib app, etc.
>
> Just so I understand this better, what exactly would have to go in the
> kernel for it to be able to restore text mode in this sort of situation,
> or perhaps if it is given some kind of keyboard signal.
keyboard signal is not really acceptable. One pride of Linux was always
that it does things right, if at all possible.
At least, a hook that can be programmed by the user level app to restore
text mode had to go. Let a bit think about this. (One thing to assume is
that gfx cards are nasty, and if any one given nastyness have not yet been
put in silicon, than you may bet it will be done sometime.)
*) So we have now a list of ioports, values and wait times in the kernel.
Now consider that there are some cards where a simple wait is not enough,
where you have to wait and poll till the accel is idle.
*) So we add input statments, etc. into the spec. With anything broken
you are going get something Turing complete :(
Another caveat: The restorating sequence depends bigtime upon the
activity of gfx driver and it can't be probed or waited out with simple
general port inputs (consider that there a different status register
for different stuff, and touching the wrong one hangs the bus).
*) Ok, we add also a virtual calling table with all needed ops beginning
with putpixel, ending with putimage into the kernel.
Two problems here: kernel bloat, and to many user<->kernel switches.
*) Let's a add a userlevel library, and let the kernel interface
support only the functions deemed as needed.
Ok, still to many switches, especially if you not only want to add
ops that are absolutly needed for stability, but also ones that are from
the acceleration department.
*) Put some sharedmemory protocol between them, so request can be queued
from userspace and vicaversa.
Nice, when well done, this elimenates the overhead of having a kernel
level driver, and by having a userlevel library that handles the
higherlevel ops automatically if they are not supported by the hardware or
kernel driver, the software gets nicer to write, and at the same time
get's most acceleration automagically.
*) And we need to change this kbd handling too: The kernel should detect
console switching and perform itself, as else a hung X (and this
happens, and as Murphy has told us, especially often when you explain
a converting Windows user about Linux stability :( ) still blocks the
console. With kernel level console switching, you just switch away,
login, and do a kill XserverPid ; sleep 5 ; kill -9 XserverPid.
*) Ok, so let's start implement it.
Hmmm, perhaps we should do a survey of existing projects before?
Hmmm. KGI seems to be a implementation :)
But GGI has taken to many PR bullets, and will probably never included
in the mainstream kernel, based not on technical merit, but upon name
recognition :(
So perhaps we should start to implement it anew with a new name? *wonder*
[fbcon as I understand it, ends at an earlier time: No standardized
support for accel stuff, etc.]
*) An afterthought: Perhaps we should make our library more portable?
Ok, libGGI runs on top of X11, svgalib, etc. So you can use
KGI on systems where the drivers are ok, and on others you can still
run the new game on X11 :) (And support for certain GatesOfHell APIs
as lowlevel implementation is coming: That could become for some
ppl the game graphics API :) )
Andreas
P.S.: I'm not associated with GGI in any way, but looking at it, it
seems the only project, that deals with most shortcomings of the
current gfx support in Linux. Be it stability, security, or acceleration.
(Having a ``own'' standard for gfx api helps also for example with
3D acceleration. 3D accel could be added to the drivers and libGGI, and
if some X ppl see that the lowlevel driver support the API on all
cards either in software or hardware, then they will probably think
about implementing OpenGL or something like this as an Server extension
:), and at least one can see the program in full speed at a console.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu