knurpht@Lenovo-P16:~> fastfetch -l none
knurpht@Lenovo-P16
------------------
OS: openSUSE Tumbleweed x86_64
Host: 21K9CTO1WW (ThinkPad P16s Gen 2)
Kernel: Linux 6.18.9-1-default
Display (LEN41B7): 1920x1200 in 16", 60 Hz [Built-in]
DE: KDE Plasma 6.5.5
WM: KWin (Wayland)
CPU: AMD Ryzen 7 PRO 7840U (16) @ 5.13 GHz
GPU: AMD Radeon 780M Graphics [Integrated]
Memory: 6.56 GiB / 54.61 GiB (12%)
knurpht@Lenovo-P16:~>
Expected behaviour
Boot system
SDDM login screen appears
Login
Plasma DE appears
This used to work fine
The Issue
After system boot, SDDM login screen appears
User ( also a fresh new user ) logs in
Plasma DE starts loading, then freezing cursor and keyboard entry
After ~10 secs, keyboard is fully unresponsive, touchpad ditto, only a system reset possible
What I already tried
Update the system. This resulted in “weird plans from zypper”, I suspected a borked rpmdb so rebuilt that, dup went fine after that, but may have played a role (???). No solution
Create a new user, login as that user. No solution.
Move back from sddm.service to display-manager-legacy.sevice. No solution.
Search the journal, but could not see / find anything. No solution
Workaround found
In the SDDM login screen hit Ctrl+Alt+F2
Login as your user
check VTs with who -aH, check the PIDs with ps -ea | grep <PID>
Hit Ctrl+Alt+F1 to SDDM login screen
Try to login, the freeze happens, but a quick Ctrl+Alt+F2 brings back the tty of the logged in user
check VTs with who -aH, check the PIDs with ps -ea | grep <PID>, see that SDDM is now running on a different tty, the display did not switch to that one, Ctrl+Alt+F1 shows the SDDM login screen again, Ctrl+Alt+F(3,4,5,6 …replace by tty# found) brings back a fully working DE.
Questions
How could this be explained? Keep in mind the rebuild of the rpmdb.
Interesting, so we have 2 udev updates.
Each on its own is fine, mix them together and we have an issue.
Ddcutil makes the most sense since it only starts after ssdm for me, doesn’t seem to happen in gnome and maybe explains why x11 wasn’t affected.
rebooted, all fine.
removed the lock on the udev systemd
updated, rebooted
no mouse of keyboard under wayland, works fine under X11 (as I am typing there)
so I continue this in my own thread I guess as it seems different.
If you did not lock these two, and updated afterwards after unlocking the udev systemd, then the two above would also be updated again. Just wondering.
I’m running openSUSE Tumbleweed with KDE Plasma on a notebook with AMD Ryzen AI 9 HX 370 and ran into this issue, too. It was running fine until I updated it two days ago: as soon as I tried to login, the whole computer would freeze when trying to load the desktop.
I can confirm that the problem is caused by the ddcutil/libddcutil5/ddcutil-i2c-udev-rules 2.2.5 package updates. The ddcutil maintainer is aware of the issue and has released a hotfix by reverting a certain commit:
I hope the Tumbleweed maintainers will pick that up, soon. In the meantime, pinning those packages to version 2.2.1, so that they won’t be updated, solves the immediate issue, but I wonder if having this forums entry here is enough to raise attention to this issue. Would it make sense to also raise a bug in the openSUSE Bugzilla?