All this talk of GGI, here's my brief $.02...
I as a user can do "kill -9 xserver" and my console is dead. This is not
good. Surely what we want is mode swapping and graphics card state
information in the kernel. We can then link a new SAK function for use in
emergencies, which can be _guarateed_ to get the console back to a useable
state.
It gets even nicer than that; if X dies horrible, its fd to (Eg.)
/dev/graph gets closed, we the kernel notice this and restore console mode
accordingly.
Does anyone disagree about that or think it isn't needed???? If so I am
_very_ interested to hear.
Once this is done, we can optionally build on this base to remove the
hackiness of a user level program needing to mess with ioports. eg. ioctls
for mapping the linear frame buffer, ioctls for queuing accelerated
command requests, etc.
People are dithering and arguing about performance; one vital point seems
to have been missed, and that is that a gfx card is supposed to deliver
performance by performing acceleration operations while the CPU gets on
with something more useful. Well under X currently it wastes my very fast
CPU by polling the damn card to see when its bitBLT request is done. A
nice queue system in the kernel can be envisaged where the kernel monitors
the gfx card interrupts and automagically loads the next request from the
queue asyncronously to the normal processor. The X-server can then sleep
waiting for some "queue purged" message from the kernel.... etc.. you get
the point.
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu