https://bugs.kde.org/show_bug.cgi?id=525195
Bug ID: 525195
Summary: QSGRenderThread high CPU after repeated display power
cycles on external USB-C monitor
Classification: Plasma
Product: kwin
Version First 6.7.4
Reported In:
Platform: CachyOS
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: multi-screen
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 195752
--> https://bugs.kde.org/attachment.cgi?id=195752&action=edit
perf recording
## Summary
On Plasma Wayland, the lock screen can enter a state where `QSGRenderThread`
consumes substantial CPU after repeated automatic display-off / wake cycles.
The problem appears to be specific to my external monitor when connected over
USB-C. I have not been able to reproduce it using the laptop's internal display
or using the same external monitor over HDMI.
The issue has been occurring for at least approximately 3 months and is
reproducible on a freshly booted and fully updated system.
## Hardware
* Laptop: ASUS ExpertBook PM3406CKA
* CPU: AMD Ryzen AI 7 350
* GPU: AMD Krackan / Radeon 840M / 860M Graphics (`1002:1114`)
* GPU kernel driver: `amdgpu`
* External monitor: Samsung M7 43"
* External monitor connection when affected: USB-C
* Laptop lid: closed throughout
* Session: Plasma Wayland
KScreen reports the external USB-C monitor as:
```text
Output: DP-2
Type: DisplayPort
Resolution: 3840x2160 @ 60 Hz
Scale: 1.3
Priority: 1
```
The internal display is still connected as `eDP-1`, but disabled while the lid
is closed.
## Software
Current system after `pacman -Syu`:
```text
plasmashell 6.7.4
kwin 6.7.4
Qt 6.11.2
Mesa 26.2.2
Wayland 1.26.0
Linux bench01 7.2.2-1-cachyos
x86_64
PREEMPT_DYNAMIC
```
Relevant package versions:
```text
kwin 6.7.4-7.1
plasma-workspace 6.7.4-3.1
plasma-desktop 6.7.4-1.1
qt6-base 6.11.2-3
qt6-declarative 6.11.2-1.1
qt6-wayland 6.11.2-1.1
mesa 3:26.2.2-2
egl-wayland 4:1.1.21-1.1
wayland 1.26.0-1.1
wayland-protocols 1.49-1
```
## Reproduction
The monitor is configured to turn off automatically after 2 minutes.
A typical successful reproduction is:
1. Boot with the Samsung M7 already connected over USB-C.
2. Keep the laptop lid closed.
3. Start/use the Plasma Wayland session normally.
4. Lock the session with Meta+L. The same behavior also occurs with automatic
locking.
5. Allow the display timeout to turn the external monitor off.
6. Move the mouse to wake the monitor.
7. Allow it to turn off again.
8. Move the mouse to wake it again.
9. Allow it to turn off again.
In successful reproductions, the CPU spike appears around the third automatic
display power cycle.
Once triggered, a `QSGRenderThread` consumes substantial CPU while the system
is otherwise idle.
## Reproduction matrix
```text
Configuration Result
------------------------------------------------- -------------------------
Internal laptop display only Cannot reproduce
Samsung M7 via HDMI, lid closed from boot Cannot reproduce
Samsung M7 via USB-C, lid closed from boot Reproduced 2/2 fresh boots
HDMI from boot, then switch to USB-C Reproduced once
```
This suggests that USB-C/external-output handling is involved, although I do
not know whether the underlying cause is in KWin, Qt Wayland, Mesa, DRM/KMS,
DPMS handling, or elsewhere.
## Actual behavior
After the problematic display power-cycle sequence, `QSGRenderThread`
persistently consumes substantial CPU.
I identified the affected thread with `top` / `ps` and recorded a 10-second
perf capture directly from its TID:
```text
sudo perf record -g -t <QSGRenderThread-TID> -F 1000 -- sleep 10
sudo perf report --stdio --percent-limit 1 > perfcapture1.txt
```
The capture reported:
```text
Total Lost Samples: 0
Samples: 4K of event 'cpu/cycles/P'
```
The profile contains substantial activity around:
* `ppoll()`
* `sendmsg()` / `recvmsg()`
* futex wake/wait operations
* scheduler wakeups
* Wayland socket activity
The interesting frame-presentation path includes:
```text
QRhi::endFrame(...)
-> QtWaylandClient::QWaylandGLContext::swapBuffers(...)
-> Mesa / libgallium
-> wl_display_roundtrip_queue()
-> wl_display_dispatch_queue()
-> wl_display_dispatch_queue_timeout()
-> wl_display_read_events()
-> ppoll()
```
The full `perf report --stdio` output is attached as `perfcapture1.txt`.
The attached perf capture was recorded when Mesa 26.2.1 was installed. The
problem remains reproducible after updating to Mesa 26.2.2.
I am not claiming that the above stack establishes the root cause. It appears
to indicate repeated Wayland/presentation synchronization activity while the
render thread is consuming CPU.
## Expected behavior
When the session is locked and the external monitor has powered off due to
inactivity, the render thread should remain idle unless rendering is actually
required.
Repeated display-off / wake cycles should not cause persistent high CPU usage.
## Additional notes
* The issue has existed on this machine for at least approximately two months.
* Disconnecting or switching display connections can appear to reset the
condition temporarily.
* USB-C-from-boot is currently the most reliable reproduction case.
* The same Samsung M7 connected over HDMI has not reproduced the issue so far.
* The laptop's internal panel alone has not reproduced the issue so far.
--
You are receiving this mail because:
You are watching all bug changes.
