Keys become stuck when disabling keyboard

[dualityim]

Binary package hint: xserver-xorg-input-evdev

When using xinput to disable the active keyboard, the system will continue to think a key on the keyboard is held down after the keyboard is successfully disabled.

Steps to duplicate the problem:
1. Run 'xinput list' to find the id of the active keyboard.
2. Type 'xinput set-prop [id] "Device Enabled" 0' into a terminal, where [id] is the keyboard id from step 1, and hit enter.

Expected behavior: keyboard becomes disabled.
Actual behavior: keyboard becomes disabled but the Enter key is stuck. The terminal prompt loops infinitely due to the Enter key being held down.

This only happens when a keyboard key press is used to trigger the command that disables the keyboard. By contrast, if one double clicks on a script in Nautilus that contains the command above, the keyboard becomes disabled and no keys are stuck.

The keys that can become stuck is not limited to the Enter key. I discovered this while running Ubuntu in a VMware Workstation VM in Unity mode. In Unity mode, the guest OS' windows are integrated into the host OS as separate windows. In this mode, it seems whenever a guest window is closed and focus goes back to a host window, vmware-tools disables the guest virtual keyboard so that key presses don't continue to be sent to the guest. Because of this, when a keyboard shortcut is used to close a guest window, the above bug is triggered, and the next time a guest window is opened, the stuck key is entered repeatedly. For example, if Ctrl+D is used to close gnome-terminal in the guest and focus goes back to a host window, then the next time gnome-terminal is opened in the guest, the "d" key is entered into the terminal repeatedly.

The problem only seems to happen if the key press is sent at the exact same time the keyboard is disabled. Someone else who has encountered the issue suggests that running, for example, 'sleep 1 && xinput --set-prop [id] "Device Enabled" 0' allows one to work around the problem. Unfortunately I'm uncertain how to inject such a workaround into vmware-tools.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: xserver-xorg-input-evdev 1:2.3.2-6ubuntu3.1
ProcVersionSignature: Ubuntu 2.6.35-25.44-generic 2.6.35.10
Uname: Linux 2.6.35-25-generic x86_64
Architecture: amd64
Date: Thu Feb 24 07:08:22 2011
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
Lsusb:
 Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
 Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: VMware, Inc. VMware Virtual Platform
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-25-generic root=UUID=2f26c460-d2bc-405a-8014-aac6b57dd71e ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: xserver-xorg-input-evdev
dmi.bios.date: 12/31/2009
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: 6.00
dmi.board.name: 440BX Desktop Reference Platform
dmi.board.vendor: Intel Corporation
dmi.board.version: None
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 1
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd12/31/2009:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:
dmi.product.name: VMware Virtual Platform
dmi.product.version: None
dmi.sys.vendor: VMware, Inc.
glxinfo: Error: [Errno 2] No such file or directory
system:
 distro: Ubuntu
 codename: maverick
 architecture: x86_64
 kernel: 2.6.35-25-generic

[bugbot (bugbot)]

Hey dualityim,

Hi, have you had a chance to test if this bug is still present in natty?

If it does (and if you're the original reporter), please boot into natty
and run the command:

  apport-collect <bug-number>

which will update the bug with fresh logs and tag the bug as affecting
natty. (It is best to run this right after reproducing the problem.)

[bugbot (bugbot)]

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

[Rory McCann (rorymcc)]

I have noticed this behaviour aswell, and am looking for a solution. This blog post also records this problem, and hypothesises: "I am guessing when you hit the enter and the command is executed, meaning the keyboard is disabled, but the keyup event is not yet sent, so X still thinks the enter key is pressed down." http://blog.yjl.im/2010/12/using-xinput-to-disable-keyboard-mouse.html