1

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?

Dan D.
  • 73,243
  • 15
  • 104
  • 123
Amandasaurus
  • 58,203
  • 71
  • 188
  • 248

3 Answers3

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.

msw
  • 42,753
  • 9
  • 87
  • 112
  • That is an interesting approach that might work. How would I do that? I asked originally "how to lock the keyboard" here http://stackoverflow.com/questions/10740067/how-do-i-lock-the-keyboard-to-prevent-any-more-keypresses-being-sent-on-x11-li NB: I don't know much about X11 programming, so something simple please. :) – Amandasaurus May 26 '12 at 10:24
  • This is not a bug. If you enter the command on the shell, hitting the enter key will execute it and the command will finish before the key is even depressed. Just put a sleep in front of it. – datenwolf May 26 '12 at 20:45
1

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.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • I know it's not a bug per se, but I want to work around it :) "wait for all keys to be depressed before actually executing the detach" How would I do that? – Amandasaurus May 27 '12 at 20:27
  • 1
    @Rory: The XInput protocol allows to query the current state of each input devices. The *xinput* tool exposes this protocol function on the command line, via the `query-state` action: `xinput query-state $ID`, you need to process the output of this, or better yet, use the protocol directly without such a helper tool. – datenwolf May 27 '12 at 23:19
  • ``query-state`` solves one part of the question ("what keys are pressed?"). How can I release those keys? If you add the ``query-state`` & answer to "how to release the keys?" as a separate answer, I'll accept the answer and you'll get karma. – Amandasaurus May 28 '12 at 09:51
  • @Rory: You don't release them. You wait, until they get released. But seriously: You should just grab the keyboard, and not disable input events. – datenwolf May 28 '12 at 10:29
0

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
s1w_
  • 133
  • 8