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/