[plasmashell] [Bug 524391] New: [Wayland][DPMS][NVIDIA] Desktop containment stops receiving mouse clicks after display powers off and wakes; panel and applications remain interactive

https://bugs.kde.org/show_bug.cgi?id=524391

            Bug ID: 524391
           Summary: [Wayland][DPMS][NVIDIA] Desktop containment stops
                    receiving mouse clicks after display powers off and
                    wakes; panel and applications remain interactive
    Classification: Plasma
           Product: plasmashell
      Version First 6.7.4
       Reported In:
          Platform: Fedora RPMs
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: Containment
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected]
  Target Milestone: 1.0

Created attachment 195229
  --> https://bugs.kde.org/attachment.cgi?id=195229&action=edit
User journal covering lock, DPMS off, wake, unlock, and broken desktop clicks

Suggested product: plasmashell
Suggested component: Desktop Containment
Possible reassignment: KWin / Wayland input or output handling

TITLE

[Wayland][DPMS][NVIDIA] Desktop containment stops receiving mouse clicks after
display powers off and wakes; panel and applications remain interactive


SUMMARY

On a Fedora 44 KDE Plasma Wayland session, the empty desktop/Folder View stops
responding to left and right mouse clicks after the display is powered off by
DPMS while the session is locked, then woken and unlocked.

Report read and verified by human . Generated by gpt 5.6 sol.

The pointer still moves, the Plasma panel remains clickable, and application
windows remain interactive. KWin/libinput continues to record complete mouse
press and release events while the desktop is unresponsive. Restarting
plasmashell restores desktop clicking immediately.

Locking and unlocking without allowing the display to power off does not
trigger the problem. The failure therefore appears to be associated with the
DPMS display-off/wake transition rather than authentication or locking by
itself.

No KWin, plasmashell, KScreenLocker, or PowerDevil crash occurs. The attached
system log contains no NVIDIA Xid, GPU reset, DRM connector failure, or
out-of-memory event around the reproduction.


IMPACT

After unlocking, the desktop cannot be used normally:

* Right-clicking empty desktop space does not open the desktop context menu.
* Left-clicking the desktop has no visible effect.
* Desktop/Folder View interaction is unavailable.
* The panel and normal application windows continue to accept mouse input.

The practical workarounds are to restart plasmashell or prevent the display
from powering off. Restarting the whole graphical session is not required.


REPRODUCIBILITY

The issue was reproduced during a controlled diagnostic capture using the
sequence below. The important trigger observed so far is lock followed by DPMS
display-off, wake, and unlock.


STEPS TO REPRODUCE

1. Log in to a KDE Plasma Wayland session.
2. Confirm that left-click and right-click work on empty desktop space.
3. Lock the session.
4. Leave the system idle long enough for PowerDevil to turn the display off.
For this test, the display-off delay after locking was 20 seconds.
5. Wake the display with mouse or keyboard activity.
6. Authenticate and return to the desktop.
7. Left-click and right-click repeatedly on empty desktop space.
8. Click the Plasma panel or an application window for comparison.


OBSERVED RESULT

The empty desktop does not react to either mouse button. In particular,
right-click does not open the desktop context menu. The panel and application
windows remain interactive, and the pointer continues to move normally.

KWin/libinput records the physical mouse button presses and releases during the
failure. Restarting plasmashell recreates the desktop and restores normal
desktop clicking.


EXPECTED RESULT

After the display wakes and the session is unlocked, the desktop containment
should receive mouse input normally. Right-click should open the desktop
context menu, and left-click/desktop icon interaction should work without
restarting plasmashell.


CONTROL OBSERVATIONS

* Lock followed by unlock before the display powers off: desktop clicking
continues to work.
* Lock followed by DPMS display-off, wake, and unlock: desktop clicking stops
working.
* In the broken state, the panel remains clickable even though the desktop does
not.
* In the broken state, application windows remain clickable.
* Restarting plasmashell restores desktop clicking.
* The configured desktop containment is KDE's standard org.kde.plasma.folder
(Folder View).
* The configured panel and panel widgets are standard KDE components; no
third-party desktop containment was found in the Plasma layout.

A DPMS-only test with automatic locking disabled has not yet been performed.
Therefore, the current evidence shows that DPMS is required in the tested
sequence, but does not completely prove whether DPMS alone is sufficient or
whether the combination of KScreenLocker and DPMS is required.


PRECISE TIMELINE FROM THE ATTACHED USER JOURNAL

All timestamps below are local time on 2026-08-18 (Asia/Karachi, UTC+05:00).

06:10:21.668345
KWin begins showing/creating the lock window.

06:10:21.856406
PowerDevil logs:
"DPMS: registering idle timeout (screen lock activating) after 20000ms"

06:10:41.983370
PowerDevil logs:
"DPMS: starting to fade out"

06:10:41.983381
PowerDevil logs:
"DPMS: triggered on idle timeout, turning off display and keyboard backlight"

06:12:05.672793
Wake activity occurs while the session is still locked. PowerDevil registers
another timeout and identifies the screen as already locked.

06:12:16.723464
KScreenLocker authentication succeeds. The message mentioning the PAM
fail-delay function is followed by a successful authentication result and is
not an authentication failure.

06:12:16.723875
KWin logs:
"Unlocking now."

06:12:16.723877
KWin hides the lock window.

06:12:16.724762
PowerDevil registers the normal unlocked idle timeout.

Approximately 06:12:19 through 06:12:35
The reporter deliberately left-clicks and right-clicks repeatedly on the
unresponsive desktop. In this interval, the attached user journal contains 69
libinput press transitions and 69 matching release transitions, plus additional
OTHERBUTTON transitions. This confirms that button activity continued to reach
KWin/libinput while the desktop was broken.


SYSTEM AND SOFTWARE INFORMATION

Operating system: Fedora Linux 44 (Forty Four), x86_64
Kernel: 7.1.8-200.fc44.x86_64
Kernel build: #1 SMP PREEMPT_DYNAMIC Mon Aug 10 03:35:23 UTC 2026
Session type: Wayland

KDE Plasma Workspace: 6.7.4-1.fc44
KDE Plasma Desktop: 6.7.4-1.fc44
KWin: 6.7.4-2.fc44
KScreenLocker: 6.7.4-1.fc44
libkscreen: 6.7.4-1.fc44
KDE Frameworks/CoreAddons: 6.29.0-1.fc44
Qt Base: 6.11.1-1.fc44
Qt Wayland: 6.11.1-1.fc44

CPU: AMD Ryzen 7 9700X 8-Core Processor, 16 logical CPUs
Memory: 30 GiB


GRAPHICS HARDWARE AND DRIVER

Primary/display GPU:
NVIDIA GeForce GTX 1060 6GB (PCI ID 10de:1c03)
Kernel driver in use: nvidia
NVIDIA proprietary driver package: 580.173.02-1.fc44 (580xx series)
Kernel module package:
kmod-nvidia-580xx-7.1.8-200.fc44.x86_64-580.173.02-1.fc44

Additional integrated GPU:
AMD/ATI Granite Ridge Radeon Graphics (PCI ID 1002:13c0)
Kernel driver: amdgpu

The active display connector used in this reproduction belongs to the NVIDIA
DRM device.


DISPLAY CONFIGURATION

Number of connected displays: 1
Connector: DP-3
Manufacturer/EDID identifier: LG / GSM 30471
Mode: 3840 x 2160
Refresh rate: 59.997 Hz
Scale: 150% (1.5)
Transform: Normal
Position: 0,0
Variable refresh rate policy: Never
HDR: Disabled

The saved KWin output configuration contains one enabled output at a fixed
position. No multi-monitor rearrangement is involved in this reproduction.


SUBSYSTEM ANALYSIS

1. Physical mouse and libinput

The mouse hardware and libinput path remain operational. KWin logs complete
button press and release transitions during the broken period. This makes a
lost USB device, mouse hardware failure, and a total libinput failure very
unlikely.

2. KWin compositor/input stack

KWin remains running and continues to receive pointer button activity. The
pointer moves, application windows are interactive, and the panel remains
interactive. Therefore, KWin's entire input stack is not frozen.

However, the evidence does not rule out a KWin hit-testing/focus bug specific
to the desktop Wayland surface after output reactivation.

3. KScreenLocker/authentication

The lock window is created and later hidden normally. Authentication succeeds
and the greeter exits normally. There is no KScreenLocker crash or failed
unlock in the captured interval. Lock/unlock without DPMS does not reproduce
the problem, making the locker alone unlikely to be the cause.

4. PowerDevil/DPMS

PowerDevil performs the expected transition: it registers the 20-second
locked-screen timeout, fades out, powers the display off, observes wake
activity, and restores the unlocked timeout after authentication. DPMS is the
distinguishing event between the working and broken lock/unlock sequences.

5. Plasma Shell/Desktop Containment

Only the desktop portion of Plasma stops accepting clicks; the panel, which is
a separate Plasma surface, remains interactive. Restarting plasmashell
immediately restores desktop clicking. The configured desktop is the standard
Folder View containment.

This behavior strongly suggests that the desktop view/surface or its Wayland
input region is stale, missing, incorrectly mapped, or no longer selected by
KWin after the DPMS output reactivation.

6. Display/GPU reset path

No NVIDIA Xid, GPU reset, KWin crash, DRM connector failure, or output-removal
error was found around the transition. The saved output remains DP-3 at
3840x2160, scale 1.5, position 0,0. This does not completely exclude a
proprietary-driver-specific trigger, but there is no evidence of a general GPU
failure.


MOST LIKELY FAULT BOUNDARY

This is an evidence-based hypothesis, not a confirmed source-code root cause:

After the DPMS off/on cycle and lock-screen removal, Plasma's desktop
containment Wayland surface or input region is not correctly restored, or KWin
retains stale hit-testing information for that surface. As a result, physical
clicks reach KWin/libinput but are not delivered to the desktop containment.
The panel remains usable because it is represented by a separate Plasma
surface. Restarting plasmashell recreates the affected surface state and fixes
the problem.

The unresolved ownership boundary is between:

* plasmashell/plasma-workspace desktop view or containment surface lifecycle
during output reactivation; and
* KWin Wayland pointer focus, surface hit-testing, or output reactivation
handling.

The suggested initial component is plasmashell / Desktop Containment because
the failure is isolated to the desktop and is repaired by restarting
plasmashell. Reassignment to KWin may be appropriate if Plasma is publishing a
valid desktop surface and input region after wake.


ERRORS NOT FOUND DURING THE REPRODUCTION

* No plasmashell crash or segmentation fault.
* No KWin crash or segmentation fault.
* No KScreenLocker crash.
* No PowerDevil crash.
* No NVIDIA Xid message.
* No GPU reset/hang report.
* No out-of-memory termination.
* No display connector removal/re-add failure.
* No authentication failure.

The journal contains repeated "Could not create udmabuf: Invalid argument"
messages from KWin. These occur as general session noise and are not limited to
the DPMS failure transition, so no causal connection has been established.

A plasmashell screencast error appears later at 06:12:39, after the deliberate
desktop click interval and while another window was being opened. It refers to
a missing window ID and is not temporally associated with DPMS off, wake,
unlock, or the beginning of the desktop-input failure.


ADDITIONAL INPUT-LOGGING OBSERVATION

An earlier diagnostic capture temporarily enabled the broad Qt Wayland logging
wildcard. During deliberate clicks on the broken desktop, KWin/libinput logged
button events but no corresponding plasmashell Qt mouse-button events were
observed for the desktop. Moving to and clicking a separate Plasma surface such
as the panel did produce plasmashell activity. That earlier broad log was
discarded after it caused excessive journal volume; it is reported here as a
diagnostic observation but is not one of the attached files.

For the attached reproduction, broad qt.qpa.wayland.* logging was intentionally
disabled to avoid journal rate limiting. Focused KWin, Plasma, KScreenLocker,
PowerDevil, KScreen DPMS, idle-time, and KDE Wayland categories remained
enabled.


WORKAROUNDS

1. Restart plasmashell after the failure. This restores desktop clicking
without restarting KWin or logging out.
2. Avoid allowing the display to power off while the session is locked.
3. Lock and unlock before the DPMS timeout expires; this does not trigger the
issue in the observed control case.


ATTACHMENTS

1. dpms-user.log
   User-session journal containing the complete lock, DPMS-off, wake,
successful unlock, and deliberate post-unlock mouse-click sequence.
   Size: 369249 bytes
   SHA-256: 37449597f7d0c1f9be771007edbdc8f9f34606a0aca34698665d96ae5ff92f44

2. dpms-system.log
   System journal captured for the reproduction, used primarily to check for
NVIDIA, DRM, kernel, GPU-reset, crash, and resource-failure evidence.
   Size: 523650 bytes
   SHA-256: 9f5e366df50702b82b0c94483be81b9593c437063daf19160f68b7551d9a64c1

The two attached logs are unmodified diagnostic captures.


QUESTIONS FOR MAINTAINERS / USEFUL FOLLOW-UP

If additional evidence is needed, please advise which state should be captured
from KWin and plasmashell while the desktop is broken. In particular, the
reporter can collect focused qt.qpa.wayland.input logging, KWin
supportInformation, output state before and after DPMS, or test whether the
trigger remains at 100% scale and/or with automatic locking disabled.

-- 
You are receiving this mail because:
You are watching all bug changes.