key "stuck down" after sendevent

[Peter Hutterer]

On Sun, Apr 10, 2022 at 04:25:51PM +0100, Julian Bradfield wrote:
> I have a puzzling (to me) observation.
> 
> In the course of marking lots of exercise, I'm doing, repeatedly,
> 
> mupdf -geometry +0+0 *.pdf &  emacs q3.txt ; sleep 0.1; xdotool search
> .pdf key q 
> 
> The purpose of the xdotool is so that mupdf receives a quit command
> and saves its history file, rather than being killed. (The sleep 0.1
> (using a local sleep that accepts floating point) is to address another
> issue.)
> 
> Almost invariably, xdotool gets a BadWindowError when it tries to send
> the KeyUp event, presumably because by then mupdf has already quit and
> accepts no more events.
> 
> Sometimes, something weird happens: the window that then has focus
> (usually an xterm or emacs) gets auto-repeating q's until I press
> and release another key.
> 
> I don't see how sending a synthetic keydown to a client can affect the
> state of the keyboard for other clients.

xdotool (from a quick check of the source) either sends key codes for the key
through the X Test device (if the target window is in focus) or uses
XSendEvent() to send to some arbitrary other window not in focus [1].

If you end up with XTest for the key down and then for some reason xdotool
fails to send the key up event, or xdotool sends the up event through
XSendEvents instead, you end up with a key down on the xtest device.
That device is like any physical device and it'll keep repeating until
something releases that key again.

Cheers,
  Peter

[1] XSendEvent has the asterisk that clients may ignore that event altogether
since it has a bit set that marks it as artificial event.