The X Window System has been implemented in Linux since the beginning and manages the graphical user interface of most Linux distributions, although some embedded systems do without X11 and use lightweight graphics libraries such as Nano-X, SDL, DirectFB etc…
X11 is invisible to the end-user but does all the hard work needed to have Gnome, KDE and Unity user interfaces work properly and smoothly.
However, in recent years, GNU/Linux desktop graphics has moved from having numerous rendering APIs talking to the X server which manages everything towards putting the Linux kernel in the middle with direct rending (e.g. OpenGL, VDPAU/VAAPI) with window systems taking the backstage. This new architecture provides a much-simplified graphics system offering more flexibility and better performance.
The problem is that the X Window System is highly complex, a complexity that is not really needed with the newest version of the kernel. That’s where Wayland protocol comes into play. Wayland is described as follows:
Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.
Here’s a graphical comparison between X11 and Wayland.
|
|
|
Without going into details, Wayland is clearly less complex than X11 as it gets rid off the middle man (the X server) and the number of messages as well as inter-process communication complexity are reduced.
Contrary to X11, Wayland uses direct rendering (DRI2), where the client and the server share a video memory buffer. The client links to a rendering library such as OpenGL that knows how to program the hardware and renders directly into the buffer. The compositor in turn can take the buffer and use it as a texture when it composites the desktop. After the initial setup, the client only needs to tell the compositor which buffer to use and when and where it has rendered new content into it.
Wayland can be backward compatible with X clients, so that all those existing applications won’t have to be rewritten. This will however require X server modifications so that it communicates with the Wayland compositor.
The first release of Wayland (and Weston) has been announced on the 9th of February 2012 with version 0.85. Version 1.0 is expected to be released in H2 2012. Wayland is the protocol and IPC mechanism while Weston is the reference compositor implementation.
The source code for both Wayland and Weston 0.85 libraries can be downloaded at:
|
1 2 |
<a href="http://wayland.freedesktop.org/releases/wayland-0.85.0.tar.xz">http://wayland.freedesktop.org/releases/wayland-0.85.0.tar.xz</a> <a href="http://wayland.freedesktop.org/releases/weston-0.85.0.tar.xz">http://wayland.freedesktop.org/releases/weston-0.85.0.tar.xz</a> |
Ubuntu (Canonical), Fedora and KDE development teams have already planned to replace X11 by Wayland in future versions. Canonical is also planning to help port Compiz to OpenGL ES and Wayland is on the high priority list at Linaro for ARM support although it still needs approval.
For further details, you can visit Wayland page at freedesktop.org.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
