https://bugs.kde.org/show_bug.cgi?id=522634
Bug ID: 522634
Summary: # Evidence snapshot — Plasma Wayland input lockout
(2026-07-04 ~23:09–23:16)
Classification: Plasma
Product: kwin
Version First 6.7.0
Reported In:
Platform: Neon
OS: Linux
Status: REPORTED
Severity: critical
Priority: NOR
Component: input
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
Created attachment 194016
--> https://bugs.kde.org/attachment.cgi?id=194016&action=edit
new summary info about system (KDE Neon)
# Evidence snapshot — Plasma Wayland input lockout (2026-07-04 ~23:09–23:16)
Companion to `~/kde-bug-report.md` (see new **Issue 4**). Read-only forensics;
no processes
were killed during collection (antigravity-ide / ollama left running per user
request).
## Incident
- **Session:** Plasma Wayland, fresh login this evening. kwin PID **1879**
(elapsed 02:25),
plasmashell PID **2117**. `loginctl`: `Type=wayland Class=user Active=yes
State=active`
on `tty1`.
- **Time of hang:** ~2026-07-04 23:09–23:10 (user noticed ~23:16).
- **Symptoms (user-reported, consistent):**
- Mouse cursor **invisible** when still; only the *shake-cursor* effect
enlarges it while
shaking the mouse, then it disappears again when still.
- **Mouse clicks do nothing.**
- **Alt+Tab does nothing.**
- **Global shortcuts do nothing** (Ctrl+Alt+Del, Meta, …).
- **TTY switch (Ctrl+Alt+F2/F3) does nothing** — user cannot escape to a
virtual terminal.
## Forensic state at time of hang (read-only)
### kwin is alive and responsive — this is NOT a compositor crash/hang
- `ps -o pid,stat,pcpu,etime -p 1879`: `SLl`, **4.7–5.4 % CPU**, elapsed 02:25
— running,
not frozen.
- Threads (main TID 1879 + workers) all in `Sl`/`SNl`, `WCHAN -` (no kernel
sleep / no
futex deadlock):
```
PID TID STAT WCHAN %CPU COMMAND
1879 1879 Sl - 4.7 kwin_wayland
1879 1926 Sl - 0.0 QDBusConnection
1879 1927 Sl - 0.0 kwin_wayla:cs0
… (cs0/sh0/disk/traceq workers, all 0.0 %)
```
- **kwin answers DBus:** `qdbus6 org.kde.KWin /KWin supportInformation` returns
354 lines
(saved to `~/kde-bug-evidence-kwin-support.txt`, 7122 bytes). So the main
event loop is
*not* blocked.
- kwin `supportInformation` reports the `Cursor` / `shakecursor` plugin but
does **NOT**
report any active pointer lock / confinement / keyboard grab — the grab is
invisible via
the standard introspection.
### plasmashell is alive
- `ps -p 2117`: `SLsl`, **1.8 % CPU**, elapsed 02:25.
### Display / GPU are fine — NOT a modeset / GPU fault
- `/sys/class/drm/card2-HDMI-A-2/status = connected`
- `/sys/class/drm/card2-HDMI-A-2/enabled = enabled`
- `journalctl -k --since "10 min ago" | grep
amdgpu|drm|gpu|reset|fault|hung|lock` →
**empty** (no amdgpu/drm kernel errors, no GPU reset).
- `coredumpctl list --since "15 min ago"` → **empty** (no new core dumps).
### kglobalaccel is NOT running (Issue 3 reproduces on a *fresh* session)
- `systemctl --user is-active plasma-kglobalaccel.service` → **inactive**
- `pgrep -af kglobalaccel` → none
- This is a clean evening session (not the corrupted afternoon one), so Issue 3
is
reproducible on a normal login, independent of the input-grab incident.
## Timeline around the hang (`journalctl --user --since 23:07 --until 23:13`)
```
23:07:05 org.telegram.desktop qt.gui.imageio.jpeg: Corrupt JPEG data:
premature end … (×many)
23:07:31 steam Background update loop / manifest download
(benign)
23:09:05 org.telegram.desktop [libvpx-vp9 @ …] v1.15.2 ← Telegram
decoding video
23:09:23 plasmashell PipeWire remote error: -2 target not found
23:09:23 plasmashell PipeWire remote error: -2 unknown resource 4
op:4
23:09:23 plasmashell PipeWire remote error: -2 unknown resource 4
op:7
23:09:44 systemd Started
app-flatpak-org.telegram.desktop-84764.scope
23:09:44 xdg-desktop-portal-kde No node found for item that was removed:
…/Снимок экрана_*.png (×3, benign)
23:12:57 kdeconnectd No uuids found for "A9:DA:F5:92:E5:A8" (benign)
```
Concurrent GUI clients at hang time: **antigravity-ide** (Electron, 3.8 % CPU),
**Google Chrome** (native Wayland, `--ozone-platform=wayland`, many renderers
spawned
23:08–23:10), **Telegram** (flatpak, playing VP9 video), Steam, kdeconnectd.
## Interpretation (for the bug report)
The symptom set — *cursor hidden, no clicks, no Alt+Tab, no global shortcuts,
**no TTY
switch*** — is consistent with a Wayland client holding an **exclusive pointer
+
keyboard grab** (pointer lock / confinement + keyboard grab), which:
1. hides the system cursor (only the `shakecursor` "find cursor" effect makes
it briefly
visible), and
2. captures keyboard so kwin never sees Ctrl+Alt+F* → **logind never gets the
VT-switch
request → the user is locked out of even dropping to a TTY**.
The critical KDE/kwin defect is the **recovery gap**: when this happens kwin
- is healthy and responsive (DBus works, no crash, no GPU fault),
- does **not** expose which client holds the grab (`supportInformation` shows
nothing),
- provides **no mechanism to forcibly break an active pointer/keyboard grab**
or to
re-route VT-switch combos when a client has the keyboard grabbed,
- so the only recovery is to identify and kill the grabbing client from a
**second channel
(SSH)** — impossible from the seat itself because TTY switch is also blocked.
See `~/kde-bug-report.md` → **Issue 4**.
## Additional observations after the snapshot (2026-07-04/05)
- **DPMS / keyboard wake (user-reported):** during the lockout the screen first
dimmed
(idle DPMS) and then lost signal, but **pressing keys on the keyboard woke
the screen
back up**. This shows keystrokes *do* reach kwin (DPMS un-blank is driven by
kwin's input
path); the grab consumes them *after* arrival, before shortcut/VT-switch
dispatch. So the
defect is "input consumed by the grab before the VT-switch fast-path", not
"input never
arrives". Strengthens the fix direction: VT-switch combos must be handled in
kwin at a
layer a client keyboard grab cannot swallow.
- **Killing non-protected GUI clients did not release the grab.** Via SSH the
user killed
Chrome (native Wayland), Telegram (flatpak), Steam, qBittorrent — input did
**not**
return. `antigravity-ide` was intentionally left alive (running the long
compute). So
either the grabber was the one survivor (antigravity), or kwin kept a stale
grab after
the grabbing client died — both confirm the recovery-gap defect; kwin
exposing the
grabbing client PID/surface would have told the branches apart.
- **Compute ran on the *other* GPU throughout.** Long task on RX 6900 XT
(`card1`,
GPU0) at 90–99 % for ~35 min straddling the lockout; display on Vega
(`card2`). No
`amdgpu`/`drm` errors, no GPU reset, no core dumps on either GPU → not a
GPU/modeset
fault; kwin healthy while grab stuck. (Concurrent benign kernel noise:
`workqueue: svm_range_restore_work [amdgpu] hogged CPU for >10000us … 35
times` at
00:19–00:20 — ROCm/HMM SVM migration under the heavy GPU0 job, ended with the
job; not a
GPU fault, unrelated to the display/input path.)
## Conclusive test (2026-07-05 ~00:25): stale grab outlives ALL clients
After the compute finished, the entire `antigravity-ide` tree was killed (main
+ zygotes +
`--type=utility` node service + 4 MCP children). Combined with the earlier
kills
(Chrome/Telegram/Steam/qBittorrent), **no Wayland client remained alive**. A
`/proc/*/fd`
scan for sockets on `wayland-0` (kwin/plasma-shell filtered out) showed **zero
external
Wayland clients connected**. Yet the lockout persisted unchanged:
- kwin (PID 1879) still `Sl`, ~4 % CPU, DBus-responsive (healthy).
- `card2-HDMI-A-2` still `connected`/`enabled` (signal present — not a modeset
fault).
- Fresh `supportInformation` →
`~/kde-bug-evidence-kwin-support-ALL-CLIENTS-DEAD.txt`
(354 lines / 7122 B, identical size to the during-incident snapshot) **still
reports no
pointer lock / confinement / keyboard grab**.
→ **kwin retains an exclusive pointer+keyboard grab after the grabbing client
died and its
Wayland connection is gone.** The grab's owner is neither tracked nor exposed,
so kwin
never notices it is gone and never releases it. With no client left to blame,
the only
remaining grab holder is kwin itself. Recovery required restarting kwin (which
on this
setup tears down the session — Issue 1). This is the strongest evidence for the
recovery-gap defect (Issue 4, stale-grab branch).
## Reproduction hints (not confirmed — client not killed per user request)
Most likely grabber candidates in this incident, in order of suspicion:
1. **antigravity-ide** (Electron) — caused the *identical* symptom earlier the
same day
(2026-07-03 ~15:11); killing it restored input then.
2. **Google Chrome** (native Wayland) — a tab with pointer lock (fullscreen
video / canvas /
game) could hold pointer+keyboard grab; many renderers spawned right before
the hang.
3. **Telegram** (flatpak) — was playing a VP9 video and triggered plasmashell
PipeWire
errors at 23:09:23, immediately before the hang.
To pin it next time (from SSH, non-destructively): before killing anything,
capture
`qdbus6 org.kde.KWin /KWin supportInformation`, `sudo fuser -v /dev/dri/card2`,
and a
`gdb -p $(pgrep -x kwin_wayland) -batch -ex 'thread apply all bt'` backtrace,
then kill
suspects one at a time (chrome → telegram → antigravity) until input returns.
+
## Issue 4 — kwin input lockout: a client's pointer+keyboard grab can't be
diagnosed, broken, or escaped from (no TTY switch) while kwin stays healthy
**Component:** `kwin` (Wayland input / pointer confinement / keyboard grab /
VT-switch routing)
### Summary
A Wayland client holding an **exclusive pointer + keyboard grab** (pointer
lock/confinement
plus keyboard grab, e.g. a game-like surface or an Electron app in a bad state)
leaves the
session unusable: the system cursor is hidden, mouse clicks / Alt+Tab / global
shortcuts do
nothing, and — critically — **Ctrl+Alt+F2/F3 (VT switch) also does nothing**,
so the user
cannot even drop to a text TTY to recover. Throughout this, **kwin itself stays
alive,
responsive to DBus, with no crash and no GPU fault**, yet it (a) does not
expose which
client holds the grab, and (b) provides no way to forcibly break the grab or to
keep routing
VT-switch combos to `logind` when a client has the keyboard grabbed. Recovery
requires a
second access channel (SSH) to find and kill the grabbing client.
### Steps to reproduce
Triggered twice on this setup (2026-07-03 ~15:11 and 2026-07-04 ~23:10) by
running
`antigravity-ide` (Electron) and/or a Wayland client (Chrome native Wayland /
Telegram
flatpak playing video) that enters a pointer+keyboard grab. Exact trigger
inside the client
not isolated, but the *kwin-side* defect is independent of the specific client.
### Expected
- kwin exposes the active pointer/keyboard grab (which client, which surface)
in
`supportInformation` or a debug interface.
- kwin can forcibly drop a client's grab (or the user can, via a
shortcut/setting).
- VT-switch combos (Ctrl+Alt+F*) are **always** routed to `logind` even when a
client has an
exclusive keyboard grab, so the user can always escape to a TTY.
- The `shakecursor` "find cursor" effect should not be the only way to tell the
cursor is
hidden by a grab.
### Actual
- Cursor invisible; only `shakecursor` enlarges it while shaking, then it
disappears again.
- Mouse clicks, Alt+Tab, all global shortcuts, and **Ctrl+Alt+F2/F3** do
nothing.
- kwin is healthy: `ps` shows it running (~5 % CPU, threads `Sl`/`SNl`, no
kernel wchan),
`qdbus6 org.kde.KWin /KWin supportInformation` returns full data — main loop
not blocked.
- `supportInformation` reports **no** pointer lock/confinement/keyboard grab —
the grab is
invisible via introspection.
- No `amdgpu`/`drm` kernel errors, no GPU reset, no core dumps.
- `kglobalaccel` already not running in the same session (Issue 3), so
shortcuts were dead
independently — but the **TTY switch** failing is purely the client keyboard
grab, not
kglobalaccel.
### Additional observations (2026-07-04 → 07-05, second incident)
These were collected after the original `supportInformation` snapshot and
refine the
diagnosis above.
- **Keys do reach kwin — DPMS proves it.** During the lockout the display first
dimmed
(idle DPMS) and then lost signal; pressing keys on the keyboard **woke the
screen back
up** (DPMS un-blank). So keystrokes are not blocked before kwin — kwin's
input path
receives them (enough to drive DPMS wakeup). The grab therefore swallows them
*after*
they enter kwin, before they reach shortcut dispatch / VT-switch routing.
This narrows
the defect: it is not "input never arrives", it is "input arrives but is
consumed by the
active grab before the VT-switch/shortcut fast-path". The VT-switch fast-path
must run at
a layer a client keyboard grab cannot consume — same conclusion as the
suggested fix, now
with evidence that the keys are present in kwin.
- **Killing the suspected grabbing clients did NOT release the grab — and after
killing
*every* Wayland client it STILL didn't.** From SSH the user killed, in order:
Google
Chrome (native Wayland), Telegram (flatpak), Steam, qBittorrent — input did
not return.
Later, once the protected compute finished, the entire `antigravity-ide` tree
(main +
zygotes + the `--type=utility` node service + its 4 MCP children) was killed
too.
**After every GUI/Wayland client was dead, the lockout persisted unchanged.**
A scan of
`/proc/*/fd` for sockets bound to `wayland-0` (filtering out
kwin/plasma-shell itself)
showed **zero external Wayland clients connected**, yet:
- kwin stayed healthy (`Sl`, ~4 % CPU, main loop answering DBus),
- the display output stayed enabled (`card2-HDMI-A-2` `connected`/`enabled`,
signal
present),
- a fresh `qdbus6 org.kde.KWin /KWin supportInformation` (saved to
`~/kde-bug-evidence-kwin-support-ALL-CLIENTS-DEAD.txt`, 354 lines / 7122 B
— identical
size to the during-incident snapshot) **still reports no pointer lock /
confinement /
keyboard grab**.
This is conclusive for the **stale-grab** branch: **kwin retains an exclusive
pointer+keyboard grab after the grabbing client has died and its Wayland
connection is
gone.** The grab's owning client/surface is neither tracked nor exposed, so
kwin never
notices the owner is gone and never releases it. Recovery then requires
restarting
kwin — which on this setup tears down the whole session (Issue 1). This is
the strongest
evidence for the recovery-gap defect: with no client alive to blame, the only
remaining
grab holder is kwin itself.
- **Heavy compute on the *other* GPU throughout — not a GPU fault.** The long
task ran on
the discrete RX 6900 XT (`card1`/renderD128, GPU0) at 90–99 % util for ~35
min straddling
the lockout, while the display is on the integrated Vega
(`card2`/renderD129). No
`amdgpu`/`drm` kernel errors, no GPU reset, no core dumps on either GPU —
rules out a
GPU/modeset fault as the cause of the input lockout and reinforces that kwin
itself is
healthy while the grab is stuck.
### Evidence
Full read-only forensic snapshot saved to
`~/kde-bug-evidence-2026-07-04-2316.md`
(timeline, kwin/plasmashell state, thread list, DRM/output state, journal
excerpts) and
kwin `supportInformation` to `~/kde-bug-evidence-kwin-support.txt`.
### Suggested fix directions
- Always handle VT-switch shortcuts in kwin at a layer that a client keyboard
grab cannot
swallow (treat them like the SysRq / reset path), forwarding to
`org.freedesktop.login1` Seat.SwitchTo.
- Expose active pointer confinement / keyboard grabs in `supportInformation`
(or a
`kwin_debug` dbus interface) with the owning client PID/surface.
- Provide a user-actionable way to break a stuck grab (e.g. a magic key combo
handled
outside the grab, or an automatic release when the grabbing client stops
rendering /
crashes).
---
--
You are receiving this mail because:
You are watching all bug changes.
