Skip to content

Be wary of “optimised for …” devices

December 17, 2012


This story began with linphone having a weird behavior: every now and then, the mouse pointer would become stuck: the pointer moves, but clikcking on it always activate the same widget. Since this always happened in the middle of phone conference done for work, this was infuriating.

Long story short, I finally found that my plantronics USB headset was responsible for this weird behavior. This headset is connected to the USB bus and is seen by the computer as a USB sound card. The bug was triggered by pressing the “mute” button provided by the headset.

Suspicious of this usb device, I used lsusb to find the features provided by the heaset:

$ lsusb -v -s 1:3 2>&1 |grep InterfaceClass
bInterfaceClass 1 Audio
bInterfaceClass 1 Audio
bInterfaceClass 1 Audio
bInterfaceClass 1 Audio
bInterfaceClass 1 Audio
bInterfaceClass 3 Human Interface Device

Audio devices were expected, but why a HID device ? This device is a headset, not a keyboard or a mouse… Testing further, I also saw some number poping up on my screen whenever I pressed the the mute button. The only way to get the mouse back was to unplug the headset.

A quick google search gave a solution to setup X11 to ignore the headset. Problem solved.

But this did not answer the question regarding the HID device. Then I got a hint in the form of a sticker glued on the headset USB plug: “Optimized for Microsoft Lync”. This page gave the answer: an “optimised for Lync” device provides “mute/unmute across PC and device”.

I can only guess that when the mute button is pressed, some data is sent from the HID interface. Unfortunately, the window manager does not like to be on the receiving end of this data.

The moral of this story is: “optimized for something” actually means “not standard“.

ok. There’s a bug somewhere. The comments of this blog have convinced me that I went too far with the moral of this story. It’s now overstriked instead of plainly remvoed so the comments still make sense.

Thanks everybody for the constructive comments.

All the best


From → computer

  1. It actually is pretty standard for that kind of devices to come with a mute/unmute and a HID interface as well, so “optimized for Lync” does not mean “not standard” at all, this time around at least.

    If you check _any_ laptop’s webcam provide HID devices and this has been the same for a long time…

    • Using the HID device is not a problem (even if it was a surprise for me).

      The problem comes (partly) from the unknown data sent over HID.
      If this data exchange is standard, the format of this data should be described somewhere available for public usage.

  2. Plainly the HID is being recognised if the mute button works (and, by extension, the device is using the USB standard properly to advertise its USB classes). I’m somewhat confused as to why the hangups are therefore being attributed to a sticker on the side of the plug (and, by implication, to lazy or corrupt vendors) rather than bugs in the WM or in X (which has always been known for trouble with multiple input devices).


    • Hmm, the mute button is located on the usb device. It still works even if X11 ignores the HID device. I think the sound is cut off on the device itself.

      There are problably bugs on both side: a bug (or unfortunate feature) that sends weird data on the device and a bug on Xorg side for not handling correctly bad data.

      The only reason for the device to send data on HID is to highlight a mute icon on the user application (and probably be able to un-mute the sound on the device side from the user’s application). I’d like to be proven wrong, but I don’t think this data exchange is standard. It’s probably Lync specific, hence the “optimized for Lync” sticker.

      • > I’d like to be proven wrong, but I don’t think this data exchange is standard

        It’s “standard” in the sense that it’s valid for USB HIDs to announce themselves as custom devices. The USB standard provides ways for operating systems to parse the commands issued by these devices, and for the device to report exactly how it will be issuing commands. It is infeasible for the standard to specify precisely how an OS is supposed to respond to every possible command in advance. Nonetheless, MS’s public documentation of the Lync SDK should be sufficient to enable developers of other applications to handle said signal, and authors of other applications (including free software ones) are free to propose a common interface for this if they wish to try to standardise such things in future. It would be impractical to do it the other way around.


  3. Ben Hutchings permalink

    This sounds like a bug in linphone – it is ‘grabbing’ the mute keystroke incorrectly.

    • Hmm, ‘grabbing’ problem also occurs when linphone is not running.

  4. Ben Hutchings permalink

    It sounds like the headset may be sending a key-down for ‘mute’ but not following that with a key-up. linphone has registered a ‘grab’ to process the mute key even if its window is not focused. My guess is that the grab is not released until the key-up, but that never comes. You should be able to monitor HID events and confirm this.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: