https://bugs.kde.org/show_bug.cgi?id=492506
dominik.klementow...@protonmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dominik.klementowski@proton
| |mail.com
--- Comment #7 from dominik.klementow...@protonmail.com ---
It appears to be specific to Ubuntu/Neon base as I could reproduce the problem
on Ubuntu 22.04 and Ubuntu 24.04 both with Plasma compiled from source and
using Neon's repositories for `noble`. I can't reproduce this on same Plasma
(6.1.5) Frameworks (6.5.0) and Qt (6.7.2) on Arch Linux (but I only try with
different machine, maybe I'll setup Neon on my unaffected laptop with Arch if
further investigation is needed).
I think I've found a way to reproduce it. For me it rarely happens itself when
just using the laptop's screen, but I can reproduce it 100% of the time when I
do the following:
1. Connect an additional screen over HDMI or DP
2. Suspend the machine and remove the screen at the same time (behavior like
this can also happen when disconnecting screen with lid being closed)
3. Resume it from sleep
4. If it's frozen then go to 7.
5. Wait a couple of seconds after it resumes and it should lockup, if that's
the case go to 7.
6. If it's still not locked up, it will right after connecting the screen back
(even though it continues to display whatever was the last frame before lockup)
7. Done
The observed result is just like OP's describing. No frame updates ever again
and no reaction to any input, even trying to swith to other TTY doesn't work. I
can SSH on the machine and kwin_wayland occupies 100% of a CPU thread. Killing
kwin_wayland brings it back and it continues to work normally, unless trying to
reproduce.
I also tried to get traces out of kwin when it locks up. If I can provide
something more useful, let me know. Since I still have plasma installation
compiled from source.
--
You are receiving this mail because:
You are watching all bug changes.
