https://bugs.kde.org/show_bug.cgi?id=526570
Bug ID: 526570
Summary: While an input method (plasma-keyboard, Fedora's
default) holds a keyboard grab, the lock screen gets a
Shift+key press that arrives in quick succession
without Shift. This happens with input injected
through libei/EIS, for example KDE Connect remote inpu
Classification: Plasma
Product: kwin
Version First 6.7.4
Reported In:
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: input
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
**STEPS TO REPRODUCE**
1. Plasma 6.7.4 Wayland session, with plasma-keyboard as the input method. This
is the Fedora 44 default, set by kde-settings (`[Wayland]
InputMethod=…org.kde.plasma.keyboard.desktop`).
2. Use a libei/EIS client that sends Shift press, key press, key release and
Shift release back to back. I used KDE Connect remote input, with a local patch
so it sends Shift for shifted characters; its EIS path otherwise drops Shift
itself.
3. Lock the screen and type `!@A1` from the client into the password field.
Reveal the field.
**OBSERVED RESULT**
The lock screen shows `12a1`: Shift is lost on every character. The same input
into KWrite (native Wayland) or Steam (XWayland) gives `!@A1`.
**EXPECTED RESULT**
`!@A1` on the lock screen, as in normal windows.
**ADDITIONAL INFORMATION**
- Turning the input method off fixes it. With `kwinrc [Wayland] InputMethod=`
(empty) and `VirtualKeyboardEnabled=false`, plasma-keyboard exits and the lock
screen gets `!@A1` from the same client.
- The client's own trace was the same in the lock-screen and KWrite runs:
identical `EI_EVENT_KEYBOARD_MODIFIERS` events from KWin, so KWin's xkb state
does see Shift.
- Physical keyboard typing on the lock screen is not affected in practice,
presumably because a human holds Shift for tens of milliseconds before the key.
**Suspected mechanism (from reading 6.7.4 source; not instrumented):**
- `KeyboardInputRedirection::processKey` (`src/keyboard_input.cpp`) skips
`m_xkb->forwardModifiers()` to the seat when `inputmethod->keyboardGrab()` is
set. Modifiers then reach the focused client only after a round trip through
the input-method process: `InputMethod::modifiers` → `xkb->forwardModifiers()`.
- On the lock screen, `LockScreenFilter::keyboardKey` (`src/input.cpp`) is
installed before `InputMethodEventFilter`. It calls `seat->notifyKeyboardKey`
directly and returns true, so the key itself reaches the greeter at once and
never goes through the input method.
- Net effect: on the lock screen, keys are delivered immediately and modifiers
late, so a burst of Shift and key loses Shift. In normal windows keys and
modifiers both go through the input method, so their order holds.
Possible fixes: have `LockScreenFilter` also forward modifiers to the seat
directly; or don't skip direct modifier forwarding while the screen is locked;
or route lock-screen keys through the input-method path consistently.
**Versions:** kwin 6.7.4-2.fc44 · plasma-keyboard 6.7.4-1.fc44 · kscreenlocker
6.7.4 · libei/libeis 1.6.0 · kdeconnectd 26.08.1 (locally patched, see below) ·
Qt 6.11
**Related:** KDE Connect's own Wayland remote input drops Shift and AltGr
levels in `plugins/mousepad/waylandremoteinput.cpp` (`keycodeFromKeysym` throws
away the level). That is a separate KDE Connect bug and fix; the KWin issue
above only shows once that one is fixed.
--
You are receiving this mail because:
You are watching all bug changes.
