Wayland: what's blocking you from using it?

Hello all,

I’ve been noticing that Wayland seems to be getting nearer and nearer to “ready” for vast majority of use cases. In fact there are things (like fractional scaling) that work better and faster than Xorg.

I wanted to migrate but have run into these issues:

  • Multi-screen does not work. Applications such as Remmina and Citrix Workspace don’t seem to be able to detect and use multiple monitors.
  • Input capture also seems to also be a problem. Citrix Workspace seems unable to capture keys and relay them to remote. Remmina on the other hand seems to have no trouble with this. I wonder if Remmina are doing something Wayland-specific.
  • Zoom does not support screen-sharing on Wayland (even though everything else seems to work fine)

Anybody else have “blockers” preventing them from using Wayland? Can you please share?

The KDE spin seems to only support Wayland already, so it seems like we may no longer have a choice in the matter.

KDE has their own list.

On that list, Color Management is a big one for me. The Graphics Tablet issues are also problematic.

The NVIDIA driver’s current lack of explicit sync support is another significant one, but that’s due to be solved in a few months.


Thank you for pointing me to this list.

Going over it, the only one I personally noticed was the fact that you can’t save/restore the session and window positions properly. That’s quite annoying indeed.

Overall though, I’m surprised that the input-capture / multi-monitor issues I mentioned didn’t make their list. Seems like these may be fringe use-cases that may not get addressed for a while still.

I know Gnome has made some progress on input-capture stuff due to a program called “input leap” which is a “software KVM” (allows sharing the same mouse/keyboard across different machines). Hopefully that work can be transferred to KDE.

You can add these issues yourself. They may not know they exist. I added the Color Management and Graphics Tablet issues, and Nate didn’t remove them…so I assume he agrees they’re Significant Issues.

I suppose I was unwittingly giving the impression that KDE had taken particular notice of Color Management/Graphics Tablet issues to add them to this page, so sorry about that. I should mention that I took the Graphics Tablet issues from a Krita user: Kde wayland for artists - KDE UserBase Wiki

Currently nothing is stopping me, but if I had a VR set-up still I’d definitely be checking performance between Xorg and Wayland sessions.

That graphics tablet issue list was almost a concern, but my Wacom CTH-470 works perfectly for the basics of aiming with the stylus on Plasma 6 Wayland and osu! lazer :stuck_out_tongue: On GNOME 43 or 44 iirc there was an issue on Wayland where it would switch between the stylus and tablet touchpad when my hand bumped it and made osu! unplayable, but no problems on Plasma 6.

Color management is definitely the sticking point for me too. There are at least several of us in the community who like to have accurate colors for working on design, art, and photography related tasks.

I know others have problems with accessibility-related features, such as screen readers.

Screen reader support is even important for us developers too: I’d like for myself and the teams I work with to be able to use screen readers on Wayland on Fedora for checking our web development work. But you can’t reliably do that on Wayland yet.

1 Like

I’ve been thinking of using Firefox’s screen reader, but have not got around to it. I used it several years ago but the experience has supposedly gotten better. . .

I can’t say I’ve ever used Firefox’s screen reader for web development, but I use it daily for reading stuff. It works pretty well in Reader mode, and I’ve set Speech Dispatcher up to use Piper voices with Pied.

I assume you’re checking that the page is navigable with a screen reader? I don’t think you can use Firefox’s screen reader outside of Reader mode…

Really? Not one mention of either:
i3lock, xsel, xclip, xrandr, xkill, xdotool, xprop

Like I said in a thread I posted on the other forum a few days ago:

I can’t live without these. I have at least a dozens scripts and shortcuts that depend on things like this, that make my work and even casual use much easier.

I don’t understand how anyone can look at Wayland and think it’s actually an alternative if doesn’t have basic functionality like that, and from what I’m reading it either can’t possibly support some of these things, or supporting them is super complicated.

1 Like

I’m a Nvidia user. While things have improved a lot, I’m still experiencing flickering issues when typing. I believe it was said to be a nvidia driver issue not supporting explicit sync, which is on its way last time I heard.

My biggest problem is fractional scaling not being supported fully. Many programs I use for work do not support wayland, which results to blurry rendering all over the place:

  • Jetbrains IDEs
  • Any Electron based apps really (Slack, Discord, Zoom, VSCode …)
  • My web browser of choice, Brave, doesn’t even start on Wayland but it could be a regression, who knows.

I’m running Fedora 40 by the way.

At least for xsel and xclip, you can use wl-clipboard. You can use ydotool instead of xdotool.

Instead of xkill, on KDE you can use CTRL+META+ESC and click on a window to kill it (press ESC to cancel).

Instead of xrandr:

  • wlr-randr for wlroots compositors like Sway
  • kscreen-doctor for KDE if you want a CLI tool
  • GNOME has the ability to configure monitors in the GUI.

I’ve never used i3, but I used Swaylock when I was using Sway.

For xprop, Sway has swaymsg -t built-in.

None of these tools will ever work on Wayland because they were designed to perform tasks on X11 that are now privileged on Wayland. So the only thing to do is replace them with Wayland-specific tools.

KDE’s Wayland implementation is pretty complete, so you’ll have a lot of luck with that compositor. Sway/wlroots goes a step further in some regards, but it’s a tiling window manager, of course. It’s meant to be a drop-in replacement for i3.

I have the same issue. The beta driver with Explicit Sync support is due on May 15th, with the stable driver likely to come out a month after that. I’m very sick of the NVIDIA driver on X11 and Wayland, so it’ll be a good day…

I have a similar issue with Krita. That’s not going to be solved until at least color management is implemented so Krita wants to use Wayland…

But you can force some of these programs to run in Wayland and it’ll be a better experience. I started doing that because XWayland programs flickered all the time with my NVIDIA GPU, but they didn’t on Wayland.

Jetbrains is going to support Wayland soon to “solv[e] the age-old fractional scaling problem”: https://blog.jetbrains.com/platform/2023/08/wayland-support/

Electron apps need one or two command-line options to force it to run in Wayland: Wayland - ArchWiki

These ones are needed for Signal Desktop, for example:


Have you tried running brave --ozone-platform=wayland? That works for me with chromium --ozone-platform=wayland.

Incidentally, I’m not currently running Fedora at all, but I’m going to install Fedora 40 later today…

JMO but this is an area Fedora and GNOME shine. How long has Wayland been default in Fedora/GNOME, basically when the X.org developers moved on so did they. They are often first to integrate core improvements like Wayland & Pipewire and thus the first to polish them.

Not to denigrate the others, just my perspective and I’m biased. Admittedly I don’t use my Linux laptop in a very technical sense… I’m a network support engineer by day and use MacOS for work… but for everything else there’s Fedora Silverblue and I’ve not had problems with Wayland for some time, even meeting screenshares work now.

thx I will check these out

Just want to point out that my post’s intent is to get a sample of outstanding issues people feel are important. I’d hate for this to become a Wayland-v-Xorg post.

I’m actually trying to switch to Wayland, but my employer’s workflow forces me to stay on Xorg. I simply must use Citrix for work, and need the multiple monitors.

At some point I expect Wayland will support all of this, but sampling the outstanding issues people have is useful. If anything, just to raise awareness…

1 Like

Wayland apparently has no way not to have a DE crash take out everything. Imagine doing work, and some wacky JS code in a distro-enabled extension causes GNOME to crash. And down goes everything else, because Wayland. I have no idea how anyone can suggest using Wayland in a work environment, unless you’re a DE dev. If I were an employer I’d enforce Xorg for any actions that aren’t crash-tolerant.

I know GNOME on Xorg crashing allowed the shell to restart and not take out everything years ago.

If the X Server crashes, everything also crashes. With Wayland, GNOME is both the compositor (analogue to X Server) and the window manager.

However, as noted on the Significant Known Issues page, Qt-based applications survive compositor crashes on KDE since last year and there’s ongoing work to enable this feature for GTK-based applications: This week in KDE: Qt apps survive the Wayland compositor crashing – Adventures in Linux and KDE

Where it’s at currently: Restarting · Wiki · Plasma / KWin · GitLab

This is not something possible on X; only Wayland, so by extension, if the XWayland server crashes, applications will be taken down too. Although by the sounds of it they’re looking at enabling this functionality on XWayland too.

I don’t know whether GNOME is working on the same functionality…

I gave those things a shot and they don’t meet my requirements. For example ydotool it can click and press keys, but I can’t for example query the windows, see if there is one with a specific class/name, and some other criteria and activate it only if it exists. Then with some windows, take a screenshot of the window, and use OCR to read the text at a specific location. Then based on that, decide the logic it needs to follow.

Some of you may be thinking, why not just develop an app, or a script to do this without clicking on stuff, and I can’t do that (or at least I don’t know how). I hate clickers myself, but when I do use them, I need them to follow logic, not just basic input and hope for the best.

Unfortunately, ydotool won’t support that feature: window id and position and bring to top? · Issue #35 · ReimuNotMoe/ydotool · GitHub

To get the Window ID/Contents, you would likely need to use a tool specifically for that compositor (swaymsg comes to mind; it’s used for wlprop) and pipe it into ydotool. My use case for ydotool is pretty simple, so I can’t offer much more help than that.

Edit: I did some more looking, and I found kdotool.

Wayland, for security concerns, removed most of the X11 APIs that xdotool uses to simulate user input and control windows. ydotool solves the input part by talking directly to the kernel input device. However, for the window control part, you have to use each Wayland compositor’s own APIs.

This program uses KWin’s scripting API to control windows. In each invocation, it generates a KWin script on-the-fly, loads it into KWin, runs it, and then deletes it, using KWin’s DBus interface.

This program should work with both KDE 5 and the upcoming KDE 6. It should work with both Wayland and X11 sessions. (But you can use the original xdotool in X11, anyway. So this is mainly for Wayland.)

I’m afraid I couldn’t find anything for GNOME, but hopefully that’s enough to get something going on Sway or KDE?