KDE Plasma users - beware of new qt6-qtwayland version 6.9.1-2 (breaks lockscreen, may cause app crashes)

I do! AMD CPU and Nvidia GPU here.

EDIT: I saw the issue on my laptop (intel iGPU, no discrete GPU). See later post for what I found on my AMD CPU / Nvidia GPU desktop.

Had a quick look at some other’s reports, where they mentioned hardware:

Here’s an example of an affected user with AMD iGPU: 2375356 – qt6-qtwayland 6.9.1-2 breaks KDE Plasma lockscreen, requiring user to drop to TTY to unlock session

This looks like an Intel iGPU here (based on log lines about “tigerlake … integrated display”):

So no really obvious pattern, though I could only find a handful of data points (i.e. reports where hardware is stated).

Hm. I have a tendency to suspect NVIDIA (partially due to my own biases from recent experiences), but if iGPUs are experiencing the same issue then I doubt it’s an NVIDIA problem. The next guess would be package interactions. Has anyone posted journalctl output yet?

Here are the tickets I know of with logs:

A prevalent factor I’ve seen is lines like this (from the KDE bugtracker ticket above):

#0  0x00007fcbf177919d in QWaylandXdgActivationV1::requestXdgActivationToken(QtWaylandClient::QWaylandDisplay*, wl_surface*, std::optional<unsigned int>, QString const&) [clone .constprop.0] () at /lib64/libLayerShellQtInterface.so.6

Specifically, the QWaylandXdgActivation class and libLayerShellQtInterface.so binary seem to be high up in the stack trace.

The involvement of libLayerShellQtInterface.so ties with the suggested cause that:

I suspect this might be an ABI breakage caused by a patch introduced in -2: https://src.fedoraproject.org/rpms/qt6-qtwayland/blob/f42/f/qtwayland-add-pointer-warp-support.patch#_236 (a new field pointerWarp was introduced which changed the layout of the QWaylandDisplay class).

In order to fix the issue, the patch in question should either be reworked to preserve ABI compatibility or removed entirely.

Rebuilding layer-shell-qt from source caused the issue to stop reproducing, confirming suspicions of ABI breakage.

However, the tickets where fcitx5 is involved don’t seem to go through that same binary and class, so the interaction might be different there. (Will try to find a stack trace illustrating that.)

1 Like

Here’s one like that (linked in the comment 2375356 – qt6-qtwayland 6.9.1-2 breaks KDE Plasma lockscreen, requiring user to drop to TTY to unlock session - the user later confirmed that downgrading qt6-qtwayland fixed the problem):

In this case there’s no sign of QWaylandXdgActivation and libLayerShellQtInterface.so.

Sorry - I realised I had a brain freeze in my earlier post - edited it, and will expand further here.

The machine that I saw the issue on was my laptop (Intel iGPU and no dGPU), not my machine with NVidia.

I had held off updating to 6.9.1-2 on my desktop (AMD CPU, NVidia GPU), but I gave it a try.

With the proprietary NVidia drivers and 6.9.1-2, there was no apparent problem with the lockscreen - locking and unlocking appeared as normal. Despite that though, in journalctl, a segfault did appear related to libLayerShellQtInterface:

kernel: kscreenlocker_g[3185]: segfault at 9a ip 00007f1f3648419d sp 00007ffcd646f150 error 4 in libLayerShellQtInterface.so.6.4.1[319d,7f1f36481000+7000] likely on CPU 7 (core 7, socket 0)

With nouveau and 6.9.1-2, I couldn’t even start a Plasma session because SDDM blackscreened. Excerpt of a stack trace

#0  0x00007fc4a268d19d _ZN23QWaylandXdgActivationV125requestXdgActivationTokenEPN15QtWaylandClient15QWaylandDisplayEP10wl_surfaceSt8optionalIjERK7QString.constprop.0 (libLayerShellQtInterface.so.6 + 0x319d)
#1  0x00007fc4a268d990 _ZN12LayerShellQt20QWaylandLayerSurface15requestActivateEv (libLayerShellQtInterface.so.6 + 0x3990)
#2  0x000055924fd3d40f _ZN4SDDM10GreeterApp16addViewForScreenEP7QScreen (/usr/bin/sddm-greeter-qt6 + 0x2040f)
#3  0x00007fc4a69657ba _Z10doActivateILb0EEvP7QObjectiPPv (libQt6Core.so.6 + 0x1657ba)

With nouveau and 6.9.1-1, there was no such problem and the system worked as normal.

So in fact, it seems like systems with the proprietary NVidia drivers may be one case where the problem with libLayerShellQtInterface can be recovered from without user-visible consequences.

Good morning! What would be the equivalent rpm-ostree command(s) to perform this downgrade task?

Are you able to roll back to a Kinoite deployment from before 20250628? That is probably the easiest approach: Updates, Upgrades & Rollbacks :: Fedora Docs

If that’s not possible, my understanding is that it’s possible to use rpm-ostree override replace to override the package to the previous good version, something like:

curl https://kojipkgs.fedoraproject.org//packages/qt6-qtwayland/6.9.1/1.fc42/x86_64/qt6-qtwayland-6.9.1-1.fc42.x86_64.rpm --output qt6-qtwayland.rpm
sudo rpm-ostree override replace ./qt6-qtwayland.rpm

(based on documentation here: Client administration | rpm-ostree)

CAUTION: I don’t use kinoite so I have not tested this, I’m only going by the documentation.

I’m also having this issue with kscreenlocker complaining about a segfault from libLayerShellQtInterface.so

I can temporarily fix it by removing kscreenlocker_greet’s cache folder, but it’s pretty short lived and a few minutes later goes back to being broken.

Running on an Intel i9-14900K, using the iGPU. I do have a Nvidia card, but it’s dedicated to vfio/gpu passthrough for a vm and isn’t used by the host.

Jul 02 09:30:11 fedora kscreenlocker_greet[16195]: qml: The backend got an unknown wallpaper provider type. The wallpaper will now fall back to the default. Please check your wallpaper configuration!
Jul 02 09:30:11 fedora audit[16195]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=16195 comm="kscreenlocker_g" exe="/usr/libexec/kscreenlocker_greet" sig=11 res=1
Jul 02 09:30:11 fedora kernel: kscreenlocker_g[16195]: segfault at b8 ip 00007fb2a5d5919d sp 00007ffeef99cd00 error 4 in libLayerShellQtInterface.so.6.4.1[319d,7fb2a5d56000+7000] likely on CPU 11 (core 20, socket 0)

Gonna try downgrading and see what happens I guess

Edit: downgrading qt6-qtwayland fixed it :slight_smile:
Edit2: Realized I just replied to the last message rather than the thread. Woops.

1 Like

Can someone please tell me if my problem is related to this? I would assume not, as this seems to be a Plasma issue, but just asking, in case.

To me it doesn’t look related to the issue in this thread.

My (not very confident) guess would be some kind of filesystem corruption when power was lost. But other folks with more BTRFS knowledge can hopefully tell you more about this.

Any idea if it can be fixed? :folded_hands:

If you’ve got Timeshift or similar set up, you could boot into a Live USB and then run it from there to restore to a known good restore point. Not saying this would fix it, but probably the first thing I would try.

A fixed version 6.9.1-3 has now been released to stable Fedora 42. This version reverts the problematic change in 6.9.1-2 and restores the behaviour of 6.9.1-1.

The “solution” post above has been updated to reflect this.

4 Likes

Unfortunately, I have no backups (very bad idea, I know)

In that case it sounds like something is probably corrupted, so I guess my next step would be to try reinstalling the OS while leaving the home directory in place. I’d also strongly recommend getting a backup solution in place, Timeshift is good: How to Setup Timeshift with BTRFS in Fedora? - GeeksforGeeks

You might want to open another thread looking for help before doing anything that has the potential to erase your data, as your issue is likely not related to the one in this thread.

FYI I’m running qt6-qtwayland-6.9.1-2.fc42.x86_64 atm.

At first I’ve got the black screen. After a little while I tried another sudo dnf update and it updates mesa to 25.0.7-2. A reboot made things running again.

So probably the issue was qt vs mesa related.