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/