Bug 488299

Summary:	Plasma wayland session becomes unresponsive when attaching external screens
Product:	[Plasma] kwin	Reporter:	notepass
Component:	wayland-generic	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED WORKSFORME
Severity:	normal	CC:	kde, notepass, xaver.hugl
Priority:	NOR
Version First Reported In:	5.27.11
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Log of kwin since boot and when the issue appears

Description notepass 2024-06-10 11:47:56 UTC

SUMMARY
When attaching multiple external screens via MST over USB-C (DP alt mode, no thunderbolt/USB 4) with Plasma running in wayland mode the session will become unresponsive.
The unresponsive state can be described as following: The external screens will not show any image, but report "No Signal". They will still come out of standby. The internal screen will continue to show the image active before connecting the external screens. The image on the internal screen is non-responsive to any inputs (Mouse, Keyboard). When the external screens are disconnected, the internal screen will start working normally again.
It seems like Plasma is actually working on rearranging the windows on display after disconnecting the external screens. Also sound continues like normal. No Plasma components seem to crash (most of the time). So it seems like Plasma is actually continuing to work but not displaying any updates on any screen.

STEPS TO REPRODUCE
1. Connect device to MST hub via USB-C
2. Observe screens

OBSERVED RESULT
Plasma session becomes visually unresponsive but seems to continue to work in the background.

EXPECTED RESULT
Plasma session continues normally on the connected screens.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Kernel 6.8.0-35-generic on Kubuntu 24.04
(available in About System)
KDE Plasma Version: 5.27.11
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.13

ADDITIONAL INFORMATION
This behaviour is exclusive to plasma in wayland mode. X11 works as expected, so does GNOME in wayland mode on the same machine. It seems that this issue also only occurs on one specific laptop for me (Framework Laptop 13" with AMD Ryzen 5 7640U). The same setup with an old HP EliteBook 1030 G3 (Some 8th gen i5) is working fine, even with the same SSD. The issue is also persistent across multiple distros (Tested with Debian, Fedora, Manjaro and Ubuntu).

The hardware in use:
- Framework Laptop 13" with AMD Ryzen 5 7640U
- Two Samsung S27A600UUU displays.

Hardware configuration:
- The laptop is connected to one of the displays via USB-C. This connection carries USB 2, DP and Power (60W)
- The first display is connected to the second display via DP. This only carries a DP signal
- The first display is put into MST mode, so that the two screens can display separate images

Please note that I only tested connecting screens via USB-C as I do not have any other possibility of connecting displays. I also did not try another MST hub (I think I have 2 somewhere here). If helpful, I can try a few more combinations of those.
Additionally, as this is not a crash, I do not know which logs to attach, but will gladly contribute anything that might help.

Comment 1 Zamundaaa 2024-06-10 12:13:41 UTC

> Additionally, as this is not a crash, I do not know which logs to attach, but will gladly contribute anything that might help.
KWin's log might help:
> journalctl --user-unit plasma-kwin_wayland --boot 0
(after reproducing the issue without rebooting)

If you set KWIN_DRM_PREFER_COLOR_DEPTH=24 for KWin (just put it into /etc/environment and reboot), do the external screens work then?

Also, if you try a live boot of some distribution with Plasma 6, does that work?

Comment 2 notepass 2024-06-10 12:56:39 UTC

Created attachment 170332 [details]
Log of kwin since boot and when the issue appears

> If you set KWIN_DRM_PREFER_COLOR_DEPTH=24 for KWin (just put it into /etc/environment and reboot), do the external screens work then?
Sadly not. I added the var, rebooted the system and had the same result. I have now removed it again and rebooted again to restore the previous state.

> KWin's log might help
Alrighty, I attached that one. A complete log since boot and an excerpt where I ran "journalctl --user-unit plasma-kwin_wayland -n 0 -f" while attaching and disconnecting an external screen. Both are in the same file as I can only upload one file at once.

> Also, if you try a live boot of some distribution with Plasma 6, does that work?
I threw a copy of the current KDE neon dev build (neon-testing-20240607-0934.iso) on a USB stick and booted that. The same issue appears there.

Comment 3 notepass 2024-06-16 10:53:19 UTC

I don't know if I should be playing with the status, but putting it back from "Needs info" to "reported"

Comment 4 Zamundaaa 2024-07-22 19:45:31 UTC

(In reply to notepass from comment #3)
> I don't know if I should be playing with the status, but putting it back
> from "Needs info" to "reported"
Yes, putting it back to reported is correct.

> kwin_core: Applying KScreen config failed!
That in the log means there's some serious problem with the display config. Could you follow the guide at https://invent.kde.org/plasma/kwin/-/wikis/Debugging-DRM-issues and provide a drm debug log for when it fails? It might reveal why applying the config fails.

Comment 5 Bug Janitor Service 2024-08-06 03:46:28 UTC

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

Comment 6 notepass 2024-08-19 21:51:21 UTC

I can no longer reproduce the issue with neon-unstable-20240807-1052.
If needed, I can try it with an older version. But the affected device will be out of order for a few days.

Comment 7 David Edmundson 2024-09-27 08:37:47 UTC

closing based on the user's feedback