Open VD-15 opened 2 years ago
Whoa, that's odd!
I tested on two X11 systems: Xephyr and XWayland. On Xephyr (Xorg's Xephyr server), I am able to reproduce this. On XWayland, this behavior doesn't happen.
Here's the test case on Xephyr:
% export DISPLAY=:1; seq 10 | xargs -n1 sh -c 'xdotool key KP_1; sleep 0.5; xset q | grep "Num Lock"'
00: Caps Lock: off 01: Num Lock: on 02: Scroll Lock: off
00: Caps Lock: off 01: Num Lock: off 02: Scroll Lock: off
00: Caps Lock: off 01: Num Lock: on 02: Scroll Lock: off
00: Caps Lock: off 01: Num Lock: off 02: Scroll Lock: off
00: Caps Lock: off 01: Num Lock: on 02: Scroll Lock: off
00: Caps Lock: off 01: Num Lock: off 02: Scroll Lock: off
00: Caps Lock: off 01: Num Lock: on 02: Scroll Lock: off
00: Caps Lock: off 01: Num Lock: off 02: Scroll Lock: off
00: Caps Lock: off 01: Num Lock: on 02: Scroll Lock: off
00: Caps Lock: off 01: Num Lock: off 02: Scroll Lock: off
Very strange.
I wonder if xdotool is determining that in order to send KP_1 that it requires the numlock modifier and is forgetting to reset it aftewards
Using xev to see the keystrokes received by a window, I see:
KeyPress event, serial 31, synthetic NO, window 0x200001,
root 0x2c8, subw 0x0, time 56046835, (35,110), root:(37,112),
state 0x0, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 32, synthetic NO, window 0x200001,
root 0x2c8, subw 0x0, time 56046835, (35,110), root:(37,112),
state 0x10, keycode 87 (keysym 0xffb1, KP_1), same_screen YES,
XLookupString gives 1 bytes: (31) "1"
XmbLookupString gives 1 bytes: (31) "1"
XFilterEvent returns: False
KeyRelease event, serial 32, synthetic NO, window 0x200001,
root 0x2c8, subw 0x0, time 56046842, (35,110), root:(37,112),
state 0x10, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 32, synthetic NO, window 0x200001,
root 0x2c8, subw 0x0, time 56046842, (35,110), root:(37,112),
state 0x10, keycode 87 (keysym 0xffb1, KP_1), same_screen YES,
XLookupString gives 1 bytes: (31) "1"
XFilterEvent returns: False
It's like xdotool treats num lock like a held-key like shift, alt, or control, instead of a toggled state like caps lock.
I'm pretty sure this is a bug in xdotool where it incorrectly uses numlock when using XTEST to send keystrokes.
Summary
When emulating keypad inputs via
xdotool key
, the state of the number lock is toggled after the key press:Observations
Running with
--clearmodifiers
does not appear to have an effect on whether number lock toggles. Toggle only occurs when emulatingKP_0
throughKP_9
.KP_Add
,KP_End
etc. as well as non-keypad keys appear to be unaffected.When running
xdotool key --delay 10000 KP_0
, the following timing observations were made:If the number lock is on when the command is run, number lock toggles off about half way through the delay (about five seconds) If the number lock is off when the command is run, number lock toggles on immediately and stays on In both cases the button only repeats for the first five seconds of the command
System info