> You write:
> | I simply think that *all* graphics within Linux should go through a
> | device driver to avoid hardware contention. If that is done, then
> | there is no reason why an X client can't "direct render" using
> | whatever API it chooses - if the X server and all graphics APIs go
> | through the device driver, then it'll be fine.
>
> I don't see how this follows. It appears to require an API which
> allows not just sharing of the graphics hardware between processes on
> different virtual consoles, only one of which is active and rendering at
> a time, but sharing of the graphics hardware between things on the same
> screen, with a mechanism for allocating, moving, partially clipping and
> obscuring, etc rendering areas.
>
> This doesn't sound simple.
I'm talking a very low level driver that simply provides safe serialized access
to the hardware. Clipping belongs in Xlib or wherever it's needed. Of course if
the hardware provides clipping, then it should go in the driver, and it would be
up to the user mode libraries/applications such as Xlib to use it if it exists.
Of course, you could move the emulate-if-missing code out of Xlib into a non-X
library as I suggested, but simply adopting device drivers to serialize hardware
access doesn't force you to do that.
Ben
Please CC: bennyb@ntplx.net
-
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/