Messages in this thread | | | Date | Sat, 06 Feb 1999 19:10:42 -0500 | From | Ben Bridgwater <> | Subject | Linux Graphics Architecture |
| |
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 incompatibilities 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 XF86_KGI o That a new graphics library, libkgi, be written for use by applications
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
bennyb@ntplx.net
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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |