[ On , July 17, 2001 at 10:09:31 (-0400), Nathan J. Williams wrote: ]
> Subject: Re: Why not track our xsrc with X11R6.6 from X.org?
>
> The reason I suspect XFree86 took the approach that they did was that
> they run on several operating systems (believe it or not!) that they
> don't control, and requiring priveleged access and performing *very*
> low-level bus scans was something that they could do, whereas asking
> multiple OS vendors to implement a new, common, interface is a
> tedious, panful, and often fruitless battle.

IMNSHO that's not even close to being reason enough.  It should be
trivial for XFreee folks to provide at least kernel drivers for Linux
for the cards they support, if not an even more generic driver templates
that would be easy to port to any OS (including any non-free OS).  They
have to write some kind of hardware control code anyway, and with a
framework for making that code "pluggable" in the Xserver they've got to
have an API designed for it already too.  Seems to me that it's just a
matter of drawing the lines a bit differently (and of course that
infinitely unmeasurable Small Matter Of Programming ;-).

They (i.e. XFree.org) just don't seem to have any incentive to design a
clean and elegant graphics card device driver interface.  I hate to say
it but that seems to be generally true over other application domains in
so much of the PC-centric world, even in much of the Linux community
too!

> It's related to the above bit about a bazillion different cards; the
> kernel would have to know about the exact register set and semantics
> of DMA for each of them.

That's ever more reason to have the hardware drivers locked firmly in
the kernel and to not ever give any bit of userland direct control over
such things as DMA operations!

It seems to me though that there's enough of a common industry standard
for graphics that a basic framebuffer driver could be written to at
least get the majority of cards into usable shape.  From there it should
just be a matter of taking the XFree code for specific cards and chips
and creating special drivers as desired.

Maybe if someone were to add /dev/fb or similar support to vga(4) or
similar and then hack Xsun or similar (pick the workstation model of
your choice; alpha, dec, and hp seem like other good candidates) to
drive it we'd at least have a proof of concept that could get people
interested in building a better framework for X11 on PCs (as well as
having an implementation on which performance studies could be done).
Has anyone done anything like this in the past?  I don't know if I could
do it (though I suppose I could if I could find the time!).

> It would also require crossing the protection
> boundary for every such operation, which wouldn't just be sub-optimal
> performance; it would be downright abysmal.

It would?  Why?  What do you call "abysmal"?  Is this only an i386
problem?

My little SS1+ (25MHz sun4c) with 25MHz s-bus attached bwtwo framebuffer
has no problem pushing 1600x1200 bits out from the Xserver to the screen
using a proper /dev/fb.  Modern PCs are almost an order of magnitude
faster in *every* way, and many orders of magnitude faster in some ways;
which of course means there's ample room to go from 1-bit to many more
bits per pixel.  Why can't PCs do good X11 with clean and elegant device
driver APIs?  Or can they and we just don't know because XFree's "market
dominance" has effectively prevented us from learning how?

> You might think so, but history disagrees. Unfortunately, like many
> other power tools, modern graphics cards are built so that the sharp
> edges are the useful bits.

But we're  not talking about high-power graphics -- we're talking about
the basic stuff necessary to drive a GUI and offer simple support for
canned animations and such.  High-power graphics users should know
better than to even try to use X11!  Has X11 really truly become the
only model for graphics in the unix and unix-like arena?

I can do almost everything I want with X11 over a 10mb/s half-duplex
ethernet, never mind even an 8-bit ISA bus.  Even multi-media stuff
works very very well over a 100mb/s FDX ethernet.  Now admittedly that's
with a fairly high-level graphics "accellerator" (i.e. an Xserver)
running on the other end of the network right next to the graphics
hardware in my NCD, but still in this case there's a lot more between
the application and the monitor than a double protection boundary
crossing for every operation.....

With PCI or AGP to move the bits real fast, and a modern CPU to figure
out what bits to move, there shouldn't be any excuse for not designing
the Xserver interface "right".  With such power and speed any X11 user
should be able to push bits to the card at a rate an order of magnitude
faster than even a 1600x1200 70Hz non-interlaced monitor can accept
(even with 32-bit pixels)!  Perhaps I'm showing my ignorance of some of
the issues involved here, but it seems to me that if you can do any of
the graphics operations in the card at all then you've probably got lots
and lots of CPU and bus bandwidth left to burn on other fun stuff (but
of course you should really be doing the CPU intensive bits on some
separate CPU(s) and bus anyway, right?).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>