Switch to Wayland tips and tricks


I’ve been looking into using Wayland here and there for the past 2 years on NVIDIA GPUs (testing each driver releases), but I keep having issues with some of my apps. I was wondering if anyone know of something I don’t to make this work…

Right now I’m on f39 Gnome, driver 550.54 (RTX 4080) and the main problem is some apps flickering.

  • Parsec from Flatpak/Distrobox (Need it for work, no other option)

  • Obsidian to take notes (Could use something else, but I have all my notes in there already…)

  • VLC (Could use something else, and I don’t really need a video player often anyway)

I’m sure more of them do not work but don’t have time to do a full check. To be honest, I’m completely fine with X11 and can’t switch to intel/amd GPUs. Unless something can be done about it, I’ll ignore the “peer” pressure to migrate until they make it work out of the box.

All the talk about X11 getting deprecated from Fedora prompted me to dig more into it.


The hope for nvidia hardware is the NVK driver development work.
I could not find a good link for the current state of the driver.
Announced here: Introducing NVK
I see stories here on the progress of the NVK work: https://www.phoronix.com/

I see lots of activity being reported and expect that this is the way forward for non-proprietary drivers for nvidia.

Personally I decided not to wait and upgraded to amdgpu.
But I’m still very interested on what happens in this space.

I heard the proprietary drivers have good Wayland support but bad XWayland support.

All these apps probably use XWayland.

Obsidian is an electron app which often dont use wayland.

Using Flatseal, try adding the environment variable ELECTRON_USE_WAYLAND as 1. Also you can just disable X11 (+X11 fallback) and enable Wayland through flatseal, and thus force it.

Old versions of Electron might not run nicely so using something not Electron will spark joy.

Generally stick to GTK and Qt apps, they all have Wayland support.

Then VLC is still using X11 and has no Wayland support at all. I really like Celluloid, Glide is also nice, both from Flathub. Ditch VLC until they release 4.0 and finally adopt the Flatpak.

For your other app, no idea, try to run it without XWayland. But it has like all the red flags, last build is based off a 3 year old release, it uses an EOL runtime and more.

If that is the parsec you mean. Forcing Wayland may still work. But as I said, avoid running such unmaintained software if possible.

XWayland is the backend used by both X11 and Wayland. If X11 is working properly then it would not seem to be an XWayland issue that causes the issue with Wayland since both use the same backend…

Any time a user runs the inxi -Gxx command or similar that provides the graphics output they see a line similar to this

  Display: x11 server: X.Org v: 1.20.14 with: Xwayland v: 23.2.4

and the only thing that changes is that x11 is replaced with wayland when the wayland DE is in use.

  Display: wayland server: X.org v: 1.20.14 with: Xwayland v: 23.2.4

I have used nvidia GPUs and drivers for years and gone through the transition from x11 to wayland. Wayland is still not 100% with everything, and some of that is that not all the apps have fully switched to supporting/functioning on wayland

Applications that rely on the lack of isolation in Xorg (xeyes is the canonical example) between the active window and the rest of the desktop won’t work as intended with XWayland. The lack of isolation under native Xorg is a security problem, but Xorg exploits based on the lack of isolation won’t work in XWayland.

Okay not sure if I understood the first comment correctly, and the second one is completely unrelated.

This is about GPU issues with XWayland apps on Wayland.

I’m sorry but that is completely wrong:

If you use X11 then neither Wayland nor XWayland is involved at all. The display server is X11 and speaks X11. Clients (“apps”) need to to speak X11 to the X server, or they can’t display anything.

If you use Wayland then there is no (proper) X11 server. The display “server” (compositor) speaks Wayland. Clients (“apps”) need to speak Wayland.
One such client is Xwayland - it speaks Wayland to the compositor. But it also provides a translation layer: X11 apps can talk X11 to Xwayland, which in turn talks Wayland to the compositor.

And that determines which drivers and how many layers of translation are involved.

1 Like

Hello @perpixel ,
A good place to start IMO is to look at https://wayland.freedesktop.org/, at least for a comparison to X and why Wayland and not just a re-write of X. There are also links to the documentation for Wayland, and through all the reading I have done there and elsewhere regarding Wayland is it is superior to X in many ways, but is not all X has become. For instance, rendering is one area that Wayland does not handle, it is left to the client app to render. Thus the confusion that seems to arise from XWayland support, which is an API between an X client (app) and the Wayland Compositor (like Gnome Shell).
Anyway, there are tools available from the fedora repos, such as wayland-utils, and gammaray to name two, that will help in determining how your hardware is being used (or not) by your DE/App setup.
Remember with Wayland the DE session handles compositing, so is the compositor, such as Gnome Shell, or Sway for instance. In practice, the desktop environment was already handling the rendering in X, but with Wayland there is no need to carry the legacy bloat of X that had core items for rendering those 80’s style graphics built in, like fonts to name just one annoying thing. To quote the Wayland documentation …

There is no single common Wayland server like Xorg is for X11, but every graphical environment brings with it one of many compositor implementations. Window management and the end user experience are often tied to the compositor rather than swappable components.

As for X apps that are migrating to Wayland, there may be a large amount of work required and this will result in some legacy needs for X, or XWayland. So, I don’t see X server disappearing in the very near future, it isn’t being actively developed though. So my suggestion to anyone interested is to make the switch and find the replacement for those things which you really need from X or even better, bug those projects to make the change (to Wayland). I think most if not all of the QT based apps for instance would already be most of the way there since QT hasn’t let X server handle it’s rendering in many years.

I just heard in some podcast that Nvidia drivers have problems with XWayland apps, thanks for the clarification.

I have no idea of GPU stuff, does the GPU driver already do something in the X11-Wayland translation of XWayland?

Only these apps are flickering and they all use XWayland which is pretty remarkable.

@jakfrost that Qt point is not completely true, the feature to undock and move around panels of settings (like in Kolourpaint or QGis) is really common in Qt apps and not supported for Wayland in Qt5.

KDE must have done some major fixes that their software has so good Wayland support on Qt5.

But with Qt6 that will improve drastically.

Short answer is yes. The xwayland code uses the gpu to create a wayland surface for the compositor. I guess using openGL.

And that may cause stuttering because some Nvidia driver problem.

Switching to Wayland native apps should mitigate that, it is not a bad idea in general and at least a workaround for now.

Isn’t Plasma based on QT6 though?

Plasma 6 is not stable, so no, Plasma is just now finishing their Qt6 port, which means all the years people used Plasma 5 on Wayland must have involved lots of Qt fixes in Plamsma.

I have been testing plasma 6 and its worked very well in my testing.
It is looking very good for f40.

1 Like