https://bugs.kde.org/show_bug.cgi?id=523673
Bug ID: 523673
Summary: No wl_pointer events delivered to any client while the
cursor still moves; keyboard and touch unaffected; VT
switch recovers
Classification: Plasma
Product: kwin
Version First 6.7.3
Reported In:
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: input
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
Created attachment 194717
--> https://bugs.kde.org/attachment.cgi?id=194717&action=edit
wev output captured in the broken state: 62 wl_keyboard + 32 wl_touch events,
zero wl_pointer
## Summary
After ~2 days of compositor uptime the pointer became completely non-functional
for every client:
the cursor still moved on screen, but **no client received a single
`wl_pointer` event** any more —
no enter, no motion, no button, no axis. Keyboard and touch input continued to
work normally on the
same surface at the same time. The condition was independent of the input
device (it persisted across
a Bluetooth mouse and a separate 2.4 GHz USB dongle mouse) and survived
lock/unlock and a plasmashell
restart. Switching to another VT and back (`Ctrl+Alt+F3`, `Ctrl+Alt+F2`)
restored pointer input
immediately.
## Observed behaviour
* Cursor moves normally and is rendered correctly.
* Left/right/middle click do nothing, anywhere.
* Scroll wheel does nothing, anywhere.
* No hover/highlight feedback in any application, including Plasma panel and
window decorations.
* Inside the Overview effect (`Meta+W`) hover **does** work and windows
highlight under the cursor —
i.e. motion still reaches KWin's effect layer — but clicking there does not
activate a window either.
## What still works
* Keyboard: fully functional in all clients.
* Touchscreen: fully functional, taps activate widgets normally.
## Evidence — layer isolation
Two measurements taken while the system was in the broken state, on the same
machine, minutes apart.
**1. Kernel / evdev level — healthy.** Reading the mouse's `/dev/input/eventN`
directly for 15 s
while clicking and scrolling:
```
Button events (EV_KEY): 14 (BTN_LEFT / BTN_RIGHT, each with value=1 then
value=0)
Scroll events (WHEEL): 50 (REL_WHEEL + REL_WHEEL_HI_RES)
Motion events: 510
Raw HID reports: 385
```
`EVIOCGKEY` across all `/dev/input/event*` reported **no** stuck key or button
at kernel level.
So the device, the HID report descriptor, the HID parsing and evdev were all
working correctly.
**2. Wayland / client level — pointer missing entirely.** `wev` started fresh
in the broken state,
pointer deliberately moved across its window, clicked, scrolled, tapped, and
typed:
```
wl_keyboard 62 events (58 key press/release) <- control value, proves the
capture works
wl_touch 32 events (down / motion / up, with coordinates, surface: 3)
zwp_tablet 6 events
wl_pointer 0 events <- not even wl_pointer.enter
```
The seat advertised `capabilities: pointer keyboard touch`, and the surface
received
`wl_keyboard.enter`, but never `wl_pointer.enter`.
**Conclusion:** the input path is intact from hardware up to and including
evdev, and KWin still
delivers keyboard and touch to clients, but pointer events are not delivered to
any client.
The fault is confined to KWin's pointer path.
## What did NOT recover it
* Power-cycling the Bluetooth mouse and the Bluetooth adapter.
* Switching to a completely different mouse on a separate USB dongle (different
driver path).
* `loginctl lock-session` + unlock. *(Note: the lock screen only became visible
after pressing
`Alt+Tab`, which may be a second symptom worth looking at.)*
* `systemctl --user restart plasma-plasmashell.service`.
* Injecting synthetic button-release events for `BTN_LEFT`..`BTN_TASK` via a
uinput device
(libinput appears to discard a release with no preceding press).
* `Meta+W` (Overview) open/close, virtual desktop switch.
## What DID recover it
`Ctrl+Alt+F3` to another VT, then `Ctrl+Alt+F2` back. Pointer input worked
immediately again,
with no session restart and no loss of open windows.
## Suspected trigger (NOT proven)
Approximately 4 minutes before the failure was noticed, a Bluetooth LE mouse
(Logitech POP Mouse)
had repeatedly lost its connection — four reconnects within 30 minutes:
```
21:05:12 kernel: input: Logi POP Mouse as
.../0005:046D:B030.002E/input/input116
21:33:00 kernel: input: Logi POP Mouse as
.../0005:046D:B030.002F/input/input118
21:33:02 bluetoothd: profiles/input/hog-lib.c:output_written_cb() Write output
report failed:
Request attribute has encountered an unlikely error
21:33:05 kernel: input: Logi POP Mouse as
.../0005:046D:B030.0030/input/input120
21:33:24 kernel: input: Logi POP Mouse as
.../0005:046D:B030.0031/input/input122
```
The only KWin log line in the whole window is:
```
21:34:28 kwin_wayland_wrapper[1892]: Key repeat discarded, Wayland compositor
doesn't seem to be
processing events fast enough!
```
**Onset timing.** The failure was reported by the user within seconds to a few
minutes of first
noticing it, which places the onset between roughly 21:34 and 21:37 — i.e.
within ~1–4 minutes of
both the last Bluetooth reconnect (21:33:24) and the KWin log line above
(21:34:28). Nothing else
happened on the machine in that window.
Hypothesis: the device disconnected while a button was held, the corresponding
release was never
delivered, and KWin was left believing a pointer button is still down or a
pointer grab/drag is
still active — which would block pointer focus updates for all clients while
leaving keyboard and
touch unaffected. This is consistent with every observation, but was **not**
verified against
KWin's internal state.
## Honest limitations
* KWin's internal pointer/seat state was never inspected while broken — the VT
switch destroyed the
state before it could be captured.
* The onset is bounded to roughly 21:34–21:37 (reported within minutes of being
noticed), but the
causal link to the Bluetooth disconnects is correlation in time only — not
verified.
* No reproducer. The condition appeared once, after ~2 days of compositor
uptime.
* The machine also has a failing I2C touchpad (unrelated, kernel-level `-121
EREMOTEIO`); it was
already dead before this incident and stayed dead after the fix, so it is not
part of this bug.
## Environment
```
kwin 6.7.3
plasma-workspace 6.7.3
libinput 1.31.3
wayland 1.25.0
qt6-wayland 6.11.1
kernel 7.1.4-1-cachyos-bore
distro CachyOS (Arch-based)
session Wayland, Plasma 6
hardware Lenovo Yoga 7 2-in-1 14AKP10 (83JR), AMD Ryzen AI 7 350,
Radeon 860M
compositor uptime ~2 days at time of failure
```
## Attachments
* `wev-broken-state.log` — full `wev` output captured in the broken state (170
lines):
keyboard and touch events present, zero `wl_pointer`.
* `journal-incident-window.txt` — journal excerpt 21:00–21:45 covering the
Bluetooth reconnects
and the single KWin message.
## If it happens again, I can capture
* `wev` output proving `wl_pointer` starvation (as above).
* Raw evdev capture proving the kernel side is healthy (as above).
* KWin's debug console input tab (`qdbus6 org.kde.KWin /KWin
org.kde.KWin.showDebugConsole`),
which should show how KWin routes a click while wedged.
* On request, a core dump of `kwin_wayland` taken in the broken state — note
this would contain
full session memory, so it can only be shared privately with a developer.
--
You are receiving this mail because:
You are watching all bug changes.
