Bug#1125343: xserver-xorg-core: X11/XKB state desync after xdotool (XTEST); NumPad acts as navigation keys in Featherpad while NumLock LED stays on
Package: xserver-xorg-core Version: 2:21.1.7-3+deb12u11 Severity: normal
Tags: x11 xkb xtest xinput2 Hello, On Debian 12 (Bookworm) with X11/Xfce
I can reproducibly trigger a keyboard state issue after injecting
synthetic key events via the XTEST extension (using xdotool key ...).
After the trigger, the numeric keypad behaves like navigation keys in
Featherpad (Qt app), even though the NumLock LED remains on. The issue
persists until I press the physical NumLock key twice, which restores
normal NumPad behavior. The trigger happens in a workflow where Firefox
is focused and the mouse pointer is over a word in a web page.
Environment ---------- - Debian 12 (Bookworm), Xfce, X11 (not Wayland) -
xserver-xorg-core 2:21.1.7-3+deb12u11 - xdotool 1:3.20160805.1-5 - xfwm4
4.20.0-1~mx23+1 (MX repo) - featherpad 1.4.1-0.1~mx23+1 (MX repo) - XKB
layout: rules: evdev model: pc105 layout: ch variant: legacy,, options:
terminate:ctrl_alt_bksp,grp_led:scroll - NumLock LED remains ON while
the issue is present. Reproducibility (as tested)
--------------------------- 1. Ensure NumLock LED is ON. 2. Open
Featherpad and confirm NumPad keys insert digits normally. 3. Focus
Firefox (any web page; mouse position is not critical for the minimal
trigger). 4. Trigger a script via an Xfce keyboard shortcut (hotkey)
that sends synthetic key events using xdotool (XTEST). Tested triggers:
Trigger 1 (minimal): #!/bin/sh xdotool key --delay 30 shift+Left Trigger
2 (also triggers): #!/bin/sh xdotool key --delay 30 ctrl+shift+Left
Trigger 3 (also triggers): #!/bin/sh xdotool key --delay 30
ctrl+shift+Right Trigger 4 (also triggers): two separate Ctrl+C
#!/bin/sh xdotool key --delay 30 ctrl+c sleep 0.2 xdotool key --delay 30
ctrl+c Trigger 5 (also triggers): double click + single Ctrl+C #!/bin/sh
eval "$(xdotool getmouselocation --shell)" xdotool windowactivate --sync
"$WINDOW" xdotool click --repeat 2 --delay 80 1 sleep 0.05 xdotool key
--delay 30 ctrl+c Counterexample tested: - A single xdotool key ctrl+c
(only once) did NOT trigger the issue. 5. Switch to Featherpad and press
NumPad-4 (LED still on). Actual result ------------ - In Featherpad,
NumPad digits behave like navigation/cursor movement keys (e.g. NumPad-4
behaves like "Left"), while the NumLock LED remains on. - The issue
persists until manually fixed. Expected result -------------- Synthetic
XTEST key events must not desynchronize/corrupt the effective keyboard
state. NumPad digits should remain digits when NumLock is on. Workaround
---------- - Press physical NumLock twice -> normal behavior returns.
Additional observation --------------------- - When testing with xev,
NumPad-4 may still show as KP_4 even while Featherpad behaves
incorrectly, suggesting a possible mismatch between core X events and
XInput2/Toolkit state (Qt uses XI2). Package versions ---------------
xdotool: 1:3.20160805.1-5 xserver-xorg-core: 2:21.1.7-3+deb12u11 xfwm4:
4.20.0-1~mx23+1 featherpad: 1.4.1-0.1~mx23+1 Thanks.Package:
xserver-xorg-core
Version: 2:21.1.7-3+deb12u11
Severity: normal
Tags: x11 xkb xtest xinput2
Hello,
On MX-Linux 23 (Debian 12) with X11/Xfce I can reproducibly trigger a
keyboard state issue after injecting synthetic key events via the XTEST
extension (using xdotool key ...). After the trigger, the numeric keypad
behaves like navigation keys in Featherpad (Qt app), even though the
NumLock LED remains on. The issue persists until I press the physical
NumLock key twice, which restores normal NumPad behavior.
The trigger happens in a workflow where Firefox is focused and the mouse
pointer is over a word in a web page.
Environment
----------
- MX-Linux 23 (Debian 12), Xfce, X11 (not Wayland)
- xserver-xorg-core 2:21.1.7-3+deb12u11
- xdotool 1:3.20160805.1-5
- xfwm4 4.20.0-1~mx23+1 (MX repo)
- featherpad 1.4.1-0.1~mx23+1 (MX repo)
- XKB layout:
rules: evdev
model: pc105
layout: ch
variant: legacy,,
options: terminate:ctrl_alt_bksp,grp_led:scroll
- NumLock LED remains ON while the issue is present.
Reproducibility (as tested)
---------------------------
1. Ensure NumLock LED is ON.
2. Open Featherpad and confirm NumPad keys insert digits normally.
3. Focus Firefox (any web page; mouse position is over a word).
4. Trigger a script via an Xfce keyboard shortcut (hotkey) that sends
synthetic key events using xdotool (XTEST). Tested triggers:
Trigger 1 (minimal):
#!/bin/sh
xdotool key --delay 30 shift+Left
Trigger 2 (also triggers):
#!/bin/sh
xdotool key --delay 30 ctrl+shift+Left
Trigger 3 (also triggers):
#!/bin/sh
xdotool key --delay 30 ctrl+shift+Right
Trigger 4 (also triggers): double click + single Ctrl+C
#!/bin/sh
eval "$(xdotool getmouselocation --shell)"
xdotool windowactivate --sync "$WINDOW"
xdotool click --repeat 2 --delay 80 1
sleep 0.05
xdotool key --delay 30 ctrl+c
Counterexample tested:
- A single xdotool key ctrl+c (only once) did NOT trigger the issue.
5. Switch to Featherpad and press NumPad-4 (LED still on).
Actual result
------------
- In Featherpad, NumPad digits behave like navigation/cursor movement
keys (e.g. NumPad-4 behaves like "Left"), while the NumLock LED remains on.
- The issue persists until manually fixed.
Expected result
--------------
Synthetic XTEST key events must not desynchronize/corrupt the effective
keyboard state. NumPad digits should remain digits when NumLock is on.
Workaround
----------
- Press physical NumLock twice -> normal behavior returns.
Additional observation
---------------------
- When testing with xev, NumPad-4 may still show as KP_4 even while
Featherpad behaves incorrectly, suggesting a possible mismatch between
core X events and XInput2/Toolkit state (Qt uses XI2).
Package versions
---------------
xdotool: 1:3.20160805.1-5
xserver-xorg-core: 2:21.1.7-3+deb12u11
xfwm4: 4.20.0-1~mx23+1
featherpad: 1.4.1-0.1~mx23+1
Thanks.
Reply to: