Wayland

Wayland is a protocol for a compositing window system, designed to be a modern replacement for the X Window System (commonly known as X11). It aims to provide a simpler, more efficient and secure interface between display servers and client applications. Wayland was created by Kristian Høgsberg with the goal of offering better performance, security and ease of use over X11.

I could put this story into the Desktop section. Wayland is the program that produces the desktop you see on your computer screen. It is such an important, low-level part of Linux, that I put it here in the Linux section.

Protocol vs. Implementation

Wayland defines a protocol for how clients (applications) communicate with the server (compositor). It specifies the messages that can be sent between them. There are a variety of implementations of the Wayland protocol. The most common server implementation is called Weston, but many desktop environments like GNOME (with Mutter), KDE (with KWin), or Sway have their own compositors.

The Wayland compositor is the central piece of software that handles the display, input and overall management of the graphical environment. Unlike X11, where the server manages windows but doesn’t necessarily control composition, in Wayland, the compositor does everything.

Compositors can render directly to the GPU, potentially offloading work from the CPU. It manages input from devices like keyboards, mice and touchscreens. Controls window placement, transitions and decorations.

Clients are applications that run under Wayland. Clients communicate with the compositor via the Wayland protocol to request screen space, handle input and draw User Interfaces.

How Wayland Works

When an application starts, it connects to the Wayland compositor via a Unix socket. This connection allows the application to become a client of the Wayland system. Clients create and manage buffers (areas of memory) where they render their content. These buffers are typically managed by the GPU through protocols like EGL or DRM. Clients then ask the compositor to present these buffers on the screen.

A client creates a “surface” which represents a window. This surface is where the client’s content will be displayed. The compositor decides how, where and when these surfaces are rendered. Clients and the compositor exchange messages. Clients can request to create surfaces, send input events or ask to redraw. The compositor sends events like keyboard input, pointer movements or window resizing to the client. Input events are sent directly to the client that has focus, reducing the security risks associated with X11’s global input broadcast.

Wayland has a simple security model where clients can only interact with the compositor directly. This reduces the attack surface as there is no concept of other clients accessing each other’s data or the server directly.

The compositor renders all surfaces at once, creating a composite image. It can use hardware acceleration for better performance, leading to smoother transitions and effects. The base Wayland protocol can be extended with additional protocols for more advanced features like drag and drop, screen sharing or advanced input methods.

Advantages Over X11

Wayland uses direct rendering, less overhead and better use of GPU capabilities improving performance. No shared memory or input broadcasting means a tighter security model. The Wayland protocol is simpler, leading to easier implementations and maintenance.

Challenges

While improving, not all features of X11 are replicated in Wayland yet, leading to some applications not working as expected. Many applications still assume they’re running under X11, requiring adaptations or using compatibility layers like XWayland.

XWayland

For backward compatibility, many Wayland compositors run an X server (XWayland) that allows running X11 applications under Wayland.

In essence, Wayland streamlines the relationship between applications and the display server, offering a cleaner, more secure environment for desktop computing, although its full adoption is still a work in progress in the broader Linux ecosystem.

Sources:
Grok