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.
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 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.
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.
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.
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.
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.
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…
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.
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.
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?
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.