KDE Wayland - What's Not Working Yet

Development
, ,
1

KDE Wayland - What’s Not Working Yet

A short list of things I’ve found that either don’t work at all, or don’t work properly (or as expected) when using KDE in a Wayland session.

This is not an “I hate Wayland” list; it’s more of a checkpoint of what works in KDE X11 and is expected to work in KDE Wayland, but currently doesn’t or works differently. KDE, even when using Wayland, is still, IMHO, The Best DE Known To Man.

Also, if I say anything that may be incorrect or no longer true, or you think it may be specific to me and my device/settings, please let me know.

My List

  • Minimizing a system tray app doesn’t remove it from the taskbar (qBittorrent, KeePassXC, OBS Studio, etc.). You must click the system tray icon to remove it from the taskbar. In an X11 session, you can click either the taskbar button or the tray icon to remove it from the taskbar.
  • Kwin window rules most times fail to work in Wayland sessions, but work as intended in X11.
  • Wacom/Tablet system tray and System Settings
    • The system tray settings pop-up often fails to detect a tablet or fails to load the icon at all, even if you set it to “Always show”.
    • The Wacom/tablet System Settings in Wayland is a downgraded experience compared to X11. Though, IIRC, I think David Revoy has been working with the KDE dev team to fix this.
  • OBS Studio often times fails to get access to record your screen.
  • Similarly, but happening far less frequently (rarely, really), Flameshot also can’t get access to take a screenshot.

For the last two, I know it’s a security feature, and that there is some recommended fix (or setup), but not all distros implement this by default. New users, and people like myself who just use X11 sessions for serious business, will either not know what to do, or pretend the problem doesn’t exist since it works in X11 just fine (again, me).

There are things a user should want to learn, and things a user shouldn’t have to learn. The screensharing/screenshotting issue is the latter.

The Clipboard Issue

On a similar note related to protecting the user, one of the major reasons for Wayland is security, and I applaud the effort. However…

If, for instance, I am sharing my screen and the last thing copied to my clipboard is a password, and I try to copy something else thinking I have successfully done so with CTRL+C, then press CTRL+V to paste it elsewhere, and it pastes my password instead, I think something is not being done correctly. And I know it’s not on my end because this has only ever happened in KDE Wayland for me - I’ve not had it happen in either Hyprland or Labwc.

I think this should be a priority one task, or whatever naming convention the KDE dev team uses.

These were all I could think of, and I am sure there are many other things, big and small, (like the session management thing), but these are the things that affect me. You may add to the list in the comments as I don’t yet have Wiki editing rights to keep this thread open.

PS: If this type of list already exists somewhere on the forum, I couldn’t find it. Feel free to close/merge. If it exists in a “KDE Roadmap” of sorts, please point me to it.

2

An example of this issue, and what prompted me to write this list since I’ve been having these drawbacks with KDE Wayland for nearly two years, mostly just ignoring them since I spend most of my time in X11 sessions (KDE and Openbox).

3
  • (+) Display ICC color profiles are still completely unstable, at least on my system.
  • Kwin windows rules are getting better… slowly! Still wish I could set separate rules per screen
4

I have yet in Wayland to see these behaviors.

5

Hmm. Maybe it could be my base distro (Archcraft) messing things up somehow? Or maybe your base distro has identified this as an issue and fixed it?

I’ll give my Tumbleweed and MX Linux installs a test with all that I mentioned to see if it’s the same. I do know that distro maintainers sometimes change defaults that could be to the benefit or detriment of their users. Of course, with the intention to make it a benefit.

6

Unfortunately phrasing like this is way too vague. Anyone trying to verify this, e.g. a bug triager, would likely try some random rules without ever hitting one that does not work.

If you have a rule (or rules) that fail, ideally consistently, be sure to mention these in the bug report you create for the issue.

Then you need to check with your distribution, they are lacking essential system components.

Indeed.
The desktop environments which consider screen access a privileged function that the user should have control over do all provide a permission check system for doing that.

Some distributions might consider this optional but, as you said, it doesn’t make a good user experience

7

Yeah, a bug report would need proper testing and details. I would check Tumbleweed and MX Linux before filing one, since I know Arch distros, in general, can be very opinionated with default settings like Archcraft, or very hands-off like EndeavourOS or base Arch.

8

For testing purposes, I feel like if you want to troubleshoot on multiple distros, KDE Linux and KDE Neon also are good candidates.

9

Okay. So I troubleshooted using Archcraft, MX Linux, and openSUSE Tumbleweed.

System Tray Minimize

This is true in all three distros, tested with the latest available version of OBS Studio per distro. And tested with the latest version of qBittorrent on Archcraft.

Three Videos (Arch, MX, Tumbleweed):

https://imgur.com/a/utrIHXF

Window Rules

There was some inconsistency here.

I set my windows to open under my mouse in all three distros. Apps with a window rule will, of course, ignore this. This is true in MX Linux under X11, where the Firefox “Library” window (or the “Bookmarks and History” window) opens in the center of the screen based on my window rule to force it to be centered. Whereas, when using Wayland, it always opens under my mouse.

However, in both of the rolling release distros, this inconsistency was no longer present - thank Jeebus! Whether it was X11 or Wayland, the Library window opens centered, like it is supposed to.

To add another app to the list, I use the same exact setting for the KeePassXC pop-up to unlock my keys database, and this inconsistency is the same - works in X11, but not Wayland.

I suspect that the inconsistency may re-occur on a rolling release as things are fine-tuned and features aren’t checked for minor bugs.

10
  • (+) Window Placement Inconsistency

On another note, my testing did remind me of another window rule-related inconsistency in Wayland - forced window placement and size.

There are a few windows that I tell kwin to place in specific areas of my screen. Two of them include qimgv and dolphin. They are both supposed to open maximized vertically on the right side of my screen.

This window rule works just fine on X11 consistently. But on Wayland, it is very inconsistent - sometimes it’s exactly where it should be, but most times it’s under my cursor. I haven’t actually tried to count/record the percentage, but if I had to give a ballpark, 70-80% of the time either window opens under my cursor rather than at their window rule-specified location.

11
  • Apps not focusing when launched. Like opening a file from a file manager, the application the file is opened with isn’t focused. Or like when opening a link from a document.
12

I’m new here a refugee from Ubuntu Mate which doesn’t seem to be happening for 26.04. I’ll stay with 22.04 as long as I can but…

My question is what is the status of Cuda on Wayland? I need Cuda for my AI project, if it is not solid I’ll have to install X11 session.

13

Objection! Relevance? :sweat_smile:

I kid… somewhat.

Are you asking this question in this thread about what’s not working in KDE’s Wayland session because you are considering switching to KDE and would like to use a Wayland session? If not, please consider opening another thread.

If yes, CUDA is not affected by the graphical session for the most part, so long as it is a graphical session. KDE is a bit more resource-heavy, though.

To be honest, you should open another thread regardless, because your question is likely to get lost in this thread if more people add comments related to the thread.

14

This can depend on various factors so this would need some more details before it can be reported.

There are several levels of “focus stealing prevention” and either the launching app or the launched app could have issues handling these properly.

15

Adding this since I’ve had this issue intermittently in the past. Obviously, it’s still not consistent as yet, and it is related to Wayland’s security model.

16

I’d personally say the system tray “issue” is actually the expected behavior?
Just because an application supports a system tray icon doesn’t mean I don’t want to be able to minimize it normally as well. In these cases I expect closing the application window to send it into the tray (and that’s the way it usually works). I don’t think this was different on X11? I thought I would’ve noticed, but I’m really not sure right now.

Edit: just saw in your example videos that the application in question has a “minimize to tray option”, so in this case of course it should work. But is this a wayland problem, or a problem with the application?

17

How so?

The difference between X11 and Wayland regarding clipboard operations is that on X11 any application can access it at any time while on Wayland only the active window can.

Both the source and the destination of the operation seem to be the active window at their respective time of interaction.

18

Not something I know the answer to. I just know that for all the applications that I use that have that feature built-in, minimize to tray does not work when I am in a KDE Wayland session. I wouldn’t be surprised if the answer is both.

Sadly, apart from KDE, there aren’t many DEs/WCs that have a fully Wayland-native task manager (meaning window buttons you can click, rearrange, etc.) so that I can test if it is KDE-specific or just Wayland in general. Might install Cinnamon or Cosmic to test it one day, but that’s unlikely.

You quite literally just described a security feature. Isn’t that the reason for its implementation - security? While the security and/or privacy is welcome, especially as Linux becomes more widely adopted, it prevents clipboards from working the way the majority of the world is used to.

I haven’t used Windows in almost 6 years now, but I don’t remember ever having an issue with the clipboard not pasting what I asked it to paste, nor has this been an issue in any Linux DE/WM I’ve used until Wayland started being widely adopted.

Again, this thread is not about bashing Wayland, so please don’t misread my observations (both from personal experience and from the many posts on forums throughout the web) as criticism of Wayland. I’d like Wayland to finally be able to do the things I am used to doing in KDE without thinking that I should just switch to a KDE X11 session or Openbox to avoid minor headaches and hiccups.

19

wait, are you all saying that if i open kate and copy some text to the clipboard and then close kate…

that i will not have that text to paste into my browser or terminal because kate was closed before i pasted?

because i do this all day long on X11 and i need to be able to do this.

is the middle click paste buffer also affected by wayland “security” features, because i also rely on that to work as expected, by selecting text and pasting using the middle mouse button.

20

Currently, this is how it should work - meaning not allowing access to the clipboard since this can be a security risk. However, currently, it is inconsistent.

For some people, whether it’s their settings, distro, or use case, things work like the KDE Wayland team coded things to work. For others, it’s a minor annoyance that may randomly have the opposite effect and expose the user rather than protect them.

As I don’t only use KDE, using Klipper is not for me, but if you are using Klipper inside a KDE Wayland session, things should be smooth-sailing. Same goes for Spectacle.

I think the issue is both a KDE Wayland and app protocol/feature adoption problem.

PS: I do remember hearing about a possible change to middle-click-to-paste due to more and more users moving to Linux, and man, I hope it remains a feature I can use even if it’s disabled by default. Preferably one I can enable in a settings manager rather a config file, terminal command, or environment variable. But anyway, that’s for future me to be annoyed about :sweat_smile: