From: Brian S. Julin <bri@tu...> - 2001-10-23 22:18:29
Apologies for the hit and run posting, but the thread was pointed out
to me and I could not resist dropping in to offer the KGI 2 duckets.
This conversation is eerily familiar, to the point where we've not only
had it during the initial discussion that spawned KGI, we've had it
many times when explaining KGI to newbies. It is good to see DRI
folks talking these issues over at this level of depth.
That said, I don't think DRI and linux-console are quite as close to
having everything in the kernel that KGI initially sought as Frank
points out, though he's right, 2.5 will be a vast improvement. KGI
will persist, though, for the simple reason that it isn't a
Linux-specific solution, which DRI seems to be. Add abstraction of
the OS from the graphics driver source, and modularization of chipset
subsystems and THEN maybe eventually the two would converge.
Matt's post Re: the kernel/user-library division of labor is right on
the mark, and is precisely why there is both KGI and a leightweight
LibKGI layer (which will be utilized by more bulky libraries like
LibGGI) which abstracts the delivery mechanism used by the kernel. We
are, in fact, discussing this layer now on kgi-develop. What I would
add though is that KGI takes security to the point of actually
inspecting command FIFO contents before dispatch, if hardware has
Anyway, we invite even lurkers on kgi-develop, or just peruse the
archives. If you do decide as a team to head down this path, you may
find some interesting points raised there. We may be have been lacking
in coders till recently, but never in quality thinking.