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 bugs. 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. l8r -- Brian _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
