Re: Article on state of graphics drivers on BSDs

["Waitman Gobble" <uzimac%da3m0n8t3r.com@localhost>]

James K. Lowden <jklowden%schemamania.org@localhost> wrote ..
> 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

Linux has moved farther and farther away from being a "free" operating system, 
it is laden with proprietary closed-source binary blobs, which are the 
"Drivers" you are talking about. There's not much to preach about, and there's 
not much use of comparison - it's a matter of a decision whether you choose to 
use free or non-free software.




--
Waitman Gobble
San Jose California USA