Kernel support for graphics cards

olafBuddenhagen at gmx.net olafBuddenhagen at gmx.net
Tue Feb 7 06:25:50 PST 2006


Hi,

> > There is a project, Kernel Graphics Interface, under way, though
> > very slowly, at http://kgi-wip.sourceforge.net/
> 
> Totally irrelevant project though, didn't engage any support from the
> people who matter, kernel developers and X developers... doomed to
> failure from the start..

Indeed, the KGI project has had a very bad start. But that just means
there is plenty room for improvement ;-)

I haven't been around at that time, so I don't know what went wrong
originally. I guess it doesn't really matter now -- let's look forward
instead.

Today, the situation is quite different, and the people in the KGI
project are as well. We hope we can do it better this time: There were
some interesting discussions recently, and it seems all of those around
today are quite open to new ideas; we want to get some serious dialog
going with "the people who matter". That's why I'm joining in this
conversation here.

(In fact, all work done on KGI in the past years was in a fork of the
original KGI -- that's why kgi-wip. We even consider using a different
name, to reflect the fact that it's quite a different project now, and
also to avoid some of the confusion about our goals.)

It doesn't really matter whether the new architecture will be a
continuation of KGI, or a completely new project; all we care about is a
sound design. The reason why I suggest considering the existing GGI/KGI
project as a starting point, is that it has a complete stack basically
working: A couple of system independant board-specific hardware access
driver modules at the bottom (presently only older stuff though); the
system specific hooks for some kernels (Linux and FreeBSD presently); a
userspace library (libggi) wrapping it up in hardware independant
abstract graphic operations; and an X server running on top of that.
(XGGI -- which is just the normal X.org server with the builtin hardware
initialization and drivers replaced by libggi calls.)

Even if it turns out that much of the code might need to be replaced
ultimately due to possible flaws in the existing implementation and/or
design, starting from a basically working system seems easier than doing
it all from scratch.

Even more importantly, the KGI project has gathered a group of people
willing to work on such stuff, and who have made quite a lot of
considerations about good kernel-supported graphics driver
architectures. This shouldn't go to waste.

So what do you think? I hope for some profitable discussion :-)

I'll be at FOSDEM (and maybe a few other GGI/KGI developers too), so we
can talk there as well. If there is interest, I can also give a
presentation about the ideas behind GGI/KGI there, to create a common
knowledge base for further considerations.

-antrik-



More information about the xorg mailing list