Wayland to replace the X Window System

In a previous post, we learned why the X Window System is one of the most successful open source projects in history, it's time to replace it with a new solution for the Linux graphical environment. In the same article, we will find out what Wayland is - the most likely candidate to replace X.

Glossary Wayland

It makes sense to first deal with some definitions and terminology.

Compositor - Composite window manager is one of the central concepts of Wayland and around it. Nowhere is it really defined what it is, but this term is used as if everyone knows everything. In any case, in Russian I did not find any definition. Fortunately, the examples clarify the point. Here is a list of them in the context of Wayland :

• KWin - KDE display server,
• Mutter - GNOME display server,
• Weston- reference composite manager for Wayland ,
• Enlightenment - graphical desktop shell,
• Marco - window manager MATE.

As we can see, this is nothing more than the window managers we know, although not really. These are display servers , which nevertheless differ in functionality from WM. The former interact with user input-output devices, with hardware, and control the data flow of client programs. The second ones are responsible for displaying windows and their placement in the window interface system.

Wikipedia page illustration .

But to say that there is a clear semantic and terminological boundary between all these servers, managers and composerswould be a hoax. For example, it KWinis both a display server and WM, just like it is Enlightenment. For this article, a composite window manager (abbreviated as COM) and a display server will be equivalent to the term Compositor .

$ eix -c enlightenment; eix -ce kwin
[N] x11-wm/enlightenment (1.0.17): Enlightenment Window Manager (e16)
[I] kde-plasma/kwin (5.8.5(5)@01.02.2017): KDE window manager

A composite manager, a display server, may also be referred to as a composite window manager .

$ eix -c mutter
[N] x11-wm/mutter (3.20.3): GNOME 3 compositing window manager based on Clutter

Weston - The Wayland Protocol Reference Display Server. Recently , the second version of COM came out .
EGL is a platform-independent software equivalent of OpenGL GLX / AGL / WGL, developed by the Khronos Group. EGL provides an infrastructure kit for quick application setup and scene initialization.

• Mechanisms for creating rendering areas (window, pixel map, pixel buffer) so that client APIs can draw and separate them on them.
• Creating a graphical context for client APIs.
• Rendering synchronization by client APIs and native platform rendering APIs.

EGL unlike GLX / AIGLX can only perform direct rendering , in which applications through DRI2 / DRI3 can safely and quickly access video equipment bypassing the X server.

GLES - A subset of OpenGL designed specifically for embedded systems - mobile phones, tablets, computers, game consoles.

Wayland Architecture

So what is Wayland ? As in the case of the X Window System, we are talking about the protocol and its implementation. Wayland is a protocol of interaction between COM and clients, as well as its library implementation in C. The client can be a user application, an X server, or another display server.

• Purpose: To radically simplify the graphical environment of Linux compared to X.
• Uses Unix Domain Sockets, no network transparency.
• Mainly uses EGL and DRI.
• I / O devices are controlled entirely from the kernel.
• Buffer allocation and rendering entirely on the client side.

At the lowest level of the protocol, the client and COM synchronize messages, exchange ordered objects using IPC libraries libwayland-clientand libwayland-server. At this level, there are no ways to control the window interface — only messages transmitted through Unix Domain Sockets, objects, and events.

+-------------------+           +-------------------+
|                   |           |                   |
| Client            |           | Compositor        |
+-------------------+           +-------------------+
| libwayland-client |           | libwayland-server |
+-------------------+           +--+----------------+
                 |                 |
                 |  Wayland        |
  User space     |  protocol       |
+---------------------------------------------------+
| Kernel space   |       +---+     |                |
|                +------>|IPC|<----+                |
|                        +---+                      |
+---------------------------------------------------+

Objects created by the client are represented by a structure wl_proxycontaining the identifier of the message transmitted to the server through the socket, voida data pointer and a pointer to a static object wl_interface. Messages are sent using the structure wl_proxy_marshal.

static inline void
wl_surface_attach(struct wl_surface *wl_surface, struct wl_buffer *buffer, int32_t x, int32_t y)
{
  wl_proxy_marshal((struct wl_proxy *) wl_surface, WL_SURFACE_ATTACH, buffer, x, y);
}

Wayland is an asynchronous protocol, object-oriented and aimed at processing messages. The message transmitted from the client to the server is a call , and in the opposite direction, an event . Each message consists of 32-bit words, the values ​​are presented in order of host bytes.

Illustration from the Wayland homepage .

How do these blocks interact?

1. The kernel registers the event and sends it to COM.
2. In his scene graph, COM finds a window to which this event should be delivered and he knows exactly what type of transformation should be applied to the object. KOM translates screen coordinates to local for a given window by reverse transformation.
3. The client processes the event by updating the area of ​​the graphical interface, renders and notifies the COM about the changes.
4. KOM collects from clients all data on territories in which the contents of the dependent buffer are different from the surface area, and then re-arranges the screen. Further, the display server loads the new page using ioctl call addressed KMS.

And how is the rendering? Clients independently draw their windows in a separate buffer, passing information about updates to the display server, which combines the contents of the buffers of different applications to form the final output, taking into account possible nuances such as window overlap and transparency.

Wayland vs. X

So how is Wayland still different for the better ? Let's go over the main points to understand why everything was up to. For me personally, the fact of the lack of a configuration file is enough xorg.conf. However, the fruitful influence of direct hands on editing this file has already been discussed in the comments to the previous post.

1. Versions permeate the protocol from top to bottom. Each interface has one version or another; each protocol object implements a specific version of its interface. This eliminates the situation of constant conflicts of versions X due to the fact that versioning is tied to clients, and not to the connection. If the application supports one version of the extension, toolkit another and X11 third, then it is impossible to predict what the application will receive in the end.
2. Working with input devices in Wayland is very similar to Xinput 2.2minus the heap of obsolete code and Master / Slave order between input devices. A global object seat, i.e. a place, defines a group of input devices, including a mouse, keyboard, and touch screen. The nightmarish problems with multi-touch will disappear.
3. Wayland , unlike X, does not have a rendering API, and therefore does not engage in art. All he needs is buffers full of client pixels, and then he conducts them so that application A does not mess up anything in the buffers containing images of application B. Customers determine which pixels will be in the buffers and in response to the image that will be displayed on screen!

1. Wayland is minimal. Recall that X was a state in the state, with a full set of kernel functions for the OS, and even had its own print server, after someone had the idea of ​​adding print support for glxgears. So, all of this in Wayland is not and never will be. The main burden is borne by customers and this is glorious, since they themselves will not want to bend under the burden of compatibility of UI elements 30 years ago.
2. Mandatory layout (compositing). This does not mean that 3D effects are inevitable. Layout means a seamless image that does not shake or jump. Wayland's motto isnot a single breakevery frame is beautiful . Each pixel in its place, as the client conceived and implemented. For comparison, how does the X Composite extension work? For desktop effects, the GL layout quite pulls the strap, but when watching a video in a browser, problems immediately begin. The browser window and the pane with the flash player are not synchronized in any way. For them, events are handled independently and one can only hope that the two threads will not run far in time. For this reason, while scrolling the window with an active Youtube video, the image may jump and twitch.
3. No fonts on the server, the clients themselves will cope. Already cope.
4. X suffers unconsciousness, which is why the notorious one is needed xfree86.conf/xorg.confto remember the settings for two or more monitors, graphic cards. We will not be bored without these killer features in the coming post-X era?

Erroneous Judgments About X and Wayland

There are a number of persistently incorrect opinions on this subject.

• X Unixway. Well, how can I say, do one thing to the principle , but do it well Unix cumbersome omnivorous X clearly contradicts.
• Network transparency X. Yes, it was, it was, but it has been since X moved to DRI2shared memory, and both are not able to work on the network. Everything spins on a slow synchronous Xlib, and the exhaust is obtained as with VNC, if not worse.
• Wayland is written by those who do not understand X. Nothing is further from the truth - it is written by those developers of X who are tired of constantly patching holes and fixing crutches. A good example is Daniel Stone, one of three people on earth who know exactly how keyboard bindings work on X.
• Wayland imposes 3D. This is not so, only layout is required. This has already been said above.

Used materials and useful links

The Wayland Situation: Facts About X vs. Wayland
Development status of an X11 application layer on top of Wayland Wayland
documentation