Messages in this thread | | | Date | Fri, 27 Mar 1998 12:42:25 +0000 | From | Fredrik Sjoholm <> | Subject | Re: GGI Project Unhappy On Linux |
| |
It seems to me that this is turning into a GGI versus X debate. If the idea is to replace X with GGI, then i'd be worried, but isn't the whole idea to create a uniform graphics device driver interface, in the kernel ?
X would be implemented on top of GGI, and all device driver efforts could be concentrated on writing KGI compliant drivers, which would instantly benefit the X server, OpenGL and any other APIs/applications that now has it's own limited set of drivers. SGI uses this approach, with a /dev/opengl which is used by the X server for rendering.
This way, the network tarnsparency of X (which is very important) would be unaltered. Only the actual X server running on a KGI capable machine would use the GGI layer for physical rendering. View it as a generalized extension of XAA, that isn't specific to the XFree86 server. Somebody wants to write a game or similair application, use the GGI layer, of course this would mean the program has to run on the local machine, but how many of us play quake with an exported X display anyway ?
The kernel driver should be able to arbitrate access, so X could still be running while running a raw GGI application, and allow switching in a virtual-console fashion. GGI should be great news to everybody working on re-implementation of other APIs, such as Mesa. By nailing the specifications for the kernel GGI driver down hard, we might even be able to get hw vendors to provide drivers (and let them provide it as .o kernel modules if they must). I agree with Linus on the specifications/goals issue, there has to be a very elaborate effort to create flexible specs that will also cover exotic hardware we might see in the future, such as hardware-nurbs or special purpose graphics cpus.
/Fredrik - Netspeak Corp.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |