On Mon, Jul 16, 2001 at 06:30:55PM -0400, Greg A. Woods wrote:

> I'm not a graphics programmer, and I've only ever written a small
> handful of graphics card drivers (way back in the Xenix/286 days), but
> it seems to me that XFree86 *is* _very_ PC-centric.

That's true, though the main reason for that is because X was previously
heavily proprietary, and difficult to make widely available.  The PC
was the platform that suffered the most.

> Why does XFree86 even have to know about the bus or whatever?  

Why does Xsun? The workstation X servers are even worse in this regard.

> That seems like a very bad design and a nasty violation of the normal device
> driver layering model.  

Hah! All X servers are generally done like that, or were in the past.
XFree 3.x was just horrible, with drivers hard-coded into servers. Sun
was no different, with the code for their cards done about the same way.
I remember having the different servers depending on my hardware the
last time I used Suns with graphics.

But this is changing pretty fast. Xig's X server was one of the first to
be rewritten to be heavily modular, with drivers independent of the rest of
the code.

Now XFree is the same way with version 4. The seperation of X by
function looks pretty good so far. Drivers and even renderers and things
like DRI can be replaced without affecting the server.

For example, I have an nVidia GF2 graphics card, supported by XFree.
However the driver is limited, so I got one from nVidia.  I did
nothing more than editn XF86Config, copy a binary driver into
place, and reboot.  

We should see a lot better graphics support in X in the future if the
XFree model becomes part of X overall.  I hope so.

> Isn't a driver just offers the hooks needed to
> map pixel memory, lookup tables, accellerator registers, and the like,
> into process address space using mmap() sufficient?  

It's actually a lot more complicated than that. Hardware various
tremendously these days, and anything hardware doesn't support has to be
transparently emulated. Then you start talking about DRI, font support,
and 3D support, it's lot harder than things were in the past.

But it's all good... :)

> Why must XFree86 contain so many hardware-dependent but Xserver-specific
> drivers itself?  

It doesn't any more... or at least they are very well on the way to that
goal

> Yes I know that development and support of other graphics
> systems (i.e. other than X11) has waned, but does that automatically mean
> that the only way to access graphics hardware should be through the XFree86
> Xserver?

That's one thing DRI is for... allowing the use of an X server but still
letting you get close the the hardware.

> Personally I think there's lots of room for active work on hardware and
> OS graphics support other than the PC-centric model chosen by XFree86.

What part of it do you perceive as being PC-centric? I imagine that the
server in 4.x will sit on top of sbus drivers too. I'm sure the pieces
of code that handle the abstraction will need to be modified (if it has
not been already), but I don't see that as making the design PC-centric.

> I just find it sad that vendors who work in this domain don't at least
> push their older source code out to The X Consortium after the hardware
> it's designed for has reached it's market EOL.  There are dozens and
> dozens of Xserver modules that *should* be in the X Consortium release.

I think what is sad is that they hide ANY information. It's pure
mythology that it would hurt them. Any agreement with third parties that
keeps this from happening is a stupid agreement.

At the very least, vendors could contribute to a modular X architecture
so they can provide binary drivers for all platforms. In fact, it would
be less work for them than their current method of operation, and would
still let them be secretive about it.

> (of course it would be nice if vendors also publlished device driver source
> and theory-of-operation documents for all their EOL hardware too...)

Yep.  Lawyers suck.


-- 
UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com