The Wayland Core protocol is only designed for GNOME and it’s not a good thing [Opinion]

Wayland is a display server system based on the idea of protocols. This means that there is no Wayland display server that clients need to talk to. Instead, Wayland defines a protocol for creating display servers. Any client application programmed to use this protocol can run on any display server (or compositor) that fully supports this protocol. It’s like the world wide web protocols, where any website can run on any browser as long as the browser fully supports web protocols. So you don’t create websites for specific browsers.

It also means that the functions defined in the protocol decide what applications (i.e. clients) can and cannot do. Going back to the website example, if the protocol does not define the necessary functions, it will limit web developers. Take CSS as an example; if it was not available in web protocols, all websites would have been same and boring. The protocol must therefore include all the necessary basics in a way that does not limit developers to a few cases and uses.

When the Wayland developers started defining the protocol, they had to decide what features to include in the protocol. Their decision was to make the protocol as minimal as possible, and composers should create new protocols for their specific use cases if they want to offer more features not included in the main protocol. The main protocol was called Wayland Core Protocoland other protocols are called protocol extensions. All composers are expected to support the main protocol, and they may not support other protocol extensions. This means that applications that depend on certain functionality defined in one of the protocol extensions will not work on all composers.

All of the above is what the developers of Wayland wanted the world of Wayland to be. Now let’s dive into more detail. How much does the Wayland Basic Protocol cost? In other words, what determines what should be in the main protocol and what should not be? In this article, I will give you an answer to this question based on my opinion, which is in turn based on a bunch of simple facts.

My opinion is that Wayland’s Core protocol is designed for GNOME purposes only.

I mean the features that exist in the core Wayland protocol are the bare minimum required for the GNOME desktop and applications to work on Wayland.

This is bad (still in my opinion) because it’s just not good enough for other desktop environments and applications other than GNOME desktop and applications, as I’m going to show you in this article.

1. Basic protocol requires the visual components of the desktop to be drawn by the compositor

First, let’s explain something. In most desktop environments, desktop components (like dock, panel, wallpaper, desktop icons, etc.) are regular clients. For these components to work, they need certain functions to be implemented by the compositor; these functions include:

  • Ability to move the window
  • Ability to tell composer not to draw decorations around said windows.
  • Possibility to keep it above all windows (in the case of the panel) or to keep it below all the windows (in the case of the background).
  • In addition to a few other features.

On X11 these have been defined in the ICCCM spec, which allows X11 clients to tell the composer to do any of the above things. On Wayland, nothing in the basic protocol allows this. This means that desktop environment creators have to draw all of this into the composer.

GNOME is the only desktop that does this, while many other desktops (KDE, XFCE, Lxqt, etc.) draw their components outside of composer (an exception to this is Cinnamon as it started out as a fork of GNOME 3) . The situation is even worse. Apps like plank dock, latte docking station and other independent desktop components cannot exist in Wayland. There are protocol extensions that fix this, and I’ll talk about that later.

In summary, the situation is as follows:

  • Desktop environments should draw everything in composer.
  • Cannot create multi-desktop desktop components like Plank and Latte Dock

2. CSD is implementable, although clients cannot move their window

We previously knew that the core protocol doesn’t define a way for clients to move their windows. So how is CDD implemented? Well there is a function in the protocol which tells the compositor to start dragging the window. So instead of having a function to move the window, which would have been useful in many cases, they resorted to a function only useful for implementing CSD.

3. CSD is a must in Wayland core protocol

On X11, the situation was that apps expect to be decorated by composer (which is SSD) and if they want to decorate themselves (by CSD), they tell composer not to draw their decorations. On Wayland, composers are free to draw their sets if they wish.

The problem is that there is no way (inside the main protocol) for applications to know if they are decorated or not. In other words, customers cannot tell the composer whether they prefer CSD or SSD, which is problematic for both CSD and SSD (in theory). But in practice, GNOME has decided not to decorate customers at all. Applications should therefore assume that they are undecorated due to GNOME’s decision, so they should opt for CSD. Again, there is a protocol extension that fixes this; more on that later.

To sum up

The above three basic protocol facts in a nutshell are:

  1. Desktop components must be drawn by the composer
  2. CDD is essential.
  3. CSD is implementable, although clients cannot move their windows.

Based on these 3 facts, I have concluded my opinion that Wayland’s core protocol is suitable for GNOME purposes only.

And if you wanted some features not available in the main protocol. Wayland or GNOME developers’ answer to this is Wayland’s Protocol Extensions. It just means that composers can provide additional functionality by creating new protocols. The problem with this approach is that it means that some applications may work on some composers and may not work on the rest of the composers (i.e. if they need certain protocol extensions). This may have resulted in severe fragmentation in theory, but the reality is far from worse thanks to the efforts of wlroots project and KDE.

Wlroots mostly saved the day

Wlroots is a library created by Composer Sway developers. It allows developers to easily create Wayland/X11 compositors. Their main focus is Wayland. There are already many composers based on wlroots. What’s interesting though are the protocol extensions that wlroots implements.

Wlroots has many protocol extensions, including:

The LayerShell protocol allows desktop components to be drawn outside of the composer. Which also makes it possible to create independent multi-desktop desktop components. Many projects use this protocol which you can explore in the following repositories:

Also, take a look at GtkLayerShell library. Which is a library for writing Gtk applications with the LayerShell protocol.
Since the LayerShell protocol is not among the core protocol applications that use it on wlroots and KDE based composers, it is not supported only on GNOME.

The second protocol is the xdg-decoration protocol. Made by wlroots and KDE, it allows applications to choose between CSD and SSD.

These protocols work on wlroots composer and KDE. The only obstacle preventing the unification of the Linux desktop is GNOME. They decided not to implement any of these protocol extensions. Which puts all applications that use SSD in a situation where they have to use SSD in media environments and CSD in gnome. The people who really feel the pain are the toolkit developers. To give you more context, take a look at the “CSD initiative” launched by Tobias Bernard of GNOME, and this blog post from Martin’s blog (the developer of kwin). Also, take a look at this problem. The situation is mostly resolved now, that Qt and Gtk still draw CSD on GNOME and use xdg decoration on other environments. However, in my opinion this is not good as it makes the platform less standardized/unified for no good reason. After all, in the future, toolkit developers might decide to just go with CSD to avoid the pain.

The root of all these problems

The root of all this is the decision of the GNOME or Wayland developers to have the kernel as little as possible and to require the creation of protocol extensions.

Imagine if the web worked the same way. This means that websites could not target standardized (minimal) protocols as they are not sufficient and will rely on protocols created by certain browsers. Thus, websites would target specific browsers, not the main protocol. It would have been a nightmare, right? Well, that’s Wayland’s current situation.

What is the solution?

The solution, in my opinion, is to put all these protocol extensions in the main protocol, or it might not be necessary if GNOME implements the protocols above (which is not expected to happen anytime soon.)
Simply put, GNOME is the root cause of the problem, and it can fix the problem if it chooses to.

Author Information: This article was written by It’s FOSS reader Hamza Algohary. Hamza is a computer engineering student and a Linux and open source enthusiast. He also develops applications for the Linux desktop. You can find his work at his GitHub profile.

The views and opinions expressed are those of the authors and do not necessarily reflect the official policy or position of It’s FOSS.

Comments are closed.