Disable xterm and XRX builds per default / [Fwd: CVS Update: xc (branch: trunk)]

[Adam Jackson]

On Monday 24 January 2005 14:33, Keith Packard wrote:
> Around 19 o'clock on Jan 24, Keith Whitwell wrote:
> > It doesn't refer to any of the serverside stuff, especially not the
> > software indirect renderer which is built into (I think) dri.a and which
> > contains basically the whole mesa source tree.  The right way to remove
> > this last dependency is to get indirect rendering handled (one way or
> > another) by the hardware acclerated clientside code.
>
> I'm not concerned about the server-side software rendering code; that can
> provide stale GL support for all the value it has to real applications; to
> some extent, it would actually be a feature to use pure client-side
> rendering instead as it's faster...

Can be.  Isn't always.  Depending on what card and the phase of the moon I can 
get better performance out of indirect GLX versus Mesa's X11 driver.  At any 
rate hardware indirect is the better way to go.

The value in accelerated indirect is in things like DMX, where AIGLX gets you 
accelerated GL on every head.  Also this makes cairo apps over the network 
Not Suck.

> I am, however, concerned about the interdependencies between the low level
> 2D driver, the DRM and the Mesa GL driver.  If Mesa ships a DRM based
> driver which must be mated to a specific 2D driver, then we need to figure
> out who's going to ship what pieces.

Xorg ships the DDX driver.  Mesa ships the DRI driver.  There's a version 
handshake between the DRI and the DDX to make sure they're mutually 
compatible.  (To clarify, I only know that this is the case in the one 
direction, I'm not sure the DDX knows how to check the DRI driver version.)

At any rate, you put a big red flag on the Mesa release that says "The savage 
driver requires a post-6.8 DDX to work, deal with it".  In a real modularised 
world each DDX has an explicit version number too as part of the package 
name, so you can say things like "Needs savage ddx 2.7".  Same deal with the 
kernel DRM driver, except those would all get packaged together because 
there's no real value in splitting them up.

There's also a slow dependency on libdrm but that hasn't changed in _years_ 
besides me making it build as a DSO.  If we really need to we can bump the 
major number on libdrm, or just bump minors for API additions.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050124/a831970c/attachment.pgp>