https://bugs.kde.org/show_bug.cgi?id=525537
Bug ID: 525537
Summary: After resume from suspend, plasmashell desktop window
repaints continuously at full refresh rate (~10% CPU
idle), until plasmashell is restarted
Classification: Plasma
Product: plasmashell
Version First 6.7.5
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: generic-performance
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: 1.0
SUMMARY
After resuming from suspend (closing and reopening the laptop lid),
plasmashell's desktop window begins repainting continuously at the display's
full refresh rate (120 Hz), even though nothing on the desktop changes. This
makes plasmashell use about 10% of a CPU core while the system is idle, and
kwin_wayland about 8% compositing those frames. The state persists indefinitely
until plasmashell is restarted, after which both drop to ~0%.
The problem reproduces with a completely default Plasma layout and a plain
solid-color wallpaper, so it does not appear to be caused by any widget,
wallpaper plugin, or user configuration. I have also tried removing any
fractional scaling to eliminate that as a potential issue.
STEPS TO REPRODUCE
1. Log in to a Plasma Wayland session. Confirm plasmashell and kwin_wayland are
idle (0-1 s of CPU time per 60 s, measured with the command under ADDITIONAL
INFORMATION).
2. Suspend the laptop by closing the lid for ~10 seconds.
3. Open the lid and unlock the screen.
4. Leave the system idle for 60 seconds and measure CPU time again.
OBSERVED RESULT
- After resume, plasmashell uses 4-6 s and kwin_wayland ~5 s of CPU time per 60
s of complete idle (normal is 0 s for both).
- With KWin's "Show Paint" effect enabled and the desktop shown (Meta+D), the
ENTIRE desktop area flashes continuously and very rapidly, i.e. the desktop
window is being redrawn every frame.
- plasmashell keeps rendering even when the desktop is fully covered by a
fullscreen window (Show Paint shows nothing because the desktop is occluded,
but plasmashell's CPU usage stays high).
- The state never recovers on its own. Restarting plasmashell (kquitapp6
plasmashell; kstart plasmashell) fixes it immediately until the next
suspend/resume.
EXPECTED RESULT
plasmashell's desktop window should not repaint when nothing changes, and CPU
usage should return to ~0% after resume, as it is before suspending.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Artix Linux (rolling, dinit init system, elogind instead of
systemd)
KDE Plasma Version: 6.7.5
KDE Frameworks Version: 6.30.0
Qt Version: 6.11.2
Kernel: 7.2.2-artix1-1.1
Graphics Platform: Wayland
Mesa: 1:26.2.2-1
Graphics Processor: Intel Arc B390
CPU: Intel Core Ultra X9 388H
Laptop model: Framework Laptop 13 pro
Display: 2880x1920 @ 120 Hz, VRR off, HDR off
Suspend mode: s2idle
ADDITIONAL INFORMATION
== Measurement method ==
CPU time consumed over exactly 60 seconds of no keyboard/mouse input:
k=$(pgrep -x kwin_wayland); p=$(pgrep -x plasmashell); a1=$(ps -p $k -o
times=); b1=$(ps -p $p -o times=); sleep 60; a2=$(ps -p $k -o times=); b2=$(ps
-p $p -o times=); echo "kwin: $((a2-a1))s plasmashell: $((b2-b1))s (per 60s)"
Before suspend / after a plasmashell restart: kwin: 0s plasmashell: 0s
After suspend + resume: kwin: 5s plasmashell: 4-6s
== plasmashell is the source, kwin is only compositing its frames ==
While in the bad state, stopping plasmashell (kquitapp6 plasmashell) and
measuring kwin_wayland alone for 60 s gave 0 s of CPU time. kwin's usage is
entirely a consequence of plasmashell submitting new frames.
== Busy threads (top -H) ==
Idle, healthy plasmashell: all threads at ~0%.
After resume, the busy threads are:
QSGRenderThread 2.7%
plasmashell 2.0% (main/GUI thread)
WaylandEventThr 1.3%
WaylandEventThr 1.3%
QThread 1.0%
(all others ~0%)
This pattern (scene graph render thread + main thread + Wayland event threads)
is consistent with a Qt Quick window stuck in a continuous render/present loop.
== Trigger isolation ==
- Suspend/resume via lid close: TRIGGERS the problem, reproducibly.
- Locking the screen WITHOUT suspending (qdbus6 org.freedesktop.ScreenSaver
/ScreenSaver Lock), then unlocking: does NOT trigger it (0 s / 0 s afterwards).
So the trigger is resume from suspend, not the lock screen.
== Ruled out (problem still reproduces after each change) ==
- Wallpaper: original was the MilkyWay wallpaper package (folder path). Changed
to a single explicit image file: still reproduces. Changed wallpaper plugin to
org.kde.color (plain black): still reproduces.
- User layout / widgets: moved
~/.config/plasma-org.kde.plasma.desktop-appletsrc aside and started plasmashell
with a fresh default layout: still reproduces.
- Panel: panel was auto-hide; set to Always Visible with Show Paint enabled:
the panel does not flash, only the desktop area does.
- Fractional scaling: original scale 1.7 (logical size 1695x1130, not an exact
division of 2880x1920). Changed to 1.6 (exact 1800x1200): still reproduces.
- Output configuration: `kscreen-doctor -o` after resume shows a single
enabled, connected eDP-1 output with the expected mode; no duplicate, ghost, or
disconnected outputs.
- Software rendering: KWin reports "OpenGL renderer string: Mesa Intel(R)
Arc(tm) B390 (PTL)", compositing type OpenGL. Not llvmpipe.
- KWin bug 522075 (idle CPU from direct-scanout/color-pipeline buffer
reallocation) is fixed in 6.7.3; I am on 6.7.5, and in any case kwin is idle
when plasmashell is not running.
== Other notes ==
- Because a freshly started plasmashell stays idle in the same post-resume
kernel/driver/compositor state, it looks like the plasmashell instance that
lives through the resume fails to recover from some resume-related event (e.g.
output reconfiguration or graphics reset notification from the new xe driver on
Panther Lake) and never leaves a continuous-update state.
- Possibly hardware-specific: Panther Lake / Xe3 is new hardware on the xe
driver; I could not find an existing report matching this.
- Happy to collect additional debug output.
--
You are receiving this mail because:
You are watching all bug changes.
