GGI and Things

[David Ghandehari <iffy@uclink4.berkeley.edu>]

GGI, or something like it, is going to be neccessary for
linux game development.  Writing on top of X is portable among
the unices, but not where it's important (Windows).  Also, X
is REALLY not designed for high speed graphics display.  The
best it has is MIT-SHM, which seems like kind of a hack to me.

	Anyway, it seems absurd to me that there is no real display
drivers in the kernel.  I don't know about what those kernel
folks think, but the whole point of a "kernel" or OS is to
provide a hardware abstraction to the user-level programs. 
The kernel supports everything under the sun, except display
cards.  Those guys are going to realize eventually that they
need some sort of unified display interface.  If it isn't KGI,
it'll be something else (Which GGI could then be implemented
on top of, hey!).

	Also, note that small portions of GGI have been integrated
with the kernel already.  I don't know what fbcons does
specifically, the GGI web page kinda bites.

	I heard the reason that Linus, et al. do not want to include
GGI in the kernel is because GGI has it's own model for input
devices, which would replace what's in the kernel.  And I
think that's whats been holding things up, as silly as that
sounds.

	I heard of another thing on linuxgames.org, Simple
DirectMedia Layer... which basically seems to be trying to do
the same thing as GGI/GSI/etc..  I haven't looked at it at
all, it might be a good alternative.

	Another problem is that Mesa+Glide will suck until we have
some sort of display hardware access in the kernel...  Because
until then, we'll have to run any Glide or Mesa+Glide
application as root.  If Glide was written on top of KGI or
whatever, then that problem would be gone!  Or something.


	Anyway, it's all such a sordid state of affairs....

-Dave