Unity looses mouse click handler when using enabling USB headset

Bug #993655 reported by Jevonearth
108
This bug affects 22 people
Affects Status Importance Assigned to Milestone
xorg-server (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

I have a Plantronics D100 headset.

When I press the button on the headset to enable it, Unity looses its click handler, in that it can not click and drag windows.

The cursor is visible and moves just fine. I can switch applications using Alt+Tab, and I can launch new applications using the keyboard. But I cannot close the existing window, or change focus to another window by using the mouse.

The Headset microphone and speaker work just fine!

Tested this on a laptop and desktop machine. Both running Ubuntu 12.04.

The headset I'm using is a Plantronics D100 unit.

I have had this problem for the past month while on the 12.04 beta release.
---
ApportVersion: 2.0.1-0ubuntu7
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
DistroRelease: Ubuntu 12.04
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120301)
NonfreeKernelModules: nvidia
Package: unity 5.10.0-0ubuntu6
PackageArchitecture: amd64
ProcEnviron:
 LANGUAGE=en_CA:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.2.0-24.37-generic 3.2.14
Tags: precise
Uname: Linux 3.2.0-24-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

Revision history for this message
Jevonearth (ebjorsell) wrote : Dependencies.txt

apport information

tags: added: apport-collected precise
description: updated
Revision history for this message
Jevonearth (ebjorsell) wrote : GconfCompiz.txt

apport information

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

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

Changed in unity (Ubuntu):
status: New → Confirmed
Revision history for this message
Jeff Rasmussen (jeffrasmussen) wrote :

I'm having the same type of issue. It seems to pop up when there is a unity issue like when I have the auto-hide turned on for the Nav bar and I try to switch desktops or when I tried to move a Chrome tab out of the current window into its own window.

My mouse buttons are not usable until I log out and back on. When I tried moving the Chrome tab, the window followed my mouse like the button was still depressed and no combination of keyboard or mouse buttons were able to break the 'stuckness'. When I tried to switch desktops I got stuck seeing 4 desktops with content on each one but I was not able to click into a desktop.

Revision history for this message
Jevonearth (ebjorsell) wrote :

I have had some progress with this issue. Either something in my system has changed (I got a batch of updates this morning) or I have just explored the behaviour more thoroughly.

When I make the headset by pressing the button on the side, it turns the audio channels on. I can see this even in /sys/kernel/debug/usb/usbmon/0u as follows:

Turn headset ON:
ffff88012c4d6f00 1619795766 C Ii:3:002:3 0:2 5 = 04200413 08
ffff88012c4d6f00 1619795950 S Ii:3:002:3 -115:2 64 <
Turn headset OFF:
ffff88012c4d6f00 1623377775 C Ii:3:002:3 0:2 5 = 04200452 08
ffff88012c4d6f00 1623377969 S Ii:3:002:3 -115:2 64 <

If I loose the click handler when the headset is active, it comes back when I turn the headset off. I think this is new behaviour, but I can't be sure if it was just that I did not notice this previously.

When the click handler is lost, I can still see the click events show up in: /sys/kernel/debug/usb/usbmon/0u
Mouse button Down:
ffff88012c9b4600 1817445838 C Ii:4:002:3 0:2 15 = 20010201 00000000 00000000 000000
ffff88012c9b4600 1817445948 S Ii:4:002:3 -115:2 32 <
Mouse button Up:
ffff88012c9b4600 1818011837 C Ii:4:002:3 0:2 15 = 20010200 00000000 00000000 000000
ffff88012c9b4600 1818011944 S Ii:4:002:3 -115:2 32 <

But the clicks don't seem to be picked up by the window manager.

Another odd thing I noticed is that the problem does not happen if I turn the headset on while my cursor is hovered over the desktop background.
If the mouse cursor is hovered over my terminal window, and it is displaying the I-Beam Pointer instead of the regular pointer, then I loose the click handler.

That's all I have for now. If anyone wants me to try more tests or gather more information, please give me some instructions.

Thank you.

Revision history for this message
SirPecanGum (sirpecangum) wrote :

I am having this bug too but I don't use a Plantronics D100 headset. Loss of mouse functionality other than movement of cursor. Alt+tab also stops working intermittently. The rest of the keyboard seems functional. Logging out and back in seems to temporarily fix the problems.

Revision history for this message
SirPecanGum (sirpecangum) wrote :

Could this be similar to:

Bug #41301
Bug #878859

Revision history for this message
SirPecanGum (sirpecangum) wrote :

I have just updated, rebooted to complete and then logged straight in to this problem. It is as if unity/the desktop will not give up focus to newly opened apps. alt+tab does not work. Gnome Classic is also effected.

Revision history for this message
Jevonearth (ebjorsell) wrote :

I retested this issue today and it still exists. However, I also tested this in other window managers, such as LXDE, Openbox and Gnome/Openbox.

I get similar behaviour in all window managers, so it appears that this issue is not specific to Unity at all.

I'm asking for guidance from the community on where to file this bug, and/or how to get more useful information.

Thanks.

Revision history for this message
amias (amias) wrote :

I can confirm this bug with two different plantronics usb headsets a blackwire c-620m and a blackwire c-420m.

pressing the volume buttons triggers a lack of mouse clickability and unplugging the headset restores mouse functions.

this is on a fully updated precise install.

also this bug is marked as a duplicate of #1007525 but that bug referers to a different hardware however the problem is the same , bad input device handling is somehow making the volume buttons block mouse clicks.

Revision history for this message
Jerry Wooten (woo10jw) wrote :

Sorry if I'm not supposed to post here, just thought my circumstance might help.

12.04 fresh install with Cinnamon, Unity and Gnome desktop, it happens on all desktops.
I have a usb creative fatality headset and microsoft usb trackball mouse. I haven't notice any particular time the problem happens, my headset is always pluged in. Left click, right click stop working all together, have to Ctrl-Alt-T then sudo reboot, sometimes 2 or 3 times to get mouse to start working. Will keep headset unplug to see if this changes anything.

Revision history for this message
Jevonearth (ebjorsell) wrote :

I updated this bug so that it is no longer marked as a duplicate of #1007575 as that issue concerns a different make & model of device, though same class of device, and as far as I can see, identical issue.

Here's hoping we get some developer love on this issue.

affects: unity (Ubuntu) → ubuntu
affects: ubuntu → xorg-server (Ubuntu)
Revision history for this message
Jevonearth (ebjorsell) wrote :

I have reproduced the same problem in 12.10.

Revision history for this message
Chris J Arges (arges) wrote :

As a workaround you could use something like this to add a quirk ignore the buttons:

sudo rmmod usbhid && sudo modprobe usbhid quirks=<lsusb id>:0x04

where lsusb id is the output of lsusb that corresponds to your device:
such as 0x041e:0x0403

Please update if this helps along with the lsusb ID of your device.

Thanks

Revision history for this message
Gabriel Pereira Borges (gpborges) wrote :

I am also being affected by this bug using a Plantronics 655. This is VERY anoying and didn't happened in 10.04 :-S

dmesg:

[ 176.764095] usb 1-1.2: new full-speed USB device number 8 using ehci_hcd
[ 177.182235] input: Plantronics Plantronics .Audio 655 DSP as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.3/input/input24
[ 177.182531] generic-usb 0003:047F:C008.0009: input,hiddev0,hidraw4: USB HID v1.00 Device [Plantronics Plantronics .Audio 655 DSP] on usb-0000:00:1a.0-1.2/input3

Revision history for this message
Gabriel Pereira Borges (gpborges) wrote :

And yes, the workaround posted in comment #14 fix the issue. I've put it in a shell script and execute it when I plug the headset. We can also create a udev rule to execute the script right after plugging in the headset, right? :-)

And do you know if this is fixed in newer releases? (12.10)

Thx!

Revision history for this message
Jevonearth (ebjorsell) wrote :

The workaround in #14 is also working for me. However, whenever I pick up the device, or press any button on the device, I need to reload the usbhid module, which is very annoying.

I looked into using udev rules as suggested in #16, but the events seem to be limited to USB device attachment/detachment. I don't know how to find the event associated with the events associated with me pressing buttons on the headset.

The 'udevadm monitor' command does not list any events for button presses, just for USB attach/detach.

FYI, here's the command I use, as you can see I also unload/reload hid_logitech_dj, as I can't unload usbhid otherwise.

 sudo rmmod hid_logitech_dj && sudo rmmod usbhid && sudo modprobe usbhid quirks=047f:ab01:0x04 && sudo modprobe hid_logitech_dj

Looking forward to finding a workable solution to this. Sure is nice to use my headset again, despite having to reset quirks mode every-time I start/finish a call.

Revision history for this message
Jevonearth (ebjorsell) wrote :

@gpborges This issue has not been fixed in 12.10.

Revision history for this message
Dave Chiluk (chiluk) wrote :
Changed in xorg-server (Ubuntu):
assignee: nobody → Dave Chiluk (chiluk)
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
Jacques Burger (jacques-burger) wrote :

Has anybody made any progress on this issue please?

Dave Chiluk (chiluk) - link provided above does not work any more, is there an alternative?

Revision history for this message
Dave Chiluk (chiluk) wrote :

A similar issue was resolved for a Creative Labs headset in https://pad.lv/1007575 with kernel 3.5.0-24.37 which has been released.

If you are running a kernel later than that and this is still occurring please say so in a comment.

Revision history for this message
Dave Chiluk (chiluk) wrote :

Well apparently pad.lv doesn't like https. Here's the direct link to that other bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1007575

Revision history for this message
Jevonearth (ebjorsell) wrote :

The fix for 1007575/SB Arena USB headset doesn't work for this bug which is related to a Plantronics headset.

I believe the vendor codes are different, but the actual fix may be the same.

I tested this on Kernel 3.7 and the bug was still present. I'm running Kernel 3.8 right now, but not in a position to verify this until later in the week. I'm 95% sure it has not been fixed in Kernel 3.8.3-2

-Jev

Revision history for this message
Jevonearth (ebjorsell) wrote :

I actually got time to quickly test it, and yes, this bug still affects Plantronic headsets on Kernel 3.8.3-2

This command;
sudo rmmod usbhid && sudo modprobe usbhid quirks=047f:ab01:0x04

will resolve the issue, but you need to run it every time the device changes state, so it's not a very practical solution.

Revision history for this message
Jacques Burger (jacques-burger) wrote :

Thanks Jevonearth, was just about to test the newer kernel, now I don't have to.

Could a guru script something up that can detect state change and run that command as needed?

That way we can use the Plantronics at least a little for now until a permanent fix is available.

Revision history for this message
Jacques Burger (jacques-burger) wrote :

Turns out this is a XORG issue.

Fixed it by creating a file called "50-plantronics.conf" in "/usr/share/X11/xorg.conf.d" with the following content:

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

This gets X to ignore the Plantronics device, which makes the mouse problem go away.

Unfortunatly this also seem to stop the MIC from working so I need to figure ouy how to get that better.

Hopefully somebody makes more progress and has some more advice soon.

Revision history for this message
Dave Chiluk (chiluk) wrote :

As I don't have this headset, and it appears to be a different issue altogether there's not much I can do to help on this one.

Changed in xorg-server (Ubuntu):
assignee: Dave Chiluk (chiluk) → nobody
Revision history for this message
Mike Butash (michael-butash) wrote :

I'd spent the weekend dealing with this as last week someone at work gave me one of these plantronics devices to use, and I was stoked it would act as a headset for my pc as well. Then I started getting the screen freeze issue, and never figured out it was linked to the stupid headset. After upgrading from 12.04 to 13.10 (hitting a ton of ubuntu bugs along with the way with the intel 4000 video chipset, forcing me to hit 13.10 until I got a stable system again), and trying every window manager out there, still had this issue... Seemingly after doing anything that triggered the sound device, finally figured out it was related when disconnecting the plantronics headset would allow me to click on my display windows again. Argh!

If nothing else, can you (Canonical) simply blacklist the device by default, or at least add the xorg entry if you can't find a better way of dealing with it? This is likely to make any user lose their hair as it about did for me.

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 :

Jevonearth, 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 xorg-server 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 xorg-server (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
reagle (joseph.reagle) wrote :

I can confirm this bug still exists in Kubuntu 13.10 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
kikjezrous (kikjezrous) wrote :

Can confir, Ubuntu 14.04 with Logitech H340 USB headphones. When they are plugged in, the pointer controller decides that the LMB is being held. RMB, MMB, scroll, and pointer location all function across touchpad, USB mouse, and graphical tablet, but LMB does not. Running the 3.13.0-23-generic kernel.

The workaround
sudo rmmod usbhid && sudo modprobe usbhid quirks=<lsusb id>:0x04
does not work, instead all clicking functionality is lost when the headphones are plugged in.

Reported as bug #1307044

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

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

Changed in xorg-server (Ubuntu):
status: Incomplete → Expired
Revision history for this message
mark davis (mark-davis2) wrote :

Confirming that this is still an issue:

Ubuntu 14.04 (Gnome 3)
Plantronics D-10

Symnptoms are windows not clicking, dragging, dash key not working, etc.

Revision history for this message
penalvch (penalvch) wrote :

mark davis, 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.

As well, please do not announce in this report you created a new bug report.

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
Sam Brightman (sambrightman) wrote :

I have a very similar-sounding issue with Logitech wireless mouse (no headset). Periodically loses click handlers or something with very closely related symptoms. Try switching to console and back (Ctrl-Alt-F1, Ctrl-Alt-F7).

Revision history for this message
Sam Brightman (sambrightman) wrote :

Christopher, I created bug 1371853 and added you there.

Revision history for this message
Christian Löpke (innos-zorn-chris) wrote :

I can confirm this bug with a Corsair VOID RGB wireless headset.
Mouse movement works all the time but sometimes (every 15 min ca.) mouse clicks are not recognized any more till I switch tty with strg+alt+F1 and back to seven.

Im using XUbuntu 15.04 and really want to help.
But I dont know where to look for debug outputs.

Can someone help me ?
Which informations are required to debug this ?

Revision history for this message
penalvch (penalvch) wrote :

Christian Löpke, it will help immensely if you filed a new report with Ubuntu via a terminal:
ubuntu-bug xorg

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

Also, please feel free to subscribe me to it.

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

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

Changed in xorg-server (Ubuntu):
status: New → Confirmed
Revision history for this message
penalvch (penalvch) wrote :

OR using EOL release, no debug logs, and no response for years.

affects: xorg-server (Debian) → xorg-server (Ubuntu)
Changed in xorg-server (Ubuntu):
importance: Unknown → Undecided
status: New → 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.