GNOME is (Gradually!) Dropping X11

[INTRO]

Let’s get straight to the point: from now on, the GNOME development is doing its first steps towards deprecating… drumroll… the X11 Session. In fact, as you can see in merge requests 98 and 99 [show pics along], the ones interested in the change we are talking about, the gnome-xorg.desktop file is being removed along with the gnome-session-x11, systemd targets and the whole code related to them.

However there’s no need to panic, because, even if the 98 merge request lands upstream, X11 functionalities will still be there. They can simply be restored by reinstalling the files in the appropriate location, and that’s because in this MR only desktop files and targets are being removed. Basically nothing is important enough to block this as it's an important next step to make sure developers understand that GNOME won't support X11 for much longer. So the plan is to push this change in the near future.

The 99 MR, though, cannot be reversed because it deletes a significant part of the X11 implementation in mutter. As a result, there is a significant debate surrounding this issue. People are worried that it could cause problems with the DE, so one idea is to postpone its implementation for a few years.

Let’s dive into this discussion.

[WAYLAND OVER X11]

But, why are they dropping it all of a sudden? Actually, if you take a look at this article (https://wiki.gnome.org/Initiatives/Wayland) on Gnome’s website, it’s clear that their intention to support Wayland over X11 is deeply rooted back in 2017.

They stated: “X is showing its age - it has been kept alive for a very long time by means of adding more and more extensions to the core protocol. The Wayland protocol is a much leaner definition of a modern compositing-based display system. We don't need to carry around many obsolete parts of the X protocol any longer. Some problematic parts of the X protocol, such as grabs, are simply not present under Wayland, which avoids a whole class of problems.”

As we all know “less code means less vulnerability", so this decision would make the codebase easier to maintain and improve, which would lead - ideally - to a more stable and feature-rich GNOME experience. Mutter developers could focus on adding new features such as HDR and better multi-monitor support, that sort of things.

Many might argue that a lot of Xorg software is not capable of running under Wayland, but that's not the case. There is a good piece of software, XWayland, that does just that. It runs Xorg specific software under Wayland, so applications that depend on the old protocol can still run, but not without problems, as some programs don't really run well under XWayland, or might even be seriously broken.

[X11 OVER WAYLAND]

But how come that these two ways of interpreting the role of a display server protocol cause such differences? Let’s make that clear.

A display server is a program that coordinates the input and output of its users with the operating system, hardware, and other users. It communicates using the display server protocol. This protocol is crucial in any graphical user interface, specifically the windowing system.

In X11, the window manager of the desktop environment puts windows where they should be and makes the title bars and frames. In Wayland, the display server and the window manager are being handled by the Wayland Compositor.

In order to create the window needed for the application to render properly, the client's applications must talk to the X11 server before the compositor creates it. This system is dependable, but it operates slowly compared to modern standards and newer systems like Wayland.

On the other hand, Wayland chooses to rely on client-side rendering, where the application talks directly to the screen handler without a middleman server. This approach can reduce load times and facilitate easier implementation, thanks to Wayland's simplified codebase.

Wayland also offers support for sandboxing and isolation which makes it more difficult for malicious applications to interfere with the other applications on the system.

[CRITIQUES TOWARDS 98/99 MERGE REQUESTS]

However, GNOME project managers are in a tough spot, because not everyone agrees with these requests and their concerns are about what we talked about earlier. They fear the inconvenience of missing some features in Wayland that are well implemented in Xorg or having some incompatibility between software.

So there's a large pool of people running GNOME desktops every day begging not to drop X11 support for a while. Among the comments on the two merge requests mentioned earlier, there are more than a few expressing dissatisfaction, showing some problems that could be defined as blockers, something that could stop this MR from passing through.

People are, for example, talking about accessibility support in the Wayland session. According to these users it lacks some accessibility features users depend on, such as screen reader keyboard shortcuts. There is an ongoing effort to achieve this, but sadly the fact is that today, accessibility still works better on the X11 session.

Or even artists demand to be heard, as the GIMP maintainer says:

“We are still ready to accept the inconveniences of a less optimal support over completely dropping the support. Because in one case, we can at least still use GNOME, whereas in the other, we are forced to use something else. “ [on screen]

Or:

“X11 still has a slew of features that on Wayland are either incomplete or are outright nonexistent.”

And:

“There are still issues with remote streaming applications from wayland, and gnome remote desktop isn't a solution for everybody. If I could do the same thing in Wayland with almost the same performance as X11 I would be happy to use Wayland, but sadly it's still not the case.”

So, this is a very serious topic for those who rely on X11 for some features that are not so good on Wayland.

Some may feel that these concerns are excessive. If you are not well-versed in Gnome + Wayland, it may come as a surprise that unresolved problems can cause users to switch to X11.

But the situation is even worse if you happen to use NVIDIA drivers. Proprietary NVIDIA drivers do not offer the same user space API as their open source counterparts. While the open-source drivers for Intel and AMD facilitate the widely-utilised GBM API, Nvidia opts for the less commonly adopted EGLStreams API. Only GNOME and KDE desktops or compositors fully accommodate EGLStreams. GBM API support has only been added by NVIDIA starting from driver 495; however, the situation is not as smooth as it should be.

The same happens with KDE, in fact it is not possible to configure it if the NVIDIA driver is older than version 495.44, because KWin is no longer compatible with previous versions.

Another issue worth mentioning is Mutter’s situation. Mutter is a Wayland display server, a X11 window manager and compositor library. It juggles between two different roles depending on which protocol is used. When used as a Wayland display server, it runs on top of KMS and libinput. It implements the compositor side of the Wayland core protocol as well as various protocol extensions. When used on top of Xorg, on the other hand, it acts as a X11 window manager and compositing manager.

[FEDORA]

GNOME itself isn’t the only one deprecating its X11 session: Fedora is also planning to drop Xorg support on either KDE Plasma 6 and GNOME for its 40th release. They, in fact, stated in a proposal:

"Wayland has been our default session for a long time and has matured considerably. At the same time, the X11 session isn't getting the testing it needs, and is an additional resource burden."

So now we know for a fact that Fedora 40 will be shipped only with Wayland support, and that's HUGE news, ‘cause that would only be the start of a chain reaction. However, it’s worth to note that the support of XWayland will not be interrupted, and it will be possible to execute X11 software on Plasma Wayland.

[KDE SITUATION]

Speaking of KDE… how does it fit into this context? As you can read on KDE website, the aim is to be able to run the same binaries under both X11 and Wayland. But I have to say, the KDE community is trying hard to locate and resolve the Wayland problems that cause a worse user experience than X11.

In particular, Plasma needs Wayland support as we are hitting the limitations of X all the time. We are aware that the X protocol was created for older use cases, and Wayland will allow us to composite the screen in the most useful way.

Considering that KWin was created as an X11 Window Manager and eventually developed as an X11 compositor, it seems reasonable to ask: why not build a new Wayland compositor entirely from scratch? The majority of KWin is X11 independent.

KWin is a very complete and stable window manager. It has been developed for over a decade. Creating a new Wayland compositor with the same capabilities seems almost impossible if started from scratch.

In the last KDE iteration, our focus was on migrating Plasma to the new Wayland display server technology and the process has been quite a challenge. But despite the difficulty of the work, it is proving successful, as Wayland offers several new ways of interacting with your desktop. As you can read in the latest release notes on the official KDE website *[https://kde.org/announcements/plasma/5/5.27.0/ on screen] *the Wayland support in Plasma 5.27 is better than ever, with numerous bug fixes and improvements in reliability!

Also, artists will be pleased to learn that design applications such as Krita can now recognize pen tilt and rotation on drawing tablets. Plasma on Wayland now enables smoother scrolling through long views with its support for high-resolution scroll wheels.

Moreover, it has added the Global Shortcuts portal for a standardised user interface in setting and editing global shortcuts for Wayland apps. Additionally, Plasma on Wayland can now automatically adjust the scale factors of your screens, saving you the hassle of doing it manually.

[OUTRO]

In conclusion, I believe that the benefits of merging this request outweigh the costs. I do think it is good to merge the request to remove Xorg and make GNOME Wayland only, but this should only take place if the transition is gradual and does not burden the user experience. When the time is right, this natural evolution to a more advanced solution will be the better answer for everyone.

I want to add that Wayland is the future of Linux, and it's crucial for GNOME to be at the forefront of this change. By becoming only compatible with Wayland, GNOME can help speed up its use on Linux, and eventually, all application developers will switch to Wayland. This will benefit all Linux users, not solely those who use GNOME]