Dave Jones wrote:
> On Sat, Sep 04, 2004 at 01:04:17PM +0100, Dave Airlie wrote:
> > releases, I would like to give those people a chance to use their graphics
> > cards, and the snapshots are not the only way, Intel have i915 Linux
> > drivers on their site from TG, they work on most kernels/distros, I get a
> > machine with i915 install Debian go to Intels website and download their
> > drivers, it all works, now why do I have to compile a kernel again?
> Then a month later, Debian issues a kernel security errata.
> You download and install it, and your 3d stops working.
> (worse case, maybe even your 2d breaks).
> The 'download third party drivers' thing is not a silver bullet.
> It will screw end users over, just as equally as it claims to help them.
There's no real disagreement that the best way to do things would be have
everything come down nicely packaged from the distro vendor. (Certainly with
my TG hat on, that is how we'd like to see things work - it's obviously easier
for us.) Historically it just didn't work though, and even into the future,
no matter what changes, I can still see a requirement for binary snapshots or
With the new LK "always stable" development model, one barrier to this ideal
of fast distribution of drivers seems to have fallen. This is perhaps the
biggest change, and I admit the implications have only just started to sink in.
Dave Airlie taking a pro-active role as DRM maintainer is also a recent change
- for a long time that code was a neglected corner of the XFree86 tree, now
it's starting to look like a first-class project in its own right and is
getting more of the attention it needs to beat it into shape.
The remaining question mark is the process of pushing the userspace drivers
out. I floated a proposal recently to loosely synchronize Xorg and Mesa
release schedules which might help a little, but there is still a potentially
long delay affecting the userspace parts of a driver in their progress to
vendors & ultimately users. Ultimately you're right that splitting that tree
up & letting the parts evolve independently might address the problems there,
though that's at least two X releases away.
In the meantime, though, downloadable binary drivers continue to be a useful
testing aid for the DRI project (their original intent), and a convenient
bandaid for working around a distribution channel which I think will probably
be pretty slow for a year or more to come.