Mute button on USB headset steals and holds on to mouse focus

Bug #1006156 reported by François Marier
88
This bug affects 17 people
Affects Status Importance Assigned to Milestone
xorg (Ubuntu)
Invalid
Low
Unassigned

Bug Description

When I press the mute button on my USB headset (Plantronics .Audio 626 DSP), it steals the "mouse focus" and holds onto it until I press the mute button again.

Expected:

- microphone is muted
- nothing else happens

Actual:

- microphone is muted
- mouse can still move but is unresponsive to clicks
- pressing the keyboard doesn't do anything (except for Ctrl+Alt+F1 which does work and switch to virtual console)

I'm not sure this is filed against the right package, please reassign if it's not. Also, I'm happy to provide more info, but I wasn't sure what I could provide (even after reading https://wiki.ubuntu.com/Hotkeys/Troubleshooting/).

This is on a fully up-to-date Precise 12.04 system.

WORKAROUND: 1. Put this in /etc/udev/rules.d/70-plantronics.rules:
ACTION!="add|change", GOTO="xorg_plantronics_end"
KERNEL!="event*", GOTO="xorg_plantronics_end"
ENV{ID_VENDOR_ID}=="047f", ENV{ID_MODEL_ID}=="c006", ENV{ID_INPUT_KEY}="1"
ENV{ID_VENDOR_ID}=="047f", ENV{ID_MODEL_ID}=="c006", RUN+="keymap $name 0xc00e9 volumeup 0xc00ea volumedown 0xb002f micmute"
LABEL="xorg_plantronics_end"

2. Reload udev:
sudo udevadm control --reload

3. Unplug the headset and plug it back in

Tags: precise
Revision history for this message
François Marier (fmarier) wrote :

I tried another headset (Logitech ClearChat Comfort USB Digital Headset) and the mute button on that one works as expected. It doesn't steal the mouse focus like the Plantronics one.

Revision history for this message
Karl Tomlinson (bugs+launchpad) wrote :

[487553.692] (II) config/udev: Adding input device Plantronics Plantronics .Audio 646 DSP (/dev/inpu
t/event17)
[487553.692] (**) Plantronics Plantronics .Audio 646 DSP: Applying InputClass "evdev keyboard catcha
ll"
[487553.692] (**) Plantronics Plantronics .Audio 646 DSP: Applying InputClass "keyboard-all"
[487553.692] (II) Using input driver 'evdev' for 'Plantronics Plantronics .Audio 646 DSP'
[487553.692] (**) Plantronics Plantronics .Audio 646 DSP: always reports core events
[487553.692] (**) evdev: Plantronics Plantronics .Audio 646 DSP: Device: "/dev/input/event17"
[487553.693] (--) evdev: Plantronics Plantronics .Audio 646 DSP: Vendor 0x47f Product 0xc001
[487553.693] (--) evdev: Plantronics Plantronics .Audio 646 DSP: Found 3 mouse buttons
[487553.693] (--) evdev: Plantronics Plantronics .Audio 646 DSP: Found keys
[487553.693] (II) evdev: Plantronics Plantronics .Audio 646 DSP: Configuring as mouse
[487553.693] (II) evdev: Plantronics Plantronics .Audio 646 DSP: Configuring as keyboard
[487553.693] (**) evdev: Plantronics Plantronics .Audio 646 DSP: YAxisMapping: buttons 4 and 5
[487553.693] (**) evdev: Plantronics Plantronics .Audio 646 DSP: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[487553.693] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.3/input/input40/event17"

The mute button is sending a core button 1 down event.
This is also sent on uncapturing the audio input through alsa.

xinput float "Plantronics Plantronics .Audio 646 DSP" disables the effect of the buttons/keys.

I expect putting this in xorg.conf would do similarly, but haven't tested:
Section "InputClass"
     Identifier "Plantronics USB Sound Card"
     MatchProduct "Plantronics .Audio 646 DSP"
     Option "Floating" "on"
EndSection

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xserver-xorg-input-evdev (Ubuntu):
status: New → Confirmed
Revision history for this message
Alexei Kojenov (alexei-kojenov) wrote :

I have a similar issue, but in my case simply plugging in a headset "steals" the mouse so I'm unable to switch between windows using mouse or do anything else. Keyboard continues to work though.

The problem is described here: http://ubuntuforums.org/showthread.php?t=1975696
and a workaround is posted here: http://www.rodneybeede.com/Plantronics_Savi_7xx-M_and_Linux_mouse_or_lockup_problems.html

The device presents itself as an usb sound card, a mouse and a keyboard. To make X11 ignore the keyboard and mouse features (which are fine in windows but Xorg does not like it), I added this to xorg.conf:

Section "InputClass"
        Identifier "Plantronics"
        MatchVendor "Plantronics"
        Option "Ignore" "true"
EndSection

The workaround works great for me

Revision history for this message
In , Eric (eric-redhat-bugs) wrote :
Download full text (5.6 KiB)

I have a Plantronics savi 750-ish headset which plugs in USB and shows up as a USB audio device. However, when I lift the headset off of the cradle, my mouse and gnome starting acting 'fishy'. Some things the left mouse button works, some things they don't. alt+f2 doesn't work. windows hotkey doesn't work. cannot change between programs by clicking other windows. Sometimes I can click between tabs. sometimes I can highlight text on the focus window, but certainly no highlighting of text on other windows. etc. Just fishy. Disconnecting the headset from USB resolves the problem. Below you will find the xorg log and the dmesg log of connecting, breaking, and disconnecting the device.

CONNECTING:

[ 21307.552] (II) config/udev: Adding input device Plantronics Plantronics Savi 7xx (/dev/input/js0)
[ 21307.552] (**) Plantronics Plantronics Savi 7xx: Applying InputClass "anaconda-keyboard"
[ 21307.552] (II) No input driver specified, ignoring this device.
[ 21307.553] (II) This device may have been added with another device file.
[ 21307.554] (II) config/udev: Adding input device Plantronics Plantronics Savi 7xx (/dev/input/event16)
[ 21307.554] (**) Plantronics Plantronics Savi 7xx: Applying InputClass "evdev keyboard catchall"
[ 21307.554] (**) Plantronics Plantronics Savi 7xx: Applying InputClass "anaconda-keyboard"
[ 21307.554] (II) Using input driver 'evdev' for 'Plantronics Plantronics Savi 7xx'
[ 21307.554] (**) Plantronics Plantronics Savi 7xx: always reports core events
[ 21307.554] (**) evdev: Plantronics Plantronics Savi 7xx: Device: "/dev/input/event16"
[ 21307.554] (--) evdev: Plantronics Plantronics Savi 7xx: Vendor 0x47f Product 0xac01
[ 21307.554] (--) evdev: Plantronics Plantronics Savi 7xx: Found 20 mouse buttons
[ 21307.554] (--) evdev: Plantronics Plantronics Savi 7xx: Found absolute axes
[ 21307.555] (--) evdev: Plantronics Plantronics Savi 7xx: Found absolute multitouch axes
[ 21307.555] (--) evdev: Plantronics Plantronics Savi 7xx: Found keys
[ 21307.555] (II) evdev: Plantronics Plantronics Savi 7xx: Forcing relative x/y axes to exist.
[ 21307.555] (II) evdev: Plantronics Plantronics Savi 7xx: Configuring as mouse
[ 21307.555] (II) evdev: Plantronics Plantronics Savi 7xx: Configuring as keyboard
[ 21307.555] (**) evdev: Plantronics Plantronics Savi 7xx: YAxisMapping: buttons 4 and 5
[ 21307.555] (**) evdev: Plantronics Plantronics Savi 7xx: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[ 21307.555] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5.4/2-1.5.4:1.3/input/input21/event16"
[ 21307.555] (II) XINPUT: Adding extended input device "Plantronics Plantronics Savi 7xx" (type: KEYBOARD, id 15)
[ 21307.555] (**) Option "xkb_rules" "evdev"
[ 21307.555] (**) Option "xkb_model" "evdev"
[ 21307.556] (**) Option "xkb_layout" "us"
[ 21307.556] (**) Option "xkb_options" "grp:alt_shift_toggle"
[ 21307.556] (II) evdev: Plantronics Plantronics Savi 7xx: initialized for absolute axes.
[ 21307.557] (**) Plantronics Plantronics Savi 7xx: (accel) keeping acceleration scheme 1
[ 21307.557] (**) Plantronics Plantronics Savi 7xx: (accel) acceleration profile 0
[ 21...

Read more...

Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

whoah. this headset actually pretends to be a mouse?

connect the headset, then run evemu-device and evemu-record against the /dev/input/eventX device file while reproducing the above issue and attach it here please.

Revision history for this message
In , Eric (eric-redhat-bugs) wrote :

so I got nothing... looking in the Xorg.0.log I get:

[229542.305] (II) config/udev: Adding input device Plantronics Plantronics Savi 7xx (/dev/input/event16)

so I ran:

#evemu-record /dev/input/event16

When I reproduce it just exited... no output at all

I was simultaneously running:

# evemu-device /dev/input/event16

Which gave one line and exited:

error: could not create device: 0

Revision history for this message
In , Eric (eric-redhat-bugs) wrote :

Just managed to get this only running record without device at the same time:

# evemu-record /dev/input/event16
E: 1361898674.699471 0004 0004 -6291248
E: 1361898674.699471 0001 0112 1
E: 1361898674.699471 0004 0004 -6291326
E: 1361898674.699471 0001 0113 1
E: 1361898674.699471 0004 0004 -6291328
E: 1361898674.699471 0001 0117 1
E: 1361898674.699471 0001 0117 0
E: 1361898674.699471 0004 0004 -6291257
E: 1361898674.699471 0001 011e 1
E: 1361898674.699471 0004 0004 -6291258
E: 1361898674.699471 0001 011f 1
E: 1361898674.699471 0000 0000 0
E: 1361898678.261384 0004 0004 -6291248
E: 1361898678.261384 0001 0112 0
E: 1361898678.261384 0004 0004 -6291328
E: 1361898678.261384 0001 0117 1
E: 1361898678.261384 0001 0117 0
E: 1361898678.261384 0000 0000 0
E: 1361898678.524143 0001 0113 0
E: 1361898678.524146 0001 011e 0
E: 1361898678.524147 0001 011f 0
E: 1361898678.524149 0000 0000 1
error: could not describe device

Revision history for this message
In , Eric (eric-redhat-bugs) wrote :

*** Bug 752606 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Hubert (hubert-redhat-bugs) wrote :

I'm the OR of the dupe above. My device is a USB headset that has volume buttons in such. See the details in bug 752606. Feel free to ask info if you need for that device.

Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

(In reply to comment #2)
> # evemu-device /dev/input/event16

sorry, typo. should've been evemu-describe

evemu-device is what I run here to reproduce it :)

so, evemu-describe once, the output attached here. then evemu-record while reproducing the bug, same attached here as plain text file please

Revision history for this message
In , Eric (eric-redhat-bugs) wrote :

Created attachment 706727
evemu-describe

Revision history for this message
In , Eric (eric-redhat-bugs) wrote :

Created attachment 706728
evemu-record taking the headset off the cradle

Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

translated into evtest format (human-readable)

Event: time 1362724260.878932, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000d0
Event: time 1362724260.878932, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
Event: time 1362724260.878932, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa00082
Event: time 1362724260.878932, type 1 (EV_KEY), code 275 (BTN_SIDE), value 1
Event: time 1362724260.878932, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa00080
Event: time 1362724260.878932, type 1 (EV_KEY), code 279 (BTN_TASK), value 1
Event: time 1362724260.878932, type 1 (EV_KEY), code 279 (BTN_TASK), value 0
Event: time 1362724260.878932, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000c7
Event: time 1362724260.878932, type 1 (EV_KEY), code 286 (?), value 1
Event: time 1362724260.878932, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000c6
Event: time 1362724260.878932, type 1 (EV_KEY), code 287 (?), value 1
Event: time 1362724260.878932, -------------- SYN_REPORT ------------

so you can see that it presses both middle and side button (buttons 2 and 8 in X) and doesn't release them (presumably it does when you put it back?). That's
why the button is stuck and things break.

when you disconnect the device X releases all buttons held by that devices, so that's why normal functionality comes back.

not much we can do here, best thing is to tell X to ignore this device:
https://fedoraproject.org/wiki/Input_device_configuration#Blacklisting_a_device

Revision history for this message
cu_ (avkv-prasad) wrote :

aleko74's work around is fine if we are OK with not using the buttons on the headset.

Ideally I would love to use the buttons on the USB headset for mute/unmute, talk/end, vol up/down buttons. Also, I have three different USB headsets two Logitect and one plantronics and the behavior is the same. The headsets work great till I press any button on the headset. Once pressed, the mouse becomes un-clickable till I pull the headset out.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be
able to fix it before Fedora 18 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Revision history for this message
penalvch (penalvch) wrote :

François Marier, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xserver-xorg-input-evdev REPLACE-WITH-BUG-NUMBER

Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

Changed in xserver-xorg-input-evdev (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for xserver-xorg-input-evdev (Ubuntu) because there has been no activity for 60 days.]

Changed in xserver-xorg-input-evdev (Ubuntu):
status: Incomplete → Expired
Revision history for this message
WattoDaToydarian (dannycan) wrote :

I am having a very similar issue, we have Jabra USB headsets "Jabra UC voice duo" where I work and I am trying to migrate users to Linux however every time you press the Mute button it both mutes/unmutes and left clicks the mouse and the volume up and down don't work.

Revision history for this message
penalvch (penalvch) wrote :

WattoDaToydarian, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report by executing the following in a terminal:
ubuntu-bug xorg

Please ensure you have xdiagnose installed, and that you click the Yes button for attaching additional debugging information.

For more on this, please see the official Ubuntu documentation:
Ubuntu X.Org Team, Ubuntu Bug Control, and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report will delay your problem being addressed as quickly as possible.

Thank you for your understanding.

Revision history for this message
Karl Tomlinson (bugs+launchpad) wrote :

Why not use the existing bug, which already has some analysis and possible solution?
It sounds like the same bug.

Comment 6 and 7 seem to suggest that nothing would happen if a new bug report were filed, anyway.

Revision history for this message
WattoDaToydarian (dannycan) wrote :

Hello Chris I have ran the ubuntu-bug xorg and upload the report however I don't know where it went or if it had any information to link it to this bug.
I have added two USB headset device IDs into my xorg.conf to ignore HID input however I would really like to get the volume controls working.
Section "InputClass"
        Identifier "Jabra USB Headset"
        MatchUSBID "0b0e:0041"
        Option "Ignore" "on"
EndSection
Section "InputClass"
        Identifier "Plantronics .Audio 626"
        MatchUSBID "047f:c006"
        Option "Ignore" "on"
EndSection

Revision history for this message
penalvch (penalvch) wrote :

WattoDaToydarian, it would appear you did not successfully create a new report as per https://bugs.launchpad.net/~dannycan/+reportedbugs . Hence, please try it again, and if it still doesn't work feel free to create a bug via https://bugs.launchpad.net/ubuntu/+source/xorg/+filebug and we can take it from there.

Revision history for this message
WattoDaToydarian (dannycan) wrote :

Ok this time I saved it to a file and uploaded it from another PC. The bug number is 1314209 thanks.

Revision history for this message
reagle (joseph.reagle) wrote :

Just encountered this myself using Kubuntu 14.04 with Plantronics SAVI W440 .

Revision history for this message
penalvch (penalvch) wrote :

reagle, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report by executing the following in a terminal:
ubuntu-bug xorg

Please ensure you have xdiagnose installed, and that you click the Yes button for attaching additional debugging information.

For more on this, please see the official Ubuntu documentation:
Ubuntu X.Org Team, Ubuntu Bug Control, and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report will delay your problem being addressed as quickly as possible.

Thank you for your understanding.

Revision history for this message
Stanislav German-Evtushenko (giner) wrote :
Revision history for this message
François Marier (fmarier) wrote :

Thanks Stanislav, I was able to fix this by following your instructions.

Here's my fix for the Plantronics .Audio 626 DSP:

1. Put this in /etc/udev/rules.d/70-plantronics.rules:

  ACTION!="add|change", GOTO="xorg_plantronics_end"
  KERNEL!="event*", GOTO="xorg_plantronics_end"

  ENV{ID_VENDOR_ID}=="047f", ENV{ID_MODEL_ID}=="c006", ENV{ID_INPUT_KEY}="1"
  ENV{ID_VENDOR_ID}=="047f", ENV{ID_MODEL_ID}=="c006", RUN+="keymap $name 0xc00e9 volumeup 0xc00ea volumedown 0xb002f micmute"

  LABEL="xorg_plantronics_end"

2. Reload udev:

  sudo udevadm control --reload

3. Unplug the headset and plug it back in

Changed in gnome-shell (Debian):
status: Unknown → New
Revision history for this message
Rob Parnell (wwolfe9-rp) wrote :

This bug is still active and affects Ubuntu 14.04LTS, the workaround proposed by aleko74 (alexei-kojenov) in comment #4 is effective, but a bug fix would be prefereable.

The workaround is:
create a new configuration file in "/usr/share/X11/xorg.conf.d" called "50-plantronics.conf" or similar.
Insert:
Section "InputClass"
        Identifier "Plantronics"
        MatchVendor "Plantronics"
        Option "Ignore" "true"
EndSection

Changed in xserver-xorg-input-evdev (Ubuntu):
status: Expired → Confirmed
penalvch (penalvch)
Changed in xserver-xorg-input-evdev (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Psychotron (redm) wrote :

Same here, on Ubuntu 14.04.3 LTS.
Headset is a "Plantronics .Audio 400 DSP"
Vendor 0x47f Product 0xc009

The Mute button of the headset acts like a "button 1", i.e. same as the left (or primary) mouse button. And it works in the way that muting generates a button press event, while unmuting generates a button release event. (So I can use the mute button instead of my mouse button to "click" in the UI ;) The problem is a) that this hijacks the "button 1" and b) that it stays in pressed state and thus further press events from the real mouse button 1 are ignored (which is normally only a very short temporary state). But the real problem is that this mute button should not appear as first mouse button in the first place.

For some reason X11 seems to enter this pressed state also in other conditions, like plugging in the USB hub the headset is connected to or whatever.

A temporary fix to the problem (without restarting X11) is to mute/unmute the headset.

xev on mute:

ButtonPress event, serial 40, synthetic NO, window 0xea00001,
    root 0x2f0, subw 0xea00002, time 65571103, (53,51), root:(53,1013),
    state 0x0, button 1, same_screen YES

xev on unmute:

ButtonRelease event, serial 40, synthetic NO, window 0xea00001,
    root 0x2f0, subw 0xea00002, time 65456007, (51,45), root:(51,1007),
    state 0x100, button 1, same_screen YES

Changed in xorg-server (Fedora):
importance: Unknown → Undecided
status: Unknown → Won't Fix
penalvch (penalvch)
no longer affects: xserver-xorg-input-evdev (Ubuntu)
affects: xorg-server (Fedora) → xserver-xorg-input-evdev (Ubuntu)
Changed in xserver-xorg-input-evdev (Ubuntu):
status: Won't Fix → New
no longer affects: xserver-xorg-input-evdev (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xserver-xorg-input-evdev (Ubuntu):
status: New → Confirmed
penalvch (penalvch)
affects: gnome-shell (Debian) → xserver-xorg-input-evdev (Ubuntu)
Changed in xserver-xorg-input-evdev (Ubuntu):
importance: Unknown → Undecided
no longer affects: xserver-xorg-input-evdev (Ubuntu)
Changed in xorg (Ubuntu):
status: New → Confirmed
Revision history for this message
penalvch (penalvch) wrote :

François Marier, does this still affect you in a supported release of Ubuntu?

If so, could you please run the following command once from a terminal by ensuring you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information:
apport-collect -p xorg 1006156

affects: archlinux → xorg (Ubuntu)
Changed in xorg (Ubuntu):
status: New → Incomplete
importance: Undecided → Low
tags: added: precise
removed: input
description: updated
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Closed due to lack of response.

Changed in xorg (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.