Messages in this thread | | | Date | Sat, 28 Mar 1998 11:40:58 +0000 (GMT) | From | Chris Evans <> | Subject | Re: GGI Project Unhappy On Linux |
| |
Hi,
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
| |