From Xorg to Wayland

Introduction

The landscape of Linux desktop environments has been undergoing a major transformation, with the advent of Wayland as a promising successor to the long-standing Xorg display server. This shift has brought about significant changes in popular desktop environments such as Plasma and GNOME. In this post, we explore the state of the art in terms of Wayland’s impact on these environments and how they compare to Xorg, as well as explaining my path towards moving from Xorg to Wayland, steps I took, mistakes I made, and learnings I’ve got.

But, first of all, why?

Basically, and I’m personal case, to follow the hype. As simple as that, no shame. There was no real need to leave my perfectly working Xorg environment just yet. But it was a great oportunity to get out of my confort zone and do some experimentation on my linux box, and maybe learn a couple of things.

So now that that’s out of the picture, let’s deep down on my path through this transition.

State of the art

Wayland: The Future Unfolding

Wayland represents a modern display protocol designed to overcome the limitations and shortcomings of Xorg, which had been the de facto standard for decades. Its main objective is to provide a secure, efficient, and flexible foundation for graphical environments. By taking advantage of the latest technologies and design principles, Wayland aims to offer smoother rendering, better performance, and improved security.

Plasma: Navigating the Wayland Path

The KDE Plasma desktop environment has been actively working towards embracing Wayland as the default display server. While Plasma has been historically associated with Xorg, recent iterations have made significant strides in Wayland compatibility. Users can now experience a native Wayland session with Plasma, benefiting from reduced input latency, improved multi-monitor support, and an overall more fluid experience. However, due to the inherent complexity of the transition, some legacy Xorg applications may still encounter compatibility issues.

GNOME: Pioneering the Wayland Experience

GNOME, one of the most popular Linux desktop environments, has been a front-runner in adopting Wayland as its primary display server. The GNOME Shell provides a seamless Wayland experience with full support for features such as fractional scaling, touchscreen gestures, and high-DPI displays. Thanks to GNOME’s early commitment to Wayland, many of its core applications have been optimized to work flawlessly under this new protocol. While Wayland support in GNOME is mature, occasional compatibility challenges with Xorg-dependent applications may still arise.

BTW, I use Arch

Arch Linux

In order to install Wayland, I just installed the following packages (assuming you have a Xorg Plasma working installation):

  • wayland
  • egl-wayland: because I have an NVidia Optimus card in my laptop
  • plasma-wayland-session: so sddm gives you the option to log into Plasma on Wayland

One of the dependencies you’ll get as a result of installing the packages above is:

  • xorg-xwayland: a fallback solution to run X11 applications within a Wayland environment

Which will be vital, at the current moment, to be able to run applications that are not 100% supported yet, or that you’re experiencinig issues with.

Once these packages are installed, just restart the graphical environment (sddm) or reboot the computer and log in back into Plasma, without forgetting to switch to the Plasma (Wayland) session in SDDM. And if everything went all right, you are now using Wayland. One way to quickly confirm that is to open a terminal and run the following command:

$ echo $XDG_SESSION_TYPE

If you get ‘wayland’ back, you’ve got your confirmation. Congratulations!

There is one caveat though: at this moment not all the applications you may be using have support for Wayland yet, that’s where xwayland comes into the picture. One really nice debug tool I’ve found that lets you inspect which applications are running natively on Wayland is the following:

$ qdbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole

which obviously is only available on Plasma.

Issue 1 - Longer application loading time

Usually my first action upon logging in is to open a terminal. alacritty is my terminal of choice, because:

  • it’s quite fast
  • cross-platform
  • configurable via YAML
  • it’s written in Rust

As usual, I pressed Ctrl + Alt + t to open a new terminal and… anda.. and… there it goes, it works! But it took a while… let’s try again… … … same :-(

Maybe it’s an issue with Alacritty, let’s check other apps like:

  • konsole: fast
  • dolphin: slower than usual
  • maybe okular: too long for such a small app
  • firefox: couldn’t tell if there was an actual difference (there wasn’t) - don’t forget to set up MOZ_ENABLE_WAYLAND=1 in your environment, otherwise it will be running under XWayland

And I’m talking a huge difference in loading times: from almost instantaneous loads under Xorg, to having to wait 2–3 seconds for the app just to appear. That can’t be right, people are for sure not going by with this huge performance difference, but… I can’t find any comment / post talking about this issue… :-(

Time to deep dive into the issue.

XWayland

Wayland

Starting with alacritty, I searched for people reporting the same issue, and luckily, I found some. Their solution was to use something call XWayland.

XWayland is a tool that allows you to run non-Wayland apps on a Wayland environment. And you can use this tool on an app-by-app basis, which is really convenient. And that’s exactly what I did, as simple as setting up an empty value to WAYLAND_DISPLAY variable for alacritty and voilà, back to a blazingly-fast terminal, as it used to be.

Not really happy with the approach, but at this point I just wanted to focus on getting the rest of the apps ready, so I can use Wayland as I used to use Xorg. Something was not right, but at this point didn’t know what yet.

Digging on the dependencies that paru (or pacman) installed, I found one that was a little bit off: egl-wayland. Based on Arch’s wiki, this package provides EGLStreams API for NVidia GPUs. I have an internal NVidia GPU, but I wasn’t planning on using it, so I uninstalled this package (which also uninstalled nouveau, NVidia GPU’s opensource driver).

And after restarting the desktop environment, guess what? Everything was snappy and zero delays during start up. Even alacritty was fast running under Wayland without having to rely on XWayland.

Nice :-)

Issue #2: Steam requires Vulkan and EGL

I don’t game much, but I like to have Steam and a couple of games ready for whenever I want to disconnect a little bit, so, given that this kind of applications are quite graphic intensive, I decided to try it out under Wayland.

But it wasn’t there! It got uninstalled (and I didn’t notice it, shame on me) when I removed egl-wayland.

How could I resolve this conflict? Do I install back egl-wayland back, so I get back Steam and everything gets slower again, or should I ditch out gaming alltogether? That can’t be the current state of Wayland!?! I know the major distros are fully moving into Wayland, so this cannot be a general issue.

This needed more digging out across forums.

Wayland and NVidia: opensource or not?

NVidia

I decided to install Steam again, and with it, egl-wayland, but this time something caught my attention during the installation: paru was asking me which NVidia drivers I wanted to install, the closed-source officials, or the opensource alternative nouveau.

I got this question during the first install attempt, and I decided to go for the opensource alternative wihout thinking it twice. But this time, after some reading about people complaining on some performance issues with nouveau, I decided to try the official drivers instead. So after the installation was done, I rebooted the computer, just to be sure that all the kernel modules are loaded properly, and logged back into Plasma.

And, oh wow, everything was running as smoothly as it was running before on Xorg. And no XWayland required at all!

Turns out my issue was on ’nouveau’ and not ’egl-wayland’.

Issue #3: Clipboard and Neovim

Neovim

So that was it, I had a nice, fully Wayland native, Plasma desktop for me to use :-D

And so I did for a couple of days, and then I noticed a small nuance: I wasn’t able to copy from or to the system’s clipboard from neovim. Ok, this must be a minor one, for sure someone in the amazing Neovim community has solved thi issues.

Yep, easy one: just installed wl-clipboard and the issue was gone.

Conclusion

Not everything was smooth, but that’s how usually works on linux, and the beauty of it, because thanks to these issues, I learned a lot about Wayland and how the different desktop environments and window managers are transitioning to it.

I’m planning on gathering some metrics regarding the usage (or not) of the integrated Nvidia card, now that I’m using the official drivers. So keep an eye for my next post, coming soon!

(Psst! You can follow me on Mastodon or subscribe to my RSS feed not to miss it)