The X.Org Foundation released
xorg-server 1.7 on October 1st, in preparation for the imminent release of
X11R7.5. Users can look
forward to improvements in display configuration, screen transformation,
and input devices, including the much-anticipated Multi-Pointer X (MPX)
code that supports multiple independent keyboard focus points and mouse
pointers. At the same time, the development team is drawing up plans to
adopt a new release process to accommodate a predictable release schedule
and better testing.
What's new with 1.7 and 7.5
Lower-level changes in the new release include several new
display-oriented technologies: support for Extended Extended display
identification data (E-EDID) and an update to the X Resize, Rotate and
Reflect Extension (XRandR). Another proposed update, the "Shatter"
enhancement to the EXA acceleration architecture, was deferred to a future
E-EDID is a revision of the EDID format with which monitors provide a
machine-readable list of capabilities to attached graphics cards. E-EDID
supports longer strings than EDID, localization of strings, and adds fields
for aspect ratio changing and additional timing and frequency formulas.
E-EDID will eventually be superseded by a newer format called DisplayID,
but is of particular importance to home electronics users because of its
usage in HDMI devices.
1.3 adds two new capabilities: projective transforms and panning.
Projective Transforms allow more generalized transformations of the image
buffer than the previously supported rotation and reflection. This will
allow transforms to correct for keystoning and other distortion, as well as
scaling of the image buffer. If the displayed desktop is smaller than the
virtual screen size, enabling Panning will allow the display to follow the
The deferred project Shatter was one of
X.Org's Google Summer of Code projects, and when integrated will allow
screens to be split between multiple framebuffers.
Input devices also see changes in this release, most notably with MPX.
As the name indicates, MPX allows multiple input devices to be used at
once. That does not mean merely the ability to plug in two mice and two
keyboards physically; X has supported that for a long time. But without
MPX, multiple attached mice both control the same pointer, and multiple
keyboards both route keystrokes into the same input stream. MPX allows for
multiple, separate cursors, with separate focus behavior. Some X
applications and toolkits will require modification to work with MPX, as
they hard-code in the assumption that there is only one keyboard and
MPX is part of a larger revision to the X input system named XInput2.
XInput2 builds on the previous XInput API, and adds other features such as
Device Properties, a mechanism through which generic properties can be
attached to input devices to report special characteristics to the X server
and client applications. Such properties might include mouse button
timeouts, pointer acceleration, or even logical names (such as
distinguishing between multiple attached mice).
Other updates to specific subsystems include changes for Mesa, SELinux,
and VGA arbitration, enhancements to the XQuartz server designed for Mac OS
X, as well as the deprecation of several obsolete and unmaintained modules
The process for 1.8
Peter Hutterer proposed
reworking the X.Org release process in an email to the xorg-devel mailing
list on September 26. He cited three problems with the existing process:
an unpredictable schedule, too much development in the git master that
frequently leaves it broken and unusable, and a too-short testing cycle
that occurs late in the release process. He noted that the three problems
were tightly related, and proposed that the project adopt a timed,
predictable release schedule with separate windows for feature merging,
bug fixing, and final testing.
The proposed process begins with starting separate branches for new
features, rather than developing them as patch sets that could disrupt
master. For each release cycle, the project would then use a three month
merge window to integrate the feature branches into master, then enter into
a two-month bug fix window, and finally freeze master for a one-month
release window, during which time a release manager is in charge, and only
crucial fixes are merged in. The result, argued Hutterer, would be a
predictable six-month release cycle, and a much easier environment for
Keith Packard questioned
whether 3:2:1 was the best ratio for feature merging, bug fixing, and
release freezing, specifically noting that the feature merge window was
considerably larger than that used by the Linux kernel team. Hutterer replied
that he thought it was a good starting value, particularly due to the fact
that the entire process was new, but added that he thought every facet of
the process should be reviewed after the 1.8 cycle, including possibly
the merge window.
The effect on testing was particularly popular with the other developers
on the list during the subsequent discussion. Several contrasted X.Org's
differences from the Linux kernel, beginning with the relative scarcity of
X.Org testers. The consensus in the thread was that the history of an
unstable git master and lack of documentation to guide willing testers in
building and testing the code was to blame; a revised release process with
a stable master and individual feature branches could go a long way towards
building a community of active X.Org testers.
Hutterer made his proposal on the list because he was unable to attend
the 2009 X Developers'
Conference (XDC), held in Portland September 28-30. The XDC attendees
discussed the proposal, after which Daniel Stone posted
their decisions to xorg-devel. The group plans to adopt the basic proposed
model for the xorg-server 1.8 / X11R7.6 release cycle, with the addition of
choosing release managers for each cycle and asking developers to adopt
per-subsystem trees in same manner that the Linux kernel developers use for
Stone's email generated its own controversy thanks to its suggestion
that if the the new process is a success for the 1.8/7.6 cycle, then the
next step would be to merge graphics drivers into the main xorg-server tree
for the 1.10/7.7 cycle. The arguments against merging drivers into the
main xorg-server code base included license incompatibilities, but
ultimately more developers deemed the simplicity of maintaining drivers in
the same codebase as the server to be a long-term win. Still, that change
in source code management is still just a proposal, and one slated for two
release cycles in the future.
Ultimately, the goal of the proposed new release process is to make the
main X.Org codebase more stable, more predictable, and as a result, easier
to test. As several on the xorg-devel list pointed out, xorg-server is
used on just as many systems as the Linux kernel, but has only a fraction
of the active testers that help make the kernel so robust. X.Org continues
to make improvements and enhancements with every release, and long gone are
the naysayers of a decade ago who proposed ditching X altogether. Hopefully,
X11R7.6 and xorg-server 1.8 will arrive on schedule six months from now,
and will show the fruits of a longer and more determined testing process,
to post comments)