You still want to go the way of DOS. I remember downloading a JPG
veiwer called QPEG, and it had video drivers bundled with it.
Sounds a little like X, eh?
then again, use the right tool for the right job, and don't let
principles get in the way of practicalities.
Is the hassle of implementing full-blown, accelerated, concurrent
access, graphics drivers in kernel worth the effort?
how many people really need to have several processes
concurrently writing to the graphics hardware? As it stands i can
think of only two: X and a direct render graphics layer - which
would have to co-operate with each other to be of practical use
anyway.
[X is the de facto UNIX graphics standard for the foreseeable
future, for better of worse. {better imho}.]
If it was for a single platform with a reasonably limited range
of graphics hardware - then maybe yes. But for an OS that covers
so many platforms? and those platforms cover how many weird and
wonderful different graphics hardware?
And which cards are capable of what? How do you present a uniform
interface? How would a uniform, rich, in-kernel, 3d & graphics
implementation run on my P133 with Trident TGUI graphics card?
Keep it too simple and you're wasting the more exotic hardware.
So perhaps it's best to let the kernel stick to a limited
knowledge of the graphics hardware, so that it can always
clean-up if needs be. And let the higher level stuff sort it out
between themselves as to what they want to do.
If needs be, some basic functions can always be migrated from the
higher level into the kernel. but let X and co worry about
concurrency and arbitration and things like that. The kernel has
enough of that kind of stuff to worry about already.
Eg, DEC faced this issue when they tried to go head to head with
SGI with their PowerStorm graphics card. Their solution was to
implement direct rendering with the X server handling concurrency
issues. X can then arbitrate between multiple X protocol and
direct render clients, as it sees fit. Only that with direct
render clients the X server doesn't need to do any rendering
work, the direct render client and the X server just need to set
things up via the X protocol.
X is already an arbitrator, why reinvent the wheel when it can
just be extended to arbitrate between more types of clients?
(Direct render clients can be anything by the way. Doesn't have
to be OpenGL.)
This way, we keep a standard and already uniform graphical
interface, X. And we can write extensions to it to support a
uniform high-performance graphics layer, "direct render" for more
advanced graphics cards. And we don't clutter the kernel with
highly complicated code that could run in user-space.
[eg: why can't the kernel do sound mixing? - so that 2 or more
processes could write to /dev/dsp concurrently and produce a real
mixed sound? the implementation itself exists.....]
regards,
Paul Jakma.
(perhaps this thread should be on another list.).
-- Paul Jakma paul@clubi.ie PGP5 key: http://www.clubi.ie/publickey.txt ------------------------------------------- Fortune:[FORTRAN] will persist for some time -- probably for at least the next decade. -- T. Cheatham
- 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/