The graphics stack in Linux comprises a number of distinct projects, and in this article we'll take a look at the current development of X.org, Wayland, and Cairo.

Linux graphics have undergone a major evolution over the past decade in two respects. First has been a shift from 2D system rendering, to today's hardware-accelerated 3D system compositing. Second has been a large-scale migration of graphics support from X down to the kernel level, where it can take maximum advantage of hardware capabilities. In recent years the former has exposed limitations in X.org's design, while the latter made it much easier to reimplement a graphics stack separately from X.

Thus there is now both the motivation and means to replace X, and this has led to a couple efforts to do just that. Wayland is slowly but surely becoming a useful affair, and Canonical's Mir efforts are offering a credible new challenge. Yet recently X.org has embarked on development of DRI3, demonstrating that this venerable project is not yet ready to fade into the sunset.

• xorg-server: 1.14.2 was released June 25, 2013.
• wayland 1.2.0 and weston 1.2.0 were released on July 12, 2013.
• cairo: 1.12.14 was released Feb 10, 2013, and is currently preparing for a possibly upcoming 1.12.16 release.

By and large, X.org is in maintenance right now, although some interesting development work is going on around the edges.

Of particular note this month, Keith Packard has been developing Present, an X server extension that handles redirected video in composited scenarios more cleanly. It provides a more direct path for applications to display visuals on the screen. This complements recent development work for the new DRI3 extension. See below for a more detailed examination of this new technology.

A new library, libevdev, was introduced by Peter Hutterer, which wraps the kernel evdev interface and provides abstractions for ioctls, SYN_DROPPED events, and device bit checking. The goal of this work is to establish a shared codebase for use by X.org, weston, and evtest. libevdev has received two releases so far, and is currently at version 0.2.

Multi-screen reverse optimus support was added to the Nouveau and Radeon drivers. This feature allows rendering to be done by the integrated GPU (typically Intel), and displayed through monitors connected to discrete GPUs (e.g. Radeon or NVIDIA graphics cards).

In addition to these major efforts are the usual array of bug fixes and codebase cleanup changes. Of particular note, Peter Hutterer proposed a large set of input patches to backport fixes for touch to xserver 1.13, to fix grab handling, cursor refcounting, race conditions, and other issues. Driver and keyboard fixes were also integrated from OpenSUSE by Egbert Eich, and from NetBSD by Thomas Klausner.

As X.org has been around quite some time, there is ongoing efforts to excise obsolete code to help cleanse the codebase. This month's dead code removal included dropping CRAY support, and obsoleting libxkbui.

One of the main selling points of Wayland and other recent display technologies being developed is that they provide a better solution to X.org's limitations when it comes to compositing of multi-buffer windows. X.org predates today's ubiquitous 3D-capable graphics hardware and its original design did not take compositing into account. It's a testament to X11's modular flexibility that compositing could be added in via the DRI2 and composite extensions, however this scheme has always felt a bit bolted-on to developers, and doesn't work well with direct rendering clients such as games and movie players.

However, a recent X.org development promises to change this, via the DRI3 and Present extensions.

The DRI3 extension allows applications to render directly through kernel buffers into Pixmaps, effectively moving this graphics buffer management out of X and into applications.

The Present extension handles moving the pixels from the DRI pixmap created by the DRI3 extension to an X drawable that can be displayed. An application calls PresentRegion once it has a back buffer ready. The server captures this request and constructs an event for the compositor to place the image correctly on the screen. The compositing manager receives this event and clips the pixmap to the shape and transformation of the window. Then it combines the transformed pixmap with other application pixmaps as needed (thus handling multi-window translucency, blur, etc.), and generates another PresentRegion request to have the result mapped onto the root window. Additionally, the compositing manager is made aware of which monitor the window is being drawn on, so it can synchronize the updates to that monitor CRTC's refresh rate. The application is then notified that its PresentRegion operation has completed, so it can handle cleanup and proceed with the next cycle.

This new approach serves to minimize the number of copy operations needed by applications to display their content within a composited environment. The goal is to achieve this without incurring tearing or other display artifacts.

By providing a complete direct rendering solution for OpenGL, the DRI3 and Present extension provide applications with the key benefits promised by Wayland, without the need of replacing X. Initial implementation of these extensions has been done, but they've not yet landed in the Xserver repository. If it lands soon, we may see this functionality in Xserver 1.15, scheduled for release in September or October; otherwise it'll need to wait for 1.16 this spring. For now, the functionality is available through Keith Packard's freedesktop.org git branches.

A common misconception about the Wayland project is that it is intent on literally replacing X. A more accurate view is that it is a technology incubator for proving out design concepts. The project produces two components: The Wayland Protocol and the Weston Display Server. The Wayland Protocol is considered the principle product of the project, with Weston being a reference implementation that it expects other projects to study or reuse from in developing their own Wayland-compatible technologies. The Weston package also includes an example shell and several example client applications.

This month saw the 1.2.0 releases of both Wayland and Weston. With much of the core API and implementation stabilized in 1.0.0, development in versions 1.1.0 and 1.2.0 has mainly focused on adding backends, polishing up the codebase, improving input handling, and fleshing out subordinate features that take advantage of the Wayland architecture.

One of the new features added in 1.2.0 is a new subsurface protocol extension. This allows clients to create their windows using multiple Wayland surfaces, for example a video player that might consist of window decorations, the video player, a sub-title layer, and picture-in-picture. Each graphical buffer can be of a differing type, with its own color space.

Color management was made more flexible in this release, as it now permits a choice between a simple CMS plugin with a profile read from weston.ini, and integration with colord. The latter permits run-time adjustment of the color profile using tools like gnome-color-manager or colord-kde.

Multi-seat functionality was added to permit defining keyboard and mouse pairs using udev rules. Each of these 'seats' can (optionally) be confined to a specific output monitor.

There is a new example client included which demonstrates how to share buffers among clients. The classic use-case is a web browser with an embedded client plugin for video playback. For security purposes, Wayland imposes stricter boundaries between clients than usual for X, so this demonstrates how to make one client act as a compositor for another in a nested fashion.

Several efforts this month focused on improvements to the shell. A xdg_shell protocol was proposed, that would establish a standard API with functionality like resizing or moving windows, setting windows state (transient, maximized, et al.), and setting window names. Shell functionality from the Raspberry Pi technical demo were proposed for inclusion; some fixes were pulled in, other items were deemed more cosmetic and out of scope for Weston.

Jason Ekstrand proposed language bindings for libwayland, for e.g. writing clients in e.g. Java. This could be a significant new feature, if it opens up Wayland client development to a wider range of programmers.

Beyond Wayland core development there are starting to appear efforts to add Wayland compatibility in other projects. Sam Spilsbury announced a proof-of-concept port of the XBMC Media Center to run inside Weston, using SDL 2.0. Both the KDE and GNOME desktop environment projects have declared intention to add Wayland support; the Enlightenment project already runs on Wayland, and plans to implement a stand-alone Wayland compositor.

Cairo development has been fairly quiet this month. The tree is being stabilized for a 1.12.16 release, although no dates or release schedules have been announced.

About a dozen patches this month focused on test suite fixes and cleanup. In particular, support was added for identifying redundant reference images; this was used to drop a bunch of unneeded files from the codebase.

In addition, Henry Song landed three patches to fix stencil buffer issues. Behdad Estfahbod landed some preparatory work for loading color glyphs from FreeType.

It will be interesting to see if the DRI3 / Present extensions for X.org will satiate Linux distribution graphics needs, or if Wayland adoption will accelerate as its technologies mature. Or, perhaps, the migration of core graphics technologies from X.org into the Linux kernel will inevitably lead to a Cambrian Explosion of compositors and new graphics projects. Will Wayland and Mir be the only contenders for replacing X, or have they merely paved a path for future projects to follow? Will the Wayland protocol be compelling enough to prevent fragmentation, or are we destined to see a host of specialty display technologies built atop the Linux kernel?

• Linux Plumber's Conference: Sept 18-20, New Orleans, Louisiana. A Graphics and Display micro-conference is being scheduled.
• X.org Developer's Conference: XDC2013 - Sept 23-25, Portland, Oregon
• LibreGraphics Meeting: LGM2014 - April 2-5, 2014: Leipzig, Germany