I just received an USB headset from Plantronics. Since it has a keypad on it, with buttons to mute the microphone and to adjust the volume, it appears as both a sound card and a keyboard. Problem: that keyboard sends a mouse ButtonPress 1 (yes, a mouse button event, do not ask me how that is materially and logically possible) when the microphone is muted, and only sends the corresponding ButtonRelease 1 when it is unmuted. As a result, the pointer behaves as if the mouse button was pressed continuously, rendering the desktop quite unusable.
This situation has been the object of many discussions and bug reports. All of them always suggest the same solution: making X.Org ignore the “keyboard” associated to the headset, with an important side effect: volume adjustment will no longer be possible using the headset buttons. Microphone muting will still be available though, since it is implemented directly in the headset.
There is a better solution however: remap the mouse button 1 of that “keyboard” (yes, the idea that a keyboard has mouse buttons is quite funny) to disable it. To do that temporarily:
$ # Get the identifier of the Plantronics keyboard $ xinput --list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Logitech USB Optical Mouse id=10 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Logitech USB Keyboard id=8 [slave keyboard (3)] ↳ Plantronics .Audio 400 DSP id=11 [slave keyboard (3)] $ # Remap its mouse button 1 to 0 (disable) $ xinput --set-button-map 11 0
And to do it permanently, create a file
Section "InputClass" Identifier "Plantronics" MatchVendor "Plantronics" Option "ButtonMapping" "0" EndSection
This way, the mouse button 1 events from the headset “keyboard” are ignored, while all the other events it generates, that is KeyPress/KeyRelease XF86AudioLowerVolume and XF86AudioRaiseVolume, are not.