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 7.4 Finally Released

Michael Larabel

Published on 23 September 2008
Written by Michael Larabel
Page 1 of 2 - 1 Comment

It's been a hell of a time getting X.Org 7.4 out the door, but this afternoon Adam Jackson has released this long-delayed update to this X system. X.Org 7.4 is arriving after the release of X Server 1.5.1 earlier in the day. Yes, it's finally here! In this article we have information on the features that make up this release along with what it's taken to get X.Org 7.4 primed for release.

In the mailing list announcement for this release, Adam Jackson simply stated:

Finally put this one to rest:

http://xorg.freedesktop.org/releases/X11R7.4/

The release notes point to the wiki. Please update them responsibly if necessary.

- ajax

The official documentation surrounding this release is minimal, but below are the major details surrounding X.Org 7.4 / X Server 1.5. Most of these details we had shared earlier this month when X.Org 7.4 was scheduled to be released on September 10.

Originally, X.Org 7.4 was set to be released in March of 2008 with features that included XGE (X Generic Events), XACE (the X Access Control Extension), RandR 1.3, more PCI reworking, XKB 2, a DRI memory manager, and Glucose. However, many of these features didn't end up getting integrated into X.Org 7.4. It wasn't until February that Red Hat's Adam Jackson had stepped up to the plate with some release plans and a revised target date of May. Red Hat had hoped to ship X.Org 7.4 with Fedora 9, but as the May release wasn't met, Fedora 9 ended up shipping with a pre-release. In early March was the first X Server 1.5 pre-release (1.4.99.901) that had included more than 100 changes with memory leak fixes, EXA improvements, and plenty more.

In June, Adam Jackson was getting ready to release X.Org 7.4 by addressing some of the last minute bugs. However, Mesa 7.1 had become a requirement for building X Server 1.5. Mesa 7.1 was still in development and the latest bits of code needed to build the X Server were only available through the git revision control system. At that point, it became a waiting game for Mesa 7.1 to be released so that X.Org 7.4 could then ship with a dependency that can be easily obtained. Just days ago we finally had the Mesa 7.1 release with a new autoconf-based configuration, DRI driver enhancements, reduced dependencies between the X Server and Mesa, GLSL support for the Intel 965 series, and ATI R500 3D support. With Mesa 7.1 out the door, it finally paved the way for the X.Org 7.4 release.

The other important part that makes up each X.Org release, the X Server, had its major update earlier this month. This release was X Server 1.5.0 but being published on the web this morning was X Server 1.5.1. The 1.5.1 release introduces a handful of bug-fixes.

X.Org was slated to receive MPX support, but Multi-Pointer X ended up being postponed to the next release. Multi-Pointer X has since merged to master but will not be present until X Server 1.6. However, if Xi2 and Xkb2 aren't completed and stabilized in time, Keith Packard has mentioned he will disable Multi-Pointer X at build-time for X Server 1.6 and hold it off for a X Server 1.7 feature. The X Server 1.6 release will include X Input 1.5 with device properties at least.

Arriving in the middle of the X.Org 7.4 development cycle was the Graphics Execution Manager, which is a kernel-based memory manager for graphics processors developed by Intel, and is designed to circumvent the shortcomings of Tungsten's TTM that previous to May had looked like the memory manager that would become the standard for open-source drivers. GEM though has caused quite a bit of reworking to take place in the X world with a new EXA-based acceleration architecture coming about as well as other developers now coming up with a GEM+TTM memory management mix for the other drivers.

How GEM affects end-users though in X.Org 7.4 is that DRI2 has been dropped. The Direct Rendering Infrastructure 2 was going to be a highlight of the X Server 1.5 since it allows for Redirected Direct Rendering and other advantages that improve the desktop experience. DRI2 had to be dropped from the X Server 1.5 release since it was late in the development cycle when Intel had stripped its TTM code and replaced it with GEM. DRI2 was dependent upon some TTM bits and therefore it needs to be reworked to support the GEM API. DRI2 is now on the table for X Server 1.6.

<< Previous Page
1
Latest Linux Hardware Reviews
  1. MSI X99S SLI PLUS On Linux
  2. NVIDIA GeForce GTX 970 Offers Great Linux Performance
  3. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  4. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
Latest Linux Articles
  1. RunAbove: A POWER8 Compute Cloud With Offerings Up To 176 Threads
  2. 6-Way Ubuntu 14.10 Linux Desktop Benchmarks
  3. Ubuntu 14.10 XMir System Compositor Benchmarks
  4. Btrfs RAID HDD Testing On Ubuntu Linux 14.10
Latest Linux News
  1. Fedora 21 Beta & Final Release Slip Further
  2. Mesa 10.3.2 Has A Couple Bug-Fixes
  3. RadeonSI/R600g HyperZ Support Gets Turned Back On
  4. openSUSE Factory & Tumbleweed Are Merging
  5. More Fedora Delays: Fedora 21 Beta Slips
  6. Mono Brings C# To The Unreal Engine 4
  7. Coreboot Now Has Support For Intel Broadwell Hardware
  8. Enlightenment's EFL 1.12 Alpha Has Evas GL-DRM Engine, OpenGL ES 1.1 Support
  9. GTK+ Lands Experimental Backend For Mir Display Server
  10. Ubuntu 14.10 Officially Released
Latest Forum Discussions
  1. HOPE: The Ease Of Python With The Speed Of C++
  2. Updated and Optimized Ubuntu Free Graphics Drivers
  3. Ubuntu 16.04 Might Be The Distribution's Last 32-Bit Release
  4. Linux hacker compares Solaris kernel code:
  5. Advertisements On Phoronix
  6. Users/Developers Threatening Fork Of Debian GNU/Linux
  7. AMD Releases UVD Video Decode Support For R600 GPUs
  8. Proof that strlcpy is un-needed