Re: Some perspective from the cheap seats...

> Someone needs to police changes made to device driver code to ensure 
> things are *working*, when they are comitted to the XFree86 code tree. 
> Keeping the list closed helps to maintain a reasonable amount of quality, 
> but it means things move *very* slowly. 

Providing the tree has regular "most of it compiles" snapshots and
developers and others are encouraged to try them out that isn't as true
as you think. In fact XFree has singularly failed to achieve this
goal because its not possible. On 4.3 my Riva128 failed and my Glint
Delta no longer works. I'd bet no XFree core member even has a Glint
Delta on PCI let alone tested it on 4.3. They have better things to be
doing anyway.

Let people break stuff, providing you have a good idea what the state
of things are you can let people fix bugs as they find them. In the
kernel fixing one card variant often breaks another, and it turns up
from users testing snapshots not from the developer.

> changes can verify things are correct. More importantly those tools 
> should be available to the developers actually working on the drivers, so 
> they can ensure their work is correct before sending it to the committer.

A test suite that uses each XAA op in various ways would help no end, as
would one which ran through lots of mode settings.

> Yes, I agree entirely with that. Network transparency is nice sometimes, 
> but not really essential for the day to day use of desktop computing. The 

Large numbers of my employers customers would disagree with you. For some
things the desktop approach is right, but for many things it is not. The
lack of a sane client-server architecture in Windows distorted the
market heavily.

I'd ask a different question with my general networking hat on. Bandwidth
is rising pretty much exponentially to many users. Latency is nearly
a constant and in some cases (cable/ADSL) has increased. On that background
the question becomes "Is the X model wrong for remote computing due to
round trip times". VNC for example significantly outperforms X (with
compress) for remote use of Gnome on 802.11b

> first step IMHO is to simply implement a 2D direct rendering system to 
> increase performance. Whether X needs to go or whether it can be 
> reinvented to support 2D direct rendering is a different question.

DirectFB + XDirectFB ?