What is Wayland?

In the Wayland architecture diagram, the most significant feature is that it reuses all Linux kernel graphics and input/output technologies: kms and evdev, so the supported drivers can be used directly; wayland does not have the traditional server/client mode, but is replaced by compositor/client. This is not just a new name, but the specific differences will be discussed later;

Remember the Application Scenario "click the refresh button of Firefox" in the previous article? In Wayland, all the processes are as follows:

The kernel receives the mouse message and forwards it to Wayland compositor after processing, just as it previously sent to X server. After receiving the message, compositor can immediately know which window should receive the message, because it is the control center, which can grasp the hierarchical relationship and animation effect of the window, therefore, it knows to whom the mouse clicking information generated by the coordinates should be sent. In this way, compositor sends the mouse clicking information to Firefox. Firefox received the message. In this case, if it is in X Window, Firefox will request the X server to draw the effect of the button being pressed. However, in Wayland, Firefox can draw on its own without the need to request

Yes! This is legendary: Direct render )! Regardless of client rendering, Wayland becomes very simple and efficient! After Firefox draws the button state, it only needs to notify compositor that a certain area has been updated. After receiving the information sent from Firefox, compositor reassembles the updated area to present the final desktop effect to the user. This process mainly deals with the kernel and graphics driver. Is the entire process very natural and simple?

The conclusion is as follows:

Wayland's "direct rendering architecture" completely ends the tedious process of rendering images by traditional X Windows, which requires constant requests to the server, confirmation, and re-drawing, theoretically, the response speed has experienced explosive growth. Wayland has fundamentally eliminated the repetitive work of "SERVER + compositor" and only needs a "compositor" synthesizer. Compostior is the "X Server" on Wayland, but it is more pure. It is not like X server, like a large parent, and it needs to take care of everything. Compositor only does what to do and simplifies the above process into a task:

Processes evdev information based on the Wayland protocol, and notifies the client (that is, the application) to respond to related events (as for how the application wants to respond, compositor does not need to be asked ); after receiving the status update from the client, recombine the image or manage the new layout. You realize that the role of Wayland compositor is like "X Server" + "Window Manager", but it only serves as a part. I think you can already imagine how simple and efficient the Wayland architecture is. It solves the problems that have been accumulated over the years and solved through "expansion.