Re: Article on state of graphics drivers on BSDs

["James K. Lowden" <jklowden%schemamania.org@localhost>]

On Wed, 13 Feb 2013 15:33:25 +1100
Martin <martin.kelly4000%gmail.com@localhost> wrote:

> The first problem is an obvious given, that the kernel API's of each
> system are going to be different unless direct they are forked and
> have direct compatibility with each other. 

Or maybe it's not obvious, because that's not how I would characterize
the problem.  

The problem is not that kernels differ.  The problem is that X is no
longer portable.  It no longer provides a machine-independent
layer for the driver.  There is no reason, theoretically, that a
graphics driver should be tied to the kernel, but that's what's
happened.  

> So any suggestion of making head-way to unify kernel api's across all
> systems is out of the question.

Linux and Apple are surely the biggest X users these days, and probably
contribute the Lion's share (no pun intended) of the code.  Given that
Apple is doing its own thing with Xquartz, there's essentially no
motivation among the current developers to maintain a MI API.  

If you wade into these waters, you will find them swift and murky.
From the point of view of the Linux-only, Linux-always folks, OS
independence is pure overhead -- both for the developer and for the
machine -- whose only purpose is to facilitate portability to an alien
system.  The problem, you see, is not technical.  

The history of bridging the Linux-BSD divide is not encouraging.  I can
think of a few APIs the BSDs adopted from Linux (e.g. iconv and PAM,
IIRC) but none in the last 10 years, say, that Linux adopted from
BSD.  (Perhaps others have better memories?)  

If you want to try anyway, your mission becomes one of persuasion: to
convince those involved that a simpler API would facilitate driver
development *and* kernel development by decoupling them.  Surely some
would accept that argument on its face; others might if you demonstrate
(in English, not C) that drivers written to your API would be easier to
implement with no appreciable speed degradation.  

Perhaps the only chance of success is radical departure.  Plan 9 can be
a source of inspiration.  It supports graphics through "8½" which serves
a device, /dev/bitblt. (Beware of the trap that these preclude using
shared memory.  The device is an abstraction, not an implementation.)
Cf. http://plan9.bell-labs.com/sys/doc/8½/8½.html.  

Defining the interface in terms of I/O would naturally restrict it to
purely graphical requirements, leaving to the kernel developers the
choice of how those requirements are met by the kernel.  

HTH.

--jkl