https://bugs.kde.org/show_bug.cgi?id=524098
Sebastian Sauer <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #8 from Sebastian Sauer <[email protected]> --- After some more investigation: With the patch from https://invent.kde.org/plasma/kwin/-/merge_requests/9913 we behave now 1:1 like Gnome Mutter. The same issue is present there. The accidental CapsLock toggle happens when typing CapsLock then CapsLock+T within 600ms (the keyboard repeat delay) — the second CapsLock is detected as a double-press and passes through to XKB, toggling CapsLock ON. The "permanently stuck" feeling is because single CapsLock presses are consumed (by design), so the user can't toggle CapsLock back unless they double-press within 600ms. The LED desync is due to firmware CapsLock LED on the user's keyboard — LED toggles on each physical press regardless of whether the OS consumed the event and in this case we don't what is why Capslock-LED and Capslock-state are out of sync. When that happens then what you can do (rather then rebooting or using "kwin --replace") is: Press two times Capslock fast again so its detected as a double-press. And then voila, its all like it was before. The issue is NOT in KWin/Mutter or Orca itself but in at-spi2-core's registry daemon. What Orca does on CapsLock double-press (click_count==2): - src/orca/orca_modifier_manager.py, line 193-219: _toggle_modifier_lock() - Calls Atspi.generate_keyboard_event(modifier, "", Atspi.KeySynthType.LOCKMODIFIERS) (line 208) - This D-Bus call goes to org.a11y.atspi.Registry service What the AT-SPI registry daemon does: - registryd/deviceeventcontroller.c, line 1514-1518: dispatches LOCKMODIFIERS/UNLOCKMODIFIERS to spi_dec_plat_lock_modifiers()/spi_dec_plat_unlock_modifiers() - Lines 185-205: these are platform dispatchers — they call klass->plat.lock_modifiers if the function pointer is set, otherwise return FALSE (no-op) X11 implementation exists: - registryd/deviceeventcontroller-x11.c, line 1356-1357: sets klass->plat.lock_modifiers = spi_dec_x11_lock_modifiers and klass->plat.unlock_modifiers = spi_dec_x11_unlock_modifiers - Line 1047-1066: spi_dec_x11_lock_modifiers() calls XkbLockModifiers() — works No Wayland implementation exists: - registryd/meson.build, line 19-28: deviceeventcontroller-x11.c is only compiled when x11_dep.found() - There is NO deviceeventcontroller-wayland.c or any other Wayland backend - On a pure Wayland build (without X11 deps), plat.lock_modifiers is NULL → spi_dec_plat_lock_modifiers returns FALSE → complete no-op The LOCKMODIFIERS call is actually redundant in the new Wayland model because: - Old X11 model: CapsLock was grabbed via XGrabKey → key events went to Orca, NOT to X11's XKB → XKB never toggled CapsLock → Orca used LOCKMODIFIERS/XkbLockModifiers as the sole mechanism to toggle CapsLock state - New Wayland model (KeyboardMonitor in Mutter/KWin): the compositor's first-click detection consumes the first press but passes the double-press through to XKB → XKB itself toggles CapsLock from the key event → LOCKMODIFIERS would be redundant even if it worked So the CapsLock toggle actually works on Wayland without LOCKMODIFIERS — it happens via the compositor's XKB. The _toggle_modifier_lock call in Orca is dead code on Wayland. The real bug is that Bug 524098's stuck CapsLock is caused by the accidental double-press during the CapsLock → CapsLock+T pattern (272ms gap triggers double-press within 600ms repeat delay). This is a compositor-level issue (same in Mutter) in the is_a11y_modifier_first_click algorithm, not an Orca issue. The user's single CapsLock presses to "fix" it are consumed, and their keyboard's firmware LED toggle creates the illusion of CapsLock responding. For any Orca/at-spi2-core report, the actionable items would be: 1. at-spi2-core: LOCKMODIFIERS/UNLOCKMODIFIERS has no Wayland implementation (file against at-spi2-core, component: registryd) 2. Orca: _toggle_modifier_lock is dead code on Wayland — the toggle relies on the compositor's XKB instead (informational, may need cleanup) Did it worked different for you on X11 or what did I miss? -- You are receiving this mail because: You are watching all bug changes.
