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

X.Org Development Discussion Continues

X.Org

Published on 28 October 2009 10:54 AM EDT
Written by Michael Larabel in X.Org
2 Comments

In late September there was a call by Peter Hutterer for a new X.Org release process that consisted of a six-month release cycle for the X Server, all development work to be done in feature branches and not Git master, and a three-stage development cycle. The agreed upon version was pretty much the same as Peter's version, but it also called for the X.Org drivers to be pulled back into the X Server (around version 1.10).

This process was immediately adopted with X Server 1.8 getting a release date just six months out, and the first X Server 1.8 snapshot already being available. So everything is all set, right? Well, a discussion regarding the X Server release and development process has continued for the past several days among key X.Org developers.

Many messages have been accumulating about this matter in this mailing list thread, but here's the summary. While a six month release cycle right now is good for the X Server, and its current schedule of new versions that would be out in March / September just in time for the seasons of Linux distribution refreshes, this may not work in the future. Once the input/video drivers are merged back into the X Server, some developers are calling for a three month release cycle of the X Server.

Moving the X.Org drivers back into the X Server -- even though they were merged out of the X Server a few years back -- is wanted so that invasive API/ABI changes can be carried out without causing hell on the user. Lots of dead, legacy code could be deleted from both the drivers and the X Server, without making it messy on distribution maintainers and end-users with having certain version requirements for the different components with each X Server release. Instead, users would just need to grab the latest X Server, which would include the compatible drivers and need not worry about any API/ABI breakage. Having the drivers in the X Server would also cause more users to test out the latest X Server development code, which isn't happening too frequently right now.

However, with an X Server + drivers combo, some -- including Keith Packard -- are saying that a six month release cycle is not frequent enough. Intel ships their X.Org driver updates quarterly and many of the other open-source X.Org drivers ship more releases than two a year too. With what the current model looks like now, a user could be waiting up to six months for a new driver that supports the latest graphics hardware, new features, bug-fixes, etc.

Depending upon the policies of the Linux distribution you are using, you may need to wait for an entirely new update to your distribution before the new X Server / drivers are pulled. Though as it stands right now, some distributions (such as Ubuntu) end up having older drivers and will not push down new major xf86-video-* driver releases until their next bi-annual release, which forces the users already to build from source or use a bleeding-edge package repository in order to gain new hardware support or important features. These users end up just seeing two driver releases per year already, though distributions like Fedora update their graphics drivers much more frequently.

When it comes to having an even shorter release cycle, there becomes the problem of getting the actual releases out the door and in a working, quality state. The X.Org project is strapped for developers as it is, while putting out for X Server releases per year would place an even larger burden on their shoulders. Beyond just getting the releases out there, with a short release cycle it also becomes a matter of how legacy and stable branches would be maintained and for how long, which again is more work on the X.Org developers, and decisions to be made about back-porting work in the X Server, etc.

Other ideas have also come up on the mailing list with only allowing API/ABI breakage on even versions of the X Server and even splitting out graphics drivers on a per-chipset/series basis. Instead of just having say the "radeon" driver module, there would be a separate driver for the R300, R500, R600, R700 series, etc. Albeit, much of the code between the different families is already shared.

Of course, the drivers could just not be merged back into the X Server, but then cleaning up the X Server and drivers becomes more difficult with API/ABI breaks. There's a few decisions to ultimately be made, and we'll keep tabs on this thread to see what comes about.

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. Even With Re-Clocking, Nouveau Remains Behind NVIDIA's Proprietary Linux Driver
  2. The Power Consumption & Efficiency Of Open-Source GPU Drivers
  3. AMD R600g/RadeonSI Performance On Linux 3.16 With Mesa 10.3-devel
  4. Intel Pentium G3258 On Linux
Latest Linux Articles
  1. Updated Source Engine Benchmarks On The Latest AMD/NVIDIA Linux Drivers
  2. Nouveau vs. Radeon vs. Intel Tests On Linux 3.16, Mesa 10.3-devel
  3. KVM Benchmarks On Ubuntu 14.10
  4. X.Org Server 1.16 Officially Released With Terrific Features
Latest Linux News
  1. GStreamer VA-API Plug-In Update Adds New Features
  2. Qt 5.4 Going Into Feature Freeze Next Week With Exciting Changes
  3. OpenSUSE Factory Turns Into Rolling Release Distribution
  4. "The World's Most Highly-Assured OS" Kernel Open-Sourced
  5. NVIDIA Is Working Towards VDPAU H.265/HEVC Support
  6. Hawaii Bug-Fixes Start Hitting Mainline RadeonSI Gallium3D
  7. The FFmpeg vs. Libav War Continues In Debian Land
  8. Grand Theft Auto Running On Direct3D Natively On Linux Shows Gallium3D Potential
  9. GCC As A Just-In Time Compiler Is An Interesting Project
  10. Age Of Wonders III Is Still Being Ported To Linux
Latest Forum Discussions
  1. Linus Torvalds On GCC 4.9: Pure & Utter Crap
  2. AMD Athlon 5350 APU On Linux
  3. Updated and Optimized Ubuntu Free Graphics Drivers
  4. Debian + radeonsi
  5. Open-source drivers on ATI R7 260X
  6. List of Linux friendly Kickstarter projects
  7. Porting Mesa to the Playstation 2
  8. ASRock AM1H-ITX: One Of The Best AM1 Mini-ITX Motherboards