General Procedure to get ATI/DRI card running?

[Coleman Kane]

On Wed, 2008-07-02 at 00:16 -0400, Arc Riley wrote:
> 
>          So I guess some are indeed considering "released 16 months
>         ago" as
>         "extremely out of date".
> 
> Yes, 16 months ago is extremely out of date.
> 
> If a new stable release of a popular package is not packaged within a
> week, there's a problem.  It's a massive chilling effect to free
> software development when a large number of users don't have access to
> recent versions. 
> 
> It hurts community support as well, people hit bugs that were fixed
> over a year ago and they can't easily upgrade because a newer version
> has not been packaged yet.  That's really bad.  Our ability to fix
> bugs and release a new version within a few days, getting it into
> people's hands so they can take advantage of the bugfix or new
> feature, gives us a huge advantage over proprietary software.
> 
> It is bleeding edge to grab a projects development tree from git or
> svn.  It's cutting edge to download a beta or release canidate.  A
> stable release should be packaged and available for upgrade.
> 
> I'm not talking about maintaining support for older versions, that's a
> separate issue entirely.  I'm talking about having newer stable
> versions packaged so that those who need them can get them without
> having to download, compile, and install on their own.
> 

A little known secret in the free software world is that the X.org
system (as a whole) really hasn't had a home since the fracture between
the XFree86 folks and the X Consortium members back in 2004 when XFree86
decided to change to a new GPL-incompatible license. This was, of
course, after a number of other snafus, one of which was the ejection of
Keith Packard from the core team (who had garnered a lot of respect in
the community), as well as the appearance to many of us outsiders that
the core had less and less time to focus on the project, but were highly
reluctant to offloading responsibilities to new members.

At that time, the X Consortium (x.org) picked up the pieces of the last
X11-licensed XFree86 4.4 pre-release and set into motion a series of
events that has resulted in the 100+ distributed projects that make up a
"functional" X deployment. The consortium offered to act as host to
release the "reference distribution" of future X servers, but IIRC they
only gave a temporary commitment back then (until freedesktop.org can
organize itself).

At some point during X11R6.8.0, it was determined that the whole
"cathedral model" of development just was not going to work, as the
project fell rapidly behind (even more so than it is now). They
committed to drop that model as of the 7.0.0 release (again, IIRC), and
distribute the project pieces out to whomever was willing to pick them
up to maintain them (or whomever had been actively maintaining the best
patch set).

Still, to this day, X.org remains stretched pretty far. They are
probably top on the list of projects that could stand to get some more
help (if all us Linux/UNIX geeks want to keep having a nice windowing
system). This isn't just the X system for a bunch of free OS's, but also
the one for Solaris, Mac OS X (not Aqua, but the actual X-server
implementation), and pretty much everyone else that uses X11 in some
manner. I don't even know if there are commercial X servers out there,
not using the X.org code-base, that are better.

It is easy to get upset that you might need to jump through hoops to get
your brand-spanking-new graphics card working under your Linux distro.
You happened to get the card during a transition period while the brand
new generation of X drivers for current and future ATI cards is under
development. This is the first time they (ATI/AMD) have undertaken such
a project, and it is moving along much quicker than the previous
X-driver developments that I've followed (tdfx, nv, ati r300). If you
help them design the driver (bug reports!), then you help them build a
foundation to more quickly get their future R700 and R800 GPUs supported
with.

If you can spare it, they can use the help: bite the bullet and run the
development stuff on your box, and give them reports. For the most part,
the card isn't going to "just work" easily if you're still on the old
releases of X.org, no matter when it is. If you want hardware to "just
work" then you've got to buy the stuff that came out a year ago, and has
had people using it already for a long time. One important part of the
whole FOSS experience has always been (for me, anyhow) participation. I
can either buy some proprietary software mess and be on their tech
support line answering dumb questions when it doesn't work, or I can go
in and try to act to fix it myself.

It is really important to understand, though, that the X.org project is
really one without a "home" or "owner". The X Consortium (x.org) really
only committed to provide some hosting, and maintain a central
repository of protocol, format, and other project-related standards and
specifications. Through its history as X.org and XFree86, it has never
gotten significant support from the hardware vendors that it is expected
to support. Support for 3Dfx hardware, for instance, didn't really get
solid until after 3Dfx shut its doors and released all their docs
on-line for free. When all the packages went modular, it was supposed to
nudge the bigger distributors (RedHat, SuSE/Novell, Debian, etc...) to
maintain their own X.org-derived distributions of X.org software, and
perform stability testing on the feature snapshots and release their own
distributions as development went on on the various freedesktop.org
projects. Basically, to take a more active role in testing and reporting
X.org problems.

To this day, that hasn't happened except in the case of the OpenBSD
project. Now everyone suffers because graphics hardware is getting close
to having a shorter lifespan than X.org releases. The X.org consortium,
to its credit, has finally recognized this and recently announced it is
going to change its release schedule to be more aggressive. The likely
result of this is a much quick time-to-market for new features, at the
expense of an increase in bugs exposed to the public (and hopefully,
found quicker and fixed quicker).

Today graphics hardware provides all sorts of features not considered by
the developers when X.org 1.3 or 1.4 were released. The development
trees are where all this stuff is being developed (EXA, DRI2, next-gen
RandR code, new DRM). They've done a heck of a lot of overhaul in the
Mesa and Xserver source code trees in the past couple months. The best I
can say is that, following the lists myself and the chats, they are
working really hard at getting this stuff together. You should probably
see 1.5 released with a lot of this new feature-set around August. If
you want to improve the odds of this happening, you should get involved.

I would, at the very least, recommend you try forwarding your email to
the developers list at X.org and also your Linux distribution. Both are
culpable in the problems that you are experiencing.

IMO, every distribution should be maintaining a -devel package for every
one of the released versions of their X.org software modules. We are
never going to get to the point where the features supported in a new
graphics card can be safely and reliably implemented in a new or
existing driver for the X-server in 3 months time, let alone at the
initial release date of the graphics card, if all the distributions
insist upon only using the "last stable release" of X.org packages. At
least with tracking -devel packages, they would be able to give much
greater exposure of newly developed features, without forcing users to
violate their distribution's deployment hierarchy and install from
sources manually (likely leaving out any distro-specific patches).

-- 
Coleman Kane