1 2 3 next »

1. The significance of Wayland
2. How we got to Wayland
3. Living in Wayland

Wayland - Beyond X

by Richard Hillesley

"If the designers of X-Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles – but you'd be able to shift gears with your car stereo. Useful feature, that" - Marus J. Ranum

Although current discussion of the Linux desktop tends to focus on the disharmony around Unity and the GNOME shell, the true revolution on the desktop is taking place out of sight of users. The Wayland display server is expected to reach version 1.0 later this year, and is seen by many as the long term replacement for the X Window System, with real potential to improve and transform the performance of the desktop for Linux users.

The significance of Wayland is that it aims to bring a new and simplified approach to graphical systems on Linux, "pushing X out of the hotpath between clients and the hardware", and replacing it with a more direct and logical path between kernel and client. Wayland is both a protocol and a library that implements that protocol on Linux.

X relies on a server to share out graphical resources, but over the years "a lot of infrastructure has moved from the X server into the kernel ... and there is very little left that has to happen in a central server process." At the same time, consistency and performance have been impeded, as Keith Packard points out, because "the window system has been split apart into multiple pieces – the X server, the window manager, the compositing manager", which are all connected by "complex, asynchronous protocols" so that, for example, "every keystroke must pass through at least three processes: the application, the X server, and the compositing manager."

Wayland removes these complexities. In Wayland, the compositor (now known as Weston) is the display server. Weston takes control of the display and input events and the Wayland protocol allows the compositor to send those input events to the clients. Clients, in turn, are given their own memory buffers to write into using whatever rendering technology they want to use and, through the Wayland protocol, inform the compositor of changes in those buffers. The compositor takes those "damage events" and assembles the buffers from the various applications into what the user sees as a windowed display showing many overlapping clients. This method removes several layers of complexity from the graphics processing and in turn puts control and performance back in the hands of the clients.

Every frame is perfect

Wayland was conceived by Kristian Høgsberg in 2008 as "a prototype/playground for some ideas I've been toying with." Høgsberg was employed by Red Hat to work on the Linux graphics stack, "including drm, mesa, X, cairo and more", and had done some work on "implementing AIGLX, which has allowed compiz and other compositing managers to run on X, and DRI2, which integrates accelerated OpenGL with the COMPOSITE extension."

Høgsberg had the inspiration for Wayland while driving through the town of Wayland in Massachusetts, which gave the display server its name. Weston, the Wayland compositor, is named after a neighbouring town in the same state. The concept came from the realisation that many elements of the Linux graphics stack have been "split up and refactored into shared libraries, kernel drivers and other components", and that "the X server is now just a middle man that introduces an extra step between applications and the compositor and an extra step between the compositor and the hardware."

Wayland can use the refactored components to build a composited desktop that is more responsive and flexible, and the X server can provide legacy functionality as a client of Wayland with a minimal overhead on its current performance. In the past, rendering has been performed by the X server; Wayland uses direct rendering through DRI2. "With direct rendering, the client and the server share a video memory buffer. The client links to a rendering library such as OpenGL that knows how to program the hardware and renders directly into the buffer. The compositor in turn can take the buffer and use it as a texture when it composites the desktop. After the initial setup, the client only needs to tell the compositor which buffer to use and when and where it has rendered new content into it."

As Høgsberg expressed it at the outset of his project: "The core idea is that all windows are redirected, we can do all rendering client side and pass a buffer handle to the server and the compositing manager runs in the display server." The significance of Wayland to the end user is in the Wayland tag line "every frame is perfect", which means, according to Høgsberg, "that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker."

No functionality will be lost. Applications that use the GTK or Qt toolkits will be able to use Wayland as the toolkits gain Wayland support, and older applications will be able to run on an X Server, running as a Wayland client. What Wayland promises is greater flexibility and better performance.

Next: How we got to Wayland

1 2 3 next »