https://bugs.kde.org/show_bug.cgi?id=523463
Bug ID: 523463
Summary: KWin/Wayland: pointer clicks intermittently stop being
delivered (client windows and sometimes KWin's own
UI), triggered by resume or occurring spontaneously
Classification: Plasma
Product: kwin
Version First unspecified
Reported In:
Platform: Bazzite
OS: Linux
Status: REPORTED
Severity: crash
Priority: NOR
Component: compositing
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 194589
--> https://bugs.kde.org/attachment.cgi?id=194589&action=edit
Full report from Troubleshooting
DESCRIPTION
The on-screen mouse cursor continues to move normally, and libinput reports
clean BTN_LEFT/BTN_RIGHT press/release and motion events with no drops — but
pointer events silently stop being delivered to client (and sometimes KWin's
own) surfaces: mouse button clicks have no effect, and hovering over items that
normally highlight on pointer-enter (e.g., Task Manager taskbar entries) also
fails to highlight. This shows the whole pointer-to-surface event pipeline
(enter/leave, motion, button) is affected, not just button delivery
specifically — the cursor's visible on-screen movement is purely
compositor-side rendering and is decoupled from whether pointer events actually
reach any surface. Keyboard shortcuts handled directly by KWin (Meta key,
Alt+Tab) continue to work throughout. No visible error, crash, or freeze;
clicking and hovering simply have no effect.
I've seen this in three distinct forms:
1. Resume-triggered, persistent — immediately after resuming from suspend,
coinciding with a logged Applying output configuration failed!. Clicking is
broken for the remainder of the session; only a full logout/login (fresh KWin
process) recovers it.
2. Spontaneous, transient — no suspend/resume involved, no output
reconfiguration failure logged, nothing else unusual in the journal. Clicking
silently stops working for roughly 5-10 seconds, then resumes on its own.
3. Spontaneous, persistent, affecting KWin's own UI — same as form 2, but does
not clear on its own, and also breaks clicking inside KWin's own
logout/power-menu dialog (opened via Ctrl+Alt+Delete), requiring keyboard-only
navigation to recover.
Direct protocol-level confirmation: I traced a freshly-launched client with
WAYLAND_DEBUG=1 during a live occurrence. wl_keyboard.enter/.leave fired
normally on its surface, but its wl_pointer object received zero events of any
kind (no .enter, .motion, .button, .leave, .frame) despite the pointer being
moved onto and clicked within the surface. So KWin's keyboard-focus dispatch
keeps working normally during the bug while pointer-focus dispatch is
completely stalled — for a brand-new surface, ruling out stale/cached focus
state on pre-existing windows.
A cheap workaround: unplugging/replugging the mouse's USB receiver has
recovered it without a logout/login (confirmed via unchanged kwin_wayland
PID/uptime), though it's not a guaranteed fix — the bug has recurred within
minutes even after a successful replug-triggered recovery.
STEPS TO REPRODUCE
1. Suspend the system to RAM, then resume — or, alternatively, just use the
desktop normally for an extended period (the spontaneous forms need no
suspend/resume at all).
2. Attempt to click on any application window, taskbar entry, or icon.
3. Observe that clicking has no effect, while the cursor still moves and
keyboard shortcuts (Meta, Alt+Tab) still work.
OBSERVED RESULT
Pointer button (and enter/leave/motion) events stop being delivered to any
client window, existing or newly opened. In the resume-triggered form this
persists until a full logout/login. In the spontaneous form it sometimes clears
itself after 5-10 seconds; in its more severe form it doesn't clear and also
breaks KWin's own logout dialog. There's no visible indication to the user of
what's wrong or that recovery is imminent.
EXPECTED RESULT
Pointer button event delivery to client surfaces should keep working regardless
of whether output reconfiguration succeeds or fails, and regardless of whatever
internal state triggers the spontaneous forms. A stuck pointer-focus state
should never be reachable through normal use.
SOFTWARE/OS VERSIONS
Operating System: Bazzite 44 (Fedora 44 base, kernel 7.1.3-ogc5.1.fc44.x86_64 —
Universal Blue/Bazzite custom kernel build)
KDE Plasma Version: 6.7.3
KDE Frameworks Version: 6.28.0
Qt Version: 6.11.1
ADDITIONAL INFORMATION
Multi-monitor setup (one output enabled, two deliberately disabled — unrelated
to this bug). One occurrence coincided with these log lines ~2-3s before the
click failure, timed with plasma-krunner.service D-Bus activation:
QDBusConnection: couldn't handle call to Teardown, no slot matched / Could not
find slot Krunner1Adaptor::Teardown — not reproduced on other occurrences, so
possibly an unrelated D-Bus binding bug, but flagged in case it's a symptom of
the same underlying issue. A fast non-invasive tell for whether the bug is
currently active: hover the taskbar — normally it highlights on pointer-enter,
but doesn't during the bug (this isn't a perfect indicator though; one
occurrence had the taskbar working fine while clicks failed inside an
already-open app's content). Happy to gather
QT_LOGGING_RULES="kwin_*.debug=true" output on request.
--
You are receiving this mail because:
You are watching all bug changes.
