The good old X Window System consists of an X server that receives events from input devices and draws the graphics on the screen. On top of this system is a compositor, which records the positions of Windows and adds novel graphical effects as needed (Figure 1). Desktop environments add a window manager that decorates every window with a frame.

Figure 1: The X Window System: The kernel reports a mouse click to the server, which forwards the event to an X client. The client sends a render request to the X server, which also informs the compositor. The compositor recomposes the screen area and asks the X server to redraw it.

All of these components need to communicate through a time-consuming process. The cumbersome structure and outdated complexity of the X system bothered programmer Kristian H¯gsberg, so he designed an alternative back in 2008, which he dubbed Wayland [1]. H¯gsberg kept to the core functions that a display system currently needs to provide on Linux. He also set out to design Wayland so that it would avoid tearing, lag, flicker, and unnecessary redrawing of modified screen areas [2].

The result was a surprisingly sleek and efficient system. Media reports increasingly attracted the attention of supporters to H¯gsberg's new display server architecture.

One organization that jumped on board with the Wayland development effort was Ubuntu parent company Canonical, but after a couple years in the trenches, Canonical announced that it would instead build its own graphical system called Mir, thus launching another alternative for an X11 replacement.

So far, most Linux distros think of Wayland and Mir as experimental technologies, and few systems actually use them as the default, but most observers believe that the new graphics systems will one day see wide adoption. We decided it was time for a closer look at what Wayland and Mir really are, how they work, and how they differ from the venerable X Window System.

One for All

On a system with Wayland, the Wayland compositor runs in the background. When a user clicks on a window, the compositor receives a matching kernel event. The compositor then determines which window the user clicked on. Wayland receives the necessary information faster than the X server. In contrast to its ancestors, the Wayland compositor always knows where the windows are located and what transformations it has applied to the windows. After finding the right window, the compositor sends the event to the associated application (Figure 2).

Figure 2: In contrast to the X Window System shown in Figure 1, Wayland merges the X server and compositor to form the Wayland compositor.

Programs that run on Wayland are known as Wayland clients. Clients need to draw their window content themselves – either manually, or using libraries like GTK+, or using hardware-accelerated interfaces such as OpenGL. After doing so, the client notifies the compositor, which puts together the contents of the screen and triggers the display.

In the old X Window System, a window manager draws borders and other decorations around the individual windows. The Wayland specification does not clarify the responsibilities. Usually, the compositor decorates the windows with frames (server side decoration).

Name Confusion

The compositor and clients use a network protocol by the name of Wayland to talk to one another. In practice, developers also refer to the complete system of clients and the compositor as Wayland. The compositor and clients exchange their messages via Unix sockets. The name of the endpoint is found in the environment variable WAYLAND_DISPLAY and is usually wayland 0. Messages are always sent asynchronously, which translates to speed increases.

To make it easier for programmers to work on clients and the compositor, the Wayland developers provide the libwayland-client and libwayland-server C libraries (Figure 3). Confusingly, this reference implementation of the network protocol also goes by the name of Wayland. The source code of both libraries is available from the project page in the form of the wayland package [1].

Figure 3: Under Wayland, the compositor and clients use established libraries and kernel interfaces. Confusing: The reference implementation of the network protocol is also named Wayland.

The package also includes an XML file by the name of wayland.xml, which contains a formal definition of the permissible messages.

The Wayland scanner from the source package generates the two C libraries (semi-) automatically from the XML file. If you compile the libraries according to the guide, you remain blissfully ignorant of them.

Independent

Clients need to render their own window content. To do so, the client first requests a memory area from the compositor that both elements can access, which is known as a shared memory buffer (SMB). The client pushes the new window content into the SMB. It then tells the compositor that something has changed, which rectangular section is affected, and in which buffer the window content is located. The compositor then grabs the buffer and arranges the stored image material, along with the other windows, to create a work of art.

Although the client must request the buffer from the compositor, the client is responsible for managing the buffer. It can use a new buffer for each drawing operation or request multiple buffers in advance and then switch back and forth between them.

You can avoid the cumbersome task of working with buffers and the libwayland-client library if you develop your programs with SDL, Clutter, Cairo, GTK+ 3, or Qt 5. These popular graphics libraries or GUI frameworks now support Wayland out of the box.

In the case of GTK+ 3 and Qt 5, the users can decide later on whether to use X11 or Wayland for the display. GTK+ 3 offers the environment variable GDK_BACKEND [3] for this purpose; for QT 5, the environment variable goes by the name of QT_QPA_PLATFORM. In addition, Qt programs support the platform command-line parameter to enforce output via one of the two systems.

In addition to the listed options, clients can also hardware-accelerate the window output using OpenGL or OpenGL ES. The client first allocates a buffer directly on the video card using the EGL interface. Like OpenGL, EGL [4] comes from the Khronos group, and it mediates between the window system – in this case Wayland – and the OpenGL and OpenGL graphics libraries.

Once the client has drawn the contents of its window, it hands control over to the compositor. The compositor then composes the screen content with EGL, OpenGL, or the OpenGL successor Vulkan [5].