Wayland on Plasma 5.27

Support KDE Plasma
, ,
1

I am starting a discussion to see what is your experience?

For me, Plasma 5.27 has a nearly perfect Wayland implantation. For a long time Wayland was no-go for me, because I use a hybrid GPU laptop with Nvidia so even when for many PCs it worked well, it was horrible at my end. With Plasma 5.27 I decided to switch to Wayland and… the experience is almost on pair with X11 and in some areas better. I run Steam with prime-run and Divinity Original Sin had about the same performance as on X11, so this has to mean, that Nvidia is correctly used. I couldn’t tell it before looking on system data on Steam, because it always crashes on Wayland, but that’s a problem with Steam, not getting the correct data and going haywire because of that. I suspect not all games will work well, but so far so good.

The perk of Wayland is the real-time touch gestures on a pad. They work so much better than on X11. It is as if I got a new pad, as accurate and smooth as on MacBooks. The con is, that there is a set of pre-defined gestures and no UI to configure them, so we are stuck with what is given to us. However, Overview and grid are absolutely awesome. The gestures’ configuration is planned, but the person responsible for it went gone. Eventually it will be implemented (if not by the original developer, by someone else), but not soon I’m afraid.

My main issue now is with shutdown, which takes a long time, or it freezes. This is a SDDM bug. See the details in:
https://bugs.kde.org/show_bug.cgi?id=445449

If you want to fix it for now, install sddm-git, till the SDDM will get a version bump in repo.

Unfortunately, there is one absolutely MAJOR CON OF WAYLAND that nobody is talking about: when Wayland crashes, all opened windows have no way of returning, so they are force-closed, so when Wayland is automatically restarted, all opened apps are gone, including latte-dock.
This is currently the problem of Wayland, so also Gnome and other Wayland implementations suffer from this. Because of that, Wayland is not ready to be the default and those who set it as a default for their distros, are probably not aware of this huge concern. So as you can imagine, tinkering with Plasma settings increase a risk of Kwin crashing, and if Kwin crashes, Wayland does also, because they are the same in Wayland session (so to speak). On a daily basis, risk is minimal thou.

EDIT: This issue will be gone with Plasma 6!

Here is the info about that:

6 Likes
2

Since no one is sharing their experience on Wayland in Plasma yet, I am sharing a link to another thread that is asking about some issues with Wayland.

Basically, Plasma is Wayland ready, but Wayland itself is not ready and won’t be for another year or probably more.

1 Like
3

Thank you for sharing you experience on optimus. As an optimus user myself, it is a bit frustrating when there is no discussion online about this besides “don’t do it” because eventually we will reach a point where we can. As for me, I am not ready to consider moving over until the gestures are fully configurable on KDE. Or at least until you can disable the default ones in favor of libinput-gestures.

3 Likes
4

Yeah, the lack of gestures configuration is a bummer, but if you are happy with old overview and grid, then all is fine.

I would also recommend to replace libinput-gestures with:
touchegg and touche (UI)

They are doing a way better job and are more configurable. On libinput-gestures the detection was incredibly spotty and unreliable. With touchegg it works incredibly smooth. Plus, you can define gestures per app, like a pinch in/put to zoom in/out in the browsers!

Touchegg won’t work in Wayland, at least for desktop, but will still work for apps like browsers.

5

Okay, I am having a lot of difficulty with this setup on Nvidia Optimus. I have the 525 driver and an RTX 3070 ti and I’m using Plasma 5.27.2. On Wayland the mouse lags on the screen with the panel (it does not lag on the secondary monitor). The panel also shows black corruption intermittently. Does anyone else have this bug and, if so, how did you manage to fix it? The lag is so bad that the session is not really useable.

6

The mouse lag has nothing to do with Nvidia. No idea what is the cause, but Wayland accepts inputs in a different way, so something is clearly no working well for you. Unless, this is some graphic issue that causes lags when object is moving through first monitor? Check out the CPU and GPU usage, and see if there is a spike of resource usage during the lag.

I have GTX 970M card, so much older model. It’s possible that it somehow works for me but not for you.

I wonder… what about EGL_STREAMS? In the past, we had to enable them manually in .xprofile, but now they should be active by default. Maybe somehow they are not active on your computer, hence the graphical issues?

Check out if you have egl-wyaland package installed,

For me, Wayland was previously hit-and-miss. If it worked, it was incredibly buggy. Some update made Wayland just not usable (black screen), sometimes it worked fine, until I saw some show stopping errors after a few minutes, then Wayland stopped working again after another update. So most of the time I was ignoring it as not usable. Since 5.27, it just works. Aside suspension and shutdown issues, the rest was working just like on X11 (excluding Wayland incapabilities so far).

Ah, I am not using system panel, only latte-dock, so possibly that was the difference?

See this site:

https://community.kde.org/Plasma/Wayland/Nvidia

There is some info about modesetting mode. Check that out. They also say that the secondary screen has a poor performance. I didn’t notice it. It worked fine for me. Moreover, I got no screen tearing, while on X11 there was always screen tearing on the secondary monitor. Although, that might have been generally fixed, not just for Wayland. I need to observe it more on X11 to be sure.

7

Just an update.

I installed sddm-git (I know it’s risky, and I’m going to move to repo version if it gets a new version, but for now, git version is better) and it fixed my shutdown issue. Not sure about the suspension, but since SDDM was unable to close Kwin windows at shutdown, it probably influenced the suspension either.

With Zoom supporting Wayland, I should be good to go. I don’t use Teams at the moment and I don’t need anybody to Team Viewer to my desktop (only the other way around), so my only main concern are possible Kwin/Wayland crashes. Those are rare but can happen. Luckily, I don’t work much with graphical software and set Libre Office to save every one minute. Browsers remember session, so I should be good to go, but a bit scared when using Wayland for work. Will see how it works on a long distance.

EDIT: I spoke too soon about Zoom… On their page it says it supports Wayland but when you actually try to share desktop on Wayland, you get this:

Screenshot_20230303_111316

I don’t get it. If it works on Gnome, why doesn’t it work on Plasma?

So Wayland on Plasma is still not ready for work environment :frowning:

8

Can you try to run $ QT_QPA_PLATFORM=xcb zoom on KDE Wayland?

9

Thank you for the reply. So I do have the libnvidia-egl-wayland1 package installed (I am currently testing on Kubuntu). Can anyone who is using the Plasma panel replicate this problem?

1 Like
10

Didn’t change a thing. I still get the same pop-up window and desktop share is blocked.

11

Zoom does not screen share, it just quickly shares screen shots. In KDE it is not possible as you need to use a protocol, same for sharing video, so is up to zoom to implement it. Meanwhile you can use zoom web version in firefox and it works very well.

12

@Lycan, I’m not sure how to use zoom in a browser. It always redirects me to the non-browser application and there is no choice to stay in a browser.

EDIT: I managed to start session in a browser, but it’s so convoluted! One have to know which parts of the site to click, although that are not obvious on first sight, then refuse the pop-up and click special link in a SMALL PRINT, so you wouldn’t find it on your own… Then it opens a series of confusing windows, but eventually it opens a meeting and sharing seems to work…

So that would mean, we need to make ask for such solution in Plasma itself.

13

That would mean to implement a security breach to bypass the xdg screen share protocol of wayland in order to provide a screenshot utility that is accepted only by zoom. Is it not better if zoom just implements the protocol like everything else?

14

OK, but why did Gnome implement it? Is this not a breach on their side?

15

Zoom uses GNOME protocol for screen shots, it just uses it repetitively to create a sort of movie they call screenshare. In KDE the protocol for screenshots is similar to the one for screenshare. Therefore you need either to import GNOME functionality or adapt your software to the correct protocol. BTW the xdg protocol is also used in parallel by GNOME, so using it will solve all problems. Zoom developers are really that lazy.

16

It is tempting to leave all to devs, but I’m afraid this leads to nowhere. Monopolist could force some solutions, but in situations where Linux is a strong minority, the only way is to adapt, hopefully to the point it won’t compromise the security or the core of what Linux is. Wine/Proton and similar projects are just doing that. Sitting and waiting will not solve a problem, and it would take too long.

That is why, in face of such obstacle, it is a Plasma’s devs task, to figure out what solution would be the best in such situation. Maybe implement something similar as Gnome, or maybe there is other solution that I don’t know.

Making Plasma a good environment for corporate is a strong goal this year. Wayland is still a priority, because it is a future. Sooner or later, Plasma community must decide what to do about that problem. Possibly there is a chance to persuade Zoom devs to implement it eventually? Someone will have to figure this out. Also, how often such solution is used and is it worth it to create workarounds on our side. At the moment Zoom, with its flaws, is a strong player in that field and discussion should be started what to do about its Wayland deficiencies. Whatever the solution it may be, I hope it won’t take too long and in a year we will have some resolution or there will be a solution in sight.

17

Every other solution so far has implemented the wayland xdg protocol : Teams, Slack, Jitsi all use it

It is just zoom remaining

1 Like
18

https://bbs.archlinux.org/viewtopic.php?id=279473

Specifically

1 Like
19

Yeah, same. Can’t even imagine moving to Wayland without a sane way to issue Forward and Backward actions with 3-finger swipes not intercepted by hardcoded settings.
Also no way to save/restore session… No thanks.

20

I assume you are talking about browser page forward/backward actions. In this case, actually, Wayland has you covered! Wayland is able to properly pass along swipe actions to applications (e.g. Firefox), that way two-finger forward/backward gestures actually work natively like they do on Windows/Mac. You may need to set Firefox to Wayland mode for this to work, though.