Releasing all keys after disabling the keyboard in X11/Linux using xinput?

Question

On Linux when using X11/Xorg, when you use xinput to disable they keyboard (e.g. xinput set-prop $ID "Device Enabled" 0) the 'key-up' event is not send (because you've disabled the keyboard). This is noticable if you enter that command on the command line, it'll act like you're holding 'enter' down. This is because the command (which disables the keyboard) runs before you lift your finger off the enter key.

This is discussed in this bug ( https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/724280 ) and this blog post ( http://blog.yjl.im/2010/12/using-xinput-to-disable-keyboard-mouse.html ).

I am writing a programme that needs to disable the keyboard, and want to avoid this problem. Is there any way/command to "release all the keys that are currently pressed" (which could be run just after the "disable the keyboard" command)? Or is there a command/way to "get a list of all the current keys that are pressed" and a way to manually/programmatically send the "key released" event? (This way I could disable the keyboard, see what keys are pressed, and then 'release' those keys).

Is this possible?

Answer 1

"I am writing a programme that needs to disable they keyboard, and want to avoid this problem"

What's wrong with grabbing the keyboard focus and discarding all input?

xinput is a pretty blunt instrument and you're hitting a bug that's more than two years old which means it isn't likely to get fixed. Indeed, the bug is probably far older than that, and could be considered "expected behavior" by someone making use of it.

Answer 2

What you experience is a peculiarity of how keyboard events are processed by terminal emulators and the shell reacts. When you press enter the shell will execute the command given to it, and your command xinput ... will finish before enter is even depressed. Since the keyboard gets disabled no key release event will be even entering the event processing.

It's not a bug, it's a feature.

How to work around it: Either wait for all keys to be depressed before actually executing the detach, or just add a sleep before the xinput command (those are both race conditions, so it's not 100% reliable).

I.e. putting this on the shell command line

sleep 1 ; xinput set-prop $ID "Device Enabled" 0

Will first sleep for a second before actually doing the xinput disable. If you don't keep the enter key pressed you should come out in the desired state.

Answer 3

just simulate any key click after xinput set-prop $ID "Device Enabled" 0, no sleep time before command needed

xinput set-prop $ID "Device Enabled" 0 ; xdotool key z