According to the release plans, the release of X Server 1.8 should take place, and while in reality it will likely not be released today, its release is coming soon. When this release does arrive, it will add a new set of features to the X.Org stack and a number of other minor improvements and bug-fixes.
It was one year ago that X.Org 7.5 was supposed to be released with X Server 1.7 to offer a whole set of advancements like X Input 2 and Multi-Pointer X, but this milestone didn't end up being reached until all the way in October. This was not the first time an X Server release was running months late, but X.Org Server 1.4.1 was released nearly one year late all for a point release. Fortunately, thanks to some changes in the development process and a greater commitment to delivering releases on a timely basis, X Server 1.8 is not nearly this far behind like its predecessors. Back in September prior to the X Server 1.7 release and the 1.8 development getting underway, input expert Peter Hutterer called for process changes. These changes largely came down to developers using branches of the X Server for developing new features rather than the mainline X Server code-base itself, three stages to the development cycle (merge, bug-fix, and release freeze cycles), and predictable time-based releases. This puts the X.Org development model closer to how the Linux kernel is developed.
By the start of October, the process changes were agreed upon and decided was that there would be a single release manager that would be responsible for pulling in the different X Server branches when called upon for pulling the new code into the master repository. This is similar to Linus Torvalds receiving pull requests for the mainline Linux kernel during its merge window. With the X Server 1.8 release series, Keith Packard has become the release manager to pull in the different trees and to tag the different snapshots and releases.
A week after the release process changes came about, an X Server 1.8.0 release date was decided upon of the 31st of March 2010. Other key dates were the closing of the merge window on the 31st of December and the end of the bug-fix window on the 28th of February. By the end of October there was already the release of the first X Server 1.8 snapshot and a second one came just prior to the closing of the merge window. In February was then the first release candidate and just last week was the second release candidate. With the second release candidate coming just one week ago, chances are X Server 1.8.0 will not be released today as planned, but Keith Packard has expressed that this major update is due out within weeks -- still, this is great and looking like it will be their most on-time release in recent times. Succeeding this will be X Server 1.9, which may be released in October of 2010 with X.Org 7.6.
The biggest change with X Server 1.8 is the move away from HAL. The Hardware Abstraction Layer has been superseded by other more device-specific projects like UDisks and UPower, udev, NetworkManager, etc. HAL for Linux and other Unix-like operating systems was designed to be a simple abstracted API for exposing the system's hardware, but it has become "a large monolithic un-maintainable mess" that has led to its deprecation and removal from newer Linux distributions. As a result, the X.Org Server has migrated away from using HAL in favor of OS-specific libraries, like udev on Linux. The udev library is now responsible for X.Org input handling on Linux while still allowing for input hot-plugging like what was provided with the FreeDesktop.org HAL.
To address HAL-like configuration files for configuring these input devices, what came about as its replacement in X Server 1.8 was xorg.conf.d support. Sections of configuration options normally housed in /etc/X11/xorg.conf can now be saved to file fragments within the /etc/X11/xorg.conf.d directory. For example, your input tablet driver instead of writing out a HAL FDI configuration file can now write its own configuration information to the xorg.conf.d directory. To address not loading all of the xorg.conf.d options every time even if no supported device is present, new configuration options were introduced (such as InputAttributes and InputClass) were introduced to match these configuration options to specific devices or specific types of devices.
Also having worked its way into the X Server 1.8 code-base is the new DRI 2.2 protocol requests and extensions for swap events. The drivers still need to implement the support (the Intel driver already does), but with the 1.8 release the necessary changes can be found in the X.Org Server for this support. What is missing from X Server 1.8 is XKB2. XKB2 has been a work in progress for quite a while now, but it did not make the deadline for X Server 1.8, but maybe it will be ready for X Server 1.9 later this year.
X Server 1.8 with its HAL replacement and new configuration system can be found in Fedora 13 and openSUSE 11.3 once released. Distributions shipping soon like Ubuntu 10.04 LTS are sticking to using X Server 1.7.x, but X Server 1.8 (or ideally X Server 1.9 / X.Org 7.6) will be picked up by the release of Ubuntu 10.10 later in the year.
When it comes to the binary graphics driver support for this major X.Org Serve release, the latest NVIDIA proprietary driver will work with X Server 1.8 (their mainline driver and not their legacy releases) while the AMD Catalyst (fglrx) driver does not yet boast such support. Seeing as AMD is not even supporting X.Org Server 1.7 until next month with Catalyst 10.4, it will likely be some months (perhaps even the fall when Ubuntu 10.10 nears) before that support will officially arrive.
Look for the official release of X Server 1.8.0 coming soon.
Discuss this article in our forums, IRC channel, or email the author. You can also follow our content via RSS and on social networks like Facebook, Identi.ca, and Twitter (@Phoronix and @MichaelLarabel). Subscribe to Phoronix Premium to view our content without advertisements, view entire articles on a single page, and experience other benefits.