I switched to Linux about 1.5 years ago now when replacing my old Macbook Pro with a Tuxedo Infinity Book. I am super happy with the transition, and for the most part my digital life has severely improved as a result of it. There’s one thing in particular though that I haven’t fully grasped or understood despite all the talk about it, and that really has mostly caused confusion on my part, and that is Xorg/X11 (I don’t know the difference…) vs. Wayland.
I started out with Tuxedo OS 1 and 2 running KDE Plasma 5.x.x, and thus have been on X11 for the most part since switching to Linux. I never dared switching to Wayland myself. However, they somewhat recently started offering optional upgrades to Tuxedo OS 3 running KDE Plasma 6 where Wayland is the default, and I took the plunge. The only real difference I noticed was small annoyances that I had to fix. Glitching windows running on XWayland and having to configure some .desktop
-files to force apps to launch natively in Wayland. Apps not showing the correct desktop icons but the generic Wayland logo instead, making Alt+Tabbing a bit more difficult because it is harder to tell applications apart. Annoying smooth scrolling (I don’t want scrolling to have as much friction as polished ice) activated in all kinds of applications that I seem to have to turn off individually. Nothing breaking (though I haven’t dared booting with my Nvidia dGPU yet in fear of breaking something irreversibly…), but I haven’t noticed any improvements either, and I find it a bit frustrating not knowing where to make the necessary changes and always having to search for it seemingly on a case by case basis.
Now for instance I was updating FreeTube to a new version, and the flags I previously added to the ́.desktop’-file suddenly doesn’t work anymore (--enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform-hint=auto
). The application won’t launch unless I remove them, but then it launches under XWayland instead. Not that I have any issues so far running it like that, but I guess I would prefer to run everything natively in Wayland if I can.
So, I’m going for a long explanation just in case, just skip the parts you already know.
tl;dr: Wayland is more modern and potentially better, but development on the linux desktop is slow so some parts are not ready yet. You should use it for future-proofing, unless there is some X11 feature that you really really need. But you probably won’t notice much on the surface. Check your drivers/desktop environment versions if you have flickers on nvidia, you need the very latest versions because of a recently resolved issue.
Backstory:
Xorg is a program, X11 is the protocol used by said program. Xorg is old, insecure, inefficient, it is based on an idea of how graphics work that is outdated and doesn’t reflect modern hardware. But most of all, its code is a mess, and it is impossible to update it to fix those issue. Thus, the Wayland protocol was born as clean-slate replacement, meant to solve some issue (make it more secure), clean up the software (Xorg is unmaintainable), and make it reflect the way modern graphics work (less intermediary, no network transparency, no per-vendor implementation), but as a consequence, it breaks compatibility with old software.
Also the developer of xorg were so traumatized by x11 that when making Wayland they went to much in the opposite direction and were reluctant to implement some features, most of which have now been added as protocol extensions or separate software, but some are considered against the protocol design principles and will never be implemented. One of the differences is that there’s no standalone display server, but you have a window manager+compositor+display manager, so Desktop environments need to make their own or support the one made for other environments, that’s why only a few of the long-standing DE support wayland, for now.
What makes Wayland good (plus drawbacks):
Less intermediaries mean theoretically more efficiency, thus speed. Of course, that is only true if the compositor is mature enough, after all X11 software is very mature.
In ye olden times every vendor provided a closed source implementation of the x11 protocol, and that’s how drivers worked. That is objectively a bad idea, so during the years glamor was developed, to run Xorg directly on OpenGL instead of on an ad hoc driver (put a pin on this for later). In Wayland you don’t need ad hoc drivers, they just need to provide Egl (not to be confused with EglStreams) and a library called GBM, that are used for managing frame buffers.
Xorg used to manage a huge part of the devices (even printers…), and due to antiquate design, it was unable to handle trackpads correctly (e.g. no proper kinetic scrolling), Wayland does less, and relies on other more modern input management libraries, this theoretically allows input devices to work better, but only if the related new libraries and protocols are ready. E.g. he trackpad part is ready, the drawing tablet part is not.
It is more secure, for example it doesn’t allow programs to just read the screen. It is absolutely possible to do screen recording, but you need modern software, and some applications (e.g. discord) are really reluctant to update their libraries (discord is using electron from 2018), so they don’t get recording. A problem is that it doesn’t allow applications to move windows, some protocols are being worked on, but right now, software that relies on moving or placing windows will not work.
Applications (plus possible work around for freetube):
Most applications using modern libraries and toolkit don’t need to care about Wayland support, the toolkit will do the job. They might be undertested on Wayland tho, and small projects might not have the resources to test and take care of both protocols, so they will choose X11 because it’s still the most used.
Most older applications also don’t need to care, because Xwayland works just fine (put another pin on this), but sometimes they are a bit broken. And if they are specifically tools for xorg (e.g. xscreensaver) they will of course not work.
Some times electron apps still have issues, because chrome has not had proper Wayland support for a long time. More over, Google does make a version of chrome with improved Wayland compatibility, but they ship it with chromeos. You might fix some issue by adding
--disable-gpu
which disables electron’s gpu support.Expect proprietary applications to not fully support native Wayland, because their vendor often don’t care.
Java applications don’t support native Wayland because AWT is fundamentally incompatible with Wayland. JetBrains is working on a replacement.
Nvidia, Xwayland, and Glamor (this probably concerns you):
Recall the pins from before.
Nvidia provides it’s own proprietary implementation of X11, like in ye olden days. When they decided to support Wayland they decided that they wanted to use Egl+EglStreams instead of Egl+Gbm, but only gnome implemented partial support for eglstreams (so it was basically unusable), they refused to support Gbm for many years, untill about three years ago for and suddenly you mostly could use wayland on Nvidia but some things were broken, and especially Xwayland was broken and flickery. Many things were fixed but not xwayland.
Nvidia refused implement the Implicit Sync (from now IS) semantic, which was (until a couple months ago) required by linux’s standards. That is to say that their drivers did not respect linux’s standard and were incorrect. IS is not a good semantic for modern graphic, but that was the standard and there was no alternative.\ No one noticed for a long time because Nvidia provided it’s own implementation of X11, but xwayland uses glamor which glitches when IS is not implemented causing flickers. Actually this affects everything, but for some reason xwayland is more affected.
During the past two-to-three years Wayland developers worked along side nvidia to come up with a new Explicit Sync (from now ES) semantic. ES is marginally better for IS, but most of all, Nvidia is fine working with it, so now the flickering should be fixed as well.
Why does your xwayland windows flicker? Applications can support ES and get 0.001% better performance even if they shouldn’t need to (because of how it was designed), but what you need is support from your desktop environment, and from your drivers. You need the latest version of Xwayland, and Gnome 46.1+ or KDE 6.1+, plus nvidia drivers 555+. If you have those versions of the software, everything should work, if not expect flickers and wait for updates.
Thanks for taking the time writing this up, it is very helpful for my understanding (and I imagine many others’ as well)! For the things I don’t completely understand for now, this also gives me a lot of additional pointers for what to learn more about to get a better grasp. So it goes straight into my notes for future reference.
Sounds like I should dare to activate my dGPU and reboot to check it out now then :) My biggest worry was that it would be so severely broken that I wouldn’t be able to switch back, but I know that is just an irrational fear - no way Tuxedo would’ve switched to Wayland by default if it broke their own laptops. But I’ve been a little twitchy about larger updates since I deleted KDE accidentally from not properly reading/understanding the prompts during update.
Well in the worst case you can always enter a tty or ssh and try to fix from there. But you can be sure the system will be recoverable.
I took a simplistic approach on some of the things I talked about, but you can use it as a pointer for a deeper dive. Also I realized now that I wrote the comment in really bad English, apologies.
I really do believe the future of the Linux desktop will be exciting, and that’s also thanks to Wayland.
I’ve never heard of AWT being incompatible with Wayland, I’d love to read more on that if you have any!
I saw it on a blogpost somewhere about jetbrains working on Wayland support for Java, but it was a long time ago, I don’t think I can find it. This has the gists of it https://blog.jetbrains.com/platform/2023/08/wayland-support/