jordansissel / xdotool

fake keyboard/mouse input, window management, and more
Other
3.26k stars 319 forks source link

xdotool key Toggling Number Lock When Emulating Keypad Buttons #405

Open VD-15 opened 2 years ago

VD-15 commented 2 years ago

Summary

When emulating keypad inputs via xdotool key, the state of the number lock is toggled after the key press:

$ xdotool key KP_1
1$ xset q | grep "Num Lock"
    00: Caps Lock:   off    01: Num Lock:    on     02: Scroll Lock: off
$ xdotool key KP_1
1$ xset q | grep "Num Lock"
    00: Caps Lock:   off    01: Num Lock:    off    02: Scroll Lock: off

Observations

Running with --clearmodifiers does not appear to have an effect on whether number lock toggles. Toggle only occurs when emulating KP_0 through KP_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

OS Arch Linux
xdotool version 3.20211022.1
xorg-server version 21.1.4-1
Kernel version 5.19.12
jordansissel commented 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

jordansissel commented 2 years ago

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.

jordansissel commented 2 years ago

I'm pretty sure this is a bug in xdotool where it incorrectly uses numlock when using XTEST to send keystrokes.