Linux Graphics Architecture (format fixed)

Ben Bridgwater (
Sat, 06 Feb 1999 19:17:51 -0500

A quick survey of the existing Linux Graphics (de facto) Architecture
reveals a mess of applications, libraries, and most recently the
framebuffer device, all contending for the graphics hardware. The major
opponents seems to be: XFree86, /dev/fb, KGI (Kernel Graphics Interface
- GGI project) and SVGALib.

The current "solutions" to this hardware contention are at best short
term solutions such as XFree DGA, XF86_FBDev, "framebuffer aware"
XF86_SVGA, GGI-over-anything and SVGALib-over-GGI, and the more
interesting X-over-GGI/KGI (XGGI).

The real solution to eliminating contention and incompatability amongst
these applications and libraries is a device driver interface to the
graphics hardware. This would have many benefits:

o Eliminate hardware contention and X/framebuffer/application
o Provide portable direct-to-hardware accelerated graphics, both within
and outside of of X
o Fully support new graphics cards via device driver implementation
o Eliminate hardware driver implementation redundancy

This is hopefully all rather obvious and non-contentious. The
interesting part is how to get there from where we are now with the
minimum of effort. I believe that the GGI project already contains
components that can be repackaged to provide what's needed.

I propose the following:

o Linux standardizes on a graphics device driver interface
o The driver interface, /dev/kgi, be based on the existing KGI drivers
o The XGGI X-server bypasses GGI and gets merged back into XFree86 as
o That a new graphics library, libkgi, be written for use by

The graphics library's architectural purpose would be to shield
applications from differing capabilities of /dev/kgi drivers for
differing graphics hardware. The idea would be that /dev/kgi drivers
only *need* implement some minimum core framebuffer like functionality,
and that device capability flags indicate whether higher level features
are implemented. Where a feature is not implemented, the graphics
library itself would implement it in terms of lower level features.

This graphics library would therefore allow a single accelerated
device-ignorant XF86_KGI (or any other graphics application), to run on
top of graphics hardware that only supported a minimal "framebuffer
level" /dev/kgi. This is a much more general solution than XF86_FBDev.
Additionally, if someone wanted to extend the /dev/kgi interface to
support some new hardware acceleration feature, then this could be made
portable via also providing a libkgi implementation.

It seems that we could have a very smooth transition to this
architecture. We would keep /dev/fb, and would have a generic fb_kgi
/dev/kgi driver that would just implement minimum framebuffer level
functionality via pass-thru to /dev/fb. The initial libkgi would just
pass-thru to /dev/kgi. Initially XF86_FBDev would still be needed by
people without a /dev/kgi KGI driver for their graphics card, but as
soon as libkgi provided missing capability implementation then
*everyone* could use the single XF86_KGI.

Now the bad news! I don't have time to implement this myself. It does
seem however that the initial work could be assumed by the GGI project
*if* there are people there who are interested. Maybe there are other
people who would also be interested in what would be quite a glamorous
and high-profile project, particularly if Linus were to bless it.

Of course the first step is to get some feedback, to see if the
consensus is that this is a desirable way to go forward...

Ben Bridgwater

P.S. Please CC: any replies to myself.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at