Wayland to replace the X Window System

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

Wayland Glossary

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, I did not find any definition in Russian. Fortunately, examples clarify the essence of the matter. Here is a list of them in the context of Wayland :

• KWin - KDE Display Server,
• Mutter is the GNOME display server,
• Weston - the reference composite manager for Wayland ,
• Enlightenment - desktop GUI,
• Marco is the MATE window manager.

As we can see, this is nothing more than window managers familiar to us, although in fact not. These are display servers , which all the same differ in their functionality from WM. The former interact with user input / output devices, with iron, and control the flow of client program data. The latter are responsible for displaying windows and placing them in the window interface system.

Illustration from wikipedia page .

But to say that there is a clear semantic and terminological boundary between all these servers, managers and composers , it would be a hoax. For example, KWin is both a display server and WM, just like Enlightenment . For this article, a composite window manager (abbreviated as KOM) 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, or 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 - Reference Wayland Protocol Display Server. Recently came the second version of the COM.
EGL is the platform-independent equivalent of the OpenGL GLX / AGL / WGL software interfaces, developed by the Khronos Group. EGL provides an infrastructure set 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 onto them.
• Creating a graphical context for client APIs.
• Synchronization of rendering by client APIs as well as native rendering APIs of the platform.

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 with the X Window System, this is a protocol and its implementation. Wayland is a protocol for interaction between COM and clients, as well as its library implementation in C. The client can be a custom application, an X server, or another display server.

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

At the lowest level of the protocol, the client and KOM synchronize messages, exchange ordered objects using the IPC libraries libwayland-client and libwayland-server . At this level, the methods for controlling the window interface are not defined - only messages transmitted via 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 the wl_proxy structure, which contains the message identifier transmitted to the server via a socket, the void data pointer, and a pointer to the static wl_interface object. Messages are sent using the wl_proxy_marshal structure.

 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, object-oriented protocol designed to handle messages. The message sent 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 the order of the host bytes.

Illustration from the main page of Wayland .

How do these blocks interact?

1. The kernel registers an event and sends a COM to it.
2. KOM in its scene graph finds the 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 into local ones for a given window by inverse transformation.
3. The client, fulfills the event, updating the graphical interface, renders and notifies the COM about the changes.
4. The CLC collects from the clients all the data for the territories in which the contents of the dependent buffer differ from the surface area, and then rearranges the screen. Next, the display server loads the new page, using the ioctl call to the addressed KMS.

How does the rendering work? Clients independently render 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 overlapping windows and transparency.

Wayland vs. X

So why is Wayland different for the better? Let's go over the main points in order to understand for what it was all going. For me personally, it’s enough that the xorg.conf configuration file is missing. 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 or another version, each protocol object implements a specific version of its interface. This eliminates the situation with the constant conflicts of versions of X due to the fact that version negotiation is tied to clients and not to the connection. If the application supports one version of the extension, the toolkit is another and X11 is the third, then it is impossible to predict what the application will receive.
2. Working with input devices in Wayland is very similar to Xinput 2.2 minus the Xinput 2.2 obsolete code and Master / Slave order between input devices. The global object is a seat , i.e. a place defines a group of input devices, including a mouse, keyboard, and a touch screen. The nightmarish multitouch problems will disappear.
3. Wayland, in contrast to X, does not have an API for rendering, and therefore does not deal with arts. All he needs is buffers full of client pixels, and then he conducts them so that Appendix A does not spoil anything in the buffers containing the pictures of Appendix B. Clients determine which pixels are in the buffers and are responsible for the image that will be displayed on screen!

1. Wayland is minimal. Recall what X was a state in a state, with a full set of OS kernel functions, and even had its own print server, after someone got the idea to add print support for glxgears. So, all this in Wayland is not and never will be. Clients are carrying the main burden on themselves, and this is great, since they themselves will not want to bend under the weight of compatibility of UI elements 30 years ago.
2. Mandatory compositing. This does not mean that 3D effects are inevitable. Layout means a seamless image that does not shake or jump. Wayland's motto is not a single gap every 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 you watch the video in the browser, problems immediately begin. The browser window and the subwindow with the flash player are not synchronized at all. For them, events are processed independently and it remains only to hope that the two streams will not diverge significantly in time. For this reason, while scrolling through the window with the active Youtube video, the image may jump and twitch.
3. No fonts on the server, customers can handle it. Already cope.
4. X suffers from unconsciousness, which is why the notorious xfree86.conf/xorg.conf is needed to remember the settings for two or more monitors, graphic cards. We are not going to be bored without these killer features in the coming post-X era?

Wrong judgments about X and Wayland

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

• X is unix. Well, how to say, do one thing to the principle , but do it well. Unix cumbersome omnivorous X clearly contradicts.
• Network transparency X. Yes, it was-was, but it has passed since X moved to DRI2 and shared memory, and both cannot work on the network. Everything revolves on the 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 farther from the truth - it is written by those X developers who are tired of constantly patching holes and repairing crutches. A good example is Daniel Stone, one of three people on earth who know exactly how the X keyboard binding works.
• Wayland imposes 3D. It is not, only the layout is required. This has already been said above.

Used materials and useful links

The Wayland Situation: Facts About X vs. Wayland
Layer development status for running X11 applications over Wayland
Wayland Documentation