04 10 | 2013

Using a Plantronics USB headset under X.Org/Linux

Written by Tanguy

Classified in : Homepage, Debian, Miscellaneous, To remember

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 /etc/X11/xorg.conf.d/plantronics.conf and restart X.Org:

 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.

5 comments

friday 04 october 2013 à 17:11 Alex said : #1

That is stupefyingly stupid. How could anybody possibly think that was a good idea?

For the record, I don't think all Plantronics USB headsets are like that; I seem to recall mine works just fine without any configuration (although I haven't had any need to fiddle with its buttons recently).

friday 04 october 2013 à 17:36 Tanguy said : #2

@Alex : I do not know, that may come from a kernel bug, or it may be a quirk from Plantronics to implement some Windows stuff, like displaying something when the user presses the mute/unmute microphone button.

For instance, since the muting is implemented directly in the headset hardware, that button must not send a keyboard event that would make the OS do an unwanted additional muting. But if an event is required to trigger something that would prompt the headset for the microphone status and display an on-screen indicator, they may have chosen the mouse button 1, as something unused and that would be supposed to do nothing when received from a keyboard…

friday 03 january 2014 à 10:16 Bob Josward said : #3

Thanks for sharing the article and the quick fix. My experience with using Plantronics headsets have always been favorable and I order them online at http://www.simplyheadsets.com.au/brands/plantronics.html.

saturday 12 april 2014 à 01:29 FredFrin said : #4

With my Plantronics savi w440 I have a similar issue - except it's a mouse event:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech USB Receiver id=11 [slave pointer (2)]
⎜ ↳ Logitech USB Receiver id=12 [slave pointer (2)]
⎜ ↳ Plantronics Plantronics D100 id=8 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ USB Keyboard id=9 [slave keyboard (3)]
↳ USB Keyboard id=10 [slave keyboard (3)]


so how do I map just that mouse event to '0' ?

The ButtonMapping above does not work - while
Option "Ignore" "true" does work.

thursday 01 may 2014 à 12:35 gringo said : #5

thx a lot!
volume buttons wouldn't work anyways,
so the side effect doesn't really matter to me.

Write a comment

What is the fourth letter of the word jejec? :