1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Legacy Mesa Drivers Receive Their Death Sentence

Mesa

Published on 24 August 2011 04:48 PM EDT
Written by Michael Larabel in Mesa
46 Comments

Last year at XDS 2010 Toulouse there was a discussion about killing old X.Org / Mesa drivers with fire. In particular, dropping all the old drivers that go un-maintained and have little in the way of users and modern functionality. Last year they decided to not really do much about it since these drivers cause little maintenance burden, but the topic has been brought up again and it sounds like these crusty old Linux drivers will finally receive their death sentence.

Intel's Ian Romanick has reignited the discussion about causing death to old drivers -- in fact, that's the title of his mailing list thread.

Ian has proposed stripping away drivers for hardware that is too old and doesn't support modern features (i.e. hardware that hasn't been common for 12+ years), drivers that are un-maintained and that "even hacking in new featureswith dummy implementations is painful", and for "drivers [that] are so buggy that many piglit tests hang the GPU."

Ian wants to kill these old drivers as he's been working up to clean up code within the heart of Mesa, but when refactoring core Mesa code, these old drivers are just getting in the way. Ian also notes that Fedora has begun to stop shipping non-DRI2 Mesa drivers.

The drivers that Ian mentions he wants to drop from the Mesa tree are all DRI1 drivers, which include: i810, Mach64, MGA, R128, Savage, SiS, and Tdfx. The only one of these DRI1 hardware drivers that still might be missed by a small portion of users would be the i810 driver, which provides the Intel Mesa support for pre-i915 IGPs. This though shouldn't be a terrible shock. Intel engineers haven't given a damn about the i810/855 series for years since some of this old hardware was already fairly problematic just when it came to mode-setting and there was already a host of DDX issues when migrating to the GEM-enabled KMS-only stack.

For these old Intel IGPs and the other DRI1 drivers, there is likely little users of them these days -- and if they are they are likely not being updated with new software releases as modern Linux distributions would run on this vintage hardware at a snail's pace.

Besides killing off those drivers, Ian is also looking to remove the un-maintained gldirect and ICD Windows drivers. He also wants to drop BeOS and fbdev, which is the driver for having a software rasterizer directly on a raw frame-buffer device.

In support of killing off these open-source drivers are other Mesa developers, like AMD's Alex Deucher as well as Brian Paul, the original creator of Mesa. Only one user has expressed interest in these drivers and having them moved to a legacy branch, so that in a theoretical world there will be another open-source developer to come along and maintain these ancient drivers and make them work with the modern Mesa interfaces and can then be re-integrated into the stack. There's commonly talk like this, but rarely (if ever) actually materializes in having maintained legacy drivers. Regardless, thanks to Git, accessing dead code is possible.

It looks like these old drivers will finally be laid to rest.

This discussion right now is just concerning the Mesa side of things, but not in terms of any old X.Org (DDX) drivers. There was talk of that last year with there being many vintage X.Org drivers that are no longer touched, aside from an occasional and belated update to make the DDX compatible with the latest X.Org Server interface. Hopefully these old DDX drivers will be killed off too once the 3D drivers go, or just removed from future X.Org katamari releases.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. NVIDIA GeForce GTX 970 Offers Great Linux Performance
  2. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  3. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
  4. AMD Radeon R9 285 Tonga Performance On Linux
Latest Linux Articles
  1. 6-Way Ubuntu 14.10 Linux Desktop Benchmarks
  2. Ubuntu 14.10 XMir System Compositor Benchmarks
  3. Btrfs RAID HDD Testing On Ubuntu Linux 14.10
  4. Ubuntu 14.10 Linux 32-bit vs. 64-bit Performance
Latest Linux News
  1. GTK+ Lands Experimental Backend For Mir Display Server
  2. Ubuntu 14.10 Officially Released
  3. Mesa 10.4 Might Re-Enable HyperZ For R600g/RadeonSI
  4. Intel GVT-g GPU Virtualization Moves Closer
  5. GTK+ 3.16 To Bring Several New Features
  6. Debian 8.0 Jessie Has Many Multimedia Improvements
  7. What Linux Benchmarks Would You Like To See Next?
  8. Open-Source, Linux Support For Corsair Link Devices Slowly Materializing
  9. Cairo-Dock 3.4 Shows A Lot Of Progress, Works Toward EGL/Wayland Support
  10. Mesa 10.4 Tentatively Planned For Early December
Latest Forum Discussions
  1. Linux hacker compares Solaris kernel code:
  2. Advertisements On Phoronix
  3. HOPE: The Ease Of Python With The Speed Of C++
  4. Updated and Optimized Ubuntu Free Graphics Drivers
  5. Users/Developers Threatening Fork Of Debian GNU/Linux
  6. Ubuntu 16.04 Might Be The Distribution's Last 32-Bit Release
  7. AMD Releases UVD Video Decode Support For R600 GPUs
  8. Proof that strlcpy is un-needed