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