Bug 1571114 - USB wireless mouse clicking on window chrome has no effect
Summary: USB wireless mouse clicking on window chrome has no effect
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libinput
Version: 27
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-24 06:51 UTC by Will Thames
Modified: 2018-06-04 11:55 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-02 03:36:25 UTC
Type: Bug


Attachments (Terms of Use)
event6 output log (16.93 KB, text/plain)
2018-04-26 00:16 UTC, Will Thames
no flags Details

Description Will Thames 2018-04-24 06:51:52 UTC
Description of problem:

The USB mouse I have been using for some time with Fedora 27 has recently started becoming problematic (my memory suggests this happened only I ran xev to find the ID of a button).

Symptoms are that the mouse won't switch between applications in the dock, or e.g.between tabs in Firefox or in xfce-terminal, or won't click into this text input box, or the mouse wheel won't scroll, or it won't select text.

If I unplug the USB key, or even just power off the mouse, then I have no problem using the trackpad. However, with the mouse still active, the trackpad suffers the same symptoms as the mouse.


Version-Release number of selected component (if applicable):

libinput-1.10.2-4.fc27.x86_64
xorg-x11-drv-libinput-0.26.0-1.fc27.x86_64


How reproducible:

If I reboot or restart Xorg it tends to happen after minutes, but I don't understand the underlying issue well enough to provide reproduction from scratch.


Additional info:

There are no interesting logs associated with me turning the mouse on and off as I might expect in /var/log/messages, dmesg or journalctl but I can provide those logs if they will help.

Comment 1 Peter Hutterer 2018-04-25 23:01:17 UTC
Sounds like a stuck button, but that could be either in HW or in software.

First thing to check: sudo evemu-record when the button is stuck, check if the BTN_LEFT events are visible. If not, then you have a hw problem.

Second thing to check: grep your xorg log/journal for "debouncing", could be that the device triggered the libinput debouncing code and it got stuck

If it's neither of those, then the issue is either in libinput or the compositor/Xorg. That's going to be much harder to track down, so let's check those two first please.

Comment 2 Will Thames 2018-04-25 23:17:44 UTC
BTN_LEFT is definitely being recorded

debouncing is not in journal but does appear in Xorg.0.log

[  6746.831] (II) event6  - Microsoft Microsoft® 2.4GHz Transceiver v9.0: Enabling spurious button debouncing, see https://wayland.freedesktop.org/libinput/doc/1.10.2/button_debouncing.html for details

Starting to think this might be more xfce/X than libinput.

I noticed while navigating to the terminal to run evemu-record that a window that appears to have focus isn't necessarily the one receiving the mouse events. The fact that this stops happening as soon as I turn off the wireless mouse is the only thing that does make me think it *is* input related.

Comment 3 Peter Hutterer 2018-04-25 23:32:26 UTC
What's the product/vendor ID on those Transceivers? the Input device ID: line of evemu-record will tell you. We have a quirk for an earlier version of those to disable debouncing because they send in bursts. Look at 90-libinput-model-quirks.hwdb and search for LIBINPUT_MODEL_MS_NANO_TRANSCEIVER. Add your pid/vid to that and run sudo udevadm hwdb --update before plugging in the device again. Does that fix things?

https://wayland.freedesktop.org/libinput/doc/latest/udev_config.html#hwdb

It could still be in libinput somewhere, let's see if the above fixes it. Might be worth running sudo libinput debug-events --verbose > somefile.out in screen. Start it immediately after your session (ideally without using your mouse), and cancel it once the bug occurs. Check the output for BTN_LEFT events, if you see them there but not in X, then it's more likely an X bug. If they don't show up in that log either then it's definitely a libinput bug and I'll need that output file.

Comment 4 Will Thames 2018-04-26 00:09:09 UTC
From 90-libinput-model-quirks.hwdb I get:


# Microsoft Microsoft® Nano Transceiver v2.0"
libinput:mouse:input:b0003v045Ep0800*
 LIBINPUT_MODEL_MS_NANO_TRANSCEIVER=1

Using evemu-describe, I get the following, which is presumably

libinput:mouse:input:b0003v045ep07a5*

# EVEMU 1.3
# Kernel: 4.15.17-300.fc27.x86_64
# DMI: dmi:bvnDellInc.:bvr1.6.1:bd12/11/2017:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA01:cvnDellInc.:ct9:cvr:
# Input device name: "Microsoft Microsoft® 2.4GHz Transceiver v9.0"
# Input device ID: bus 0x03 vendor 0x45e product 0x7a5 version 0x111
# Supported events:
#   Event type 0 (EV_SYN)
#     Event code 0 (SYN_REPORT)
#     Event code 1 (SYN_CONFIG)
#     Event code 2 (SYN_MT_REPORT)
#     Event code 3 (SYN_DROPPED)
#     Event code 4 ((null))
#     Event code 5 ((null))
#     Event code 6 ((null))
#     Event code 7 ((null))
#     Event code 8 ((null))
#     Event code 9 ((null))
#     Event code 10 ((null))
#     Event code 11 ((null))
#     Event code 12 ((null))
#     Event code 13 ((null))
#     Event code 14 ((null))
#     Event code 15 (SYN_MAX)
#   Event type 1 (EV_KEY)
#     Event code 272 (BTN_LEFT)
#     Event code 273 (BTN_RIGHT)
#     Event code 274 (BTN_MIDDLE)
#     Event code 275 (BTN_SIDE)
#     Event code 276 (BTN_EXTRA)
#   Event type 2 (EV_REL)
#     Event code 0 (REL_X)
#     Event code 1 (REL_Y)
#     Event code 6 (REL_HWHEEL)
#     Event code 7 (REL_DIAL)
#     Event code 8 (REL_WHEEL)
#   Event type 4 (EV_MSC)
#     Event code 4 (MSC_SCAN)
# Properties:
N: Microsoft Microsoft® 2.4GHz Transceiver v9.0
I: 0003 045e 07a5 0111
P: 00 00 00 00 00 00 00 00
B: 00 0b 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 1f 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 02 c3 01 00 00 00 00 00 00
B: 03 00 00 00 00 00 00 00 00
B: 04 10 00 00 00 00 00 00 00
B: 05 00 00 00 00 00 00 00 00
B: 11 00 00 00 00 00 00 00 00
B: 12 00 00 00 00 00 00 00 00
B: 14 00 00 00 00 00 00 00 00
B: 15 00 00 00 00 00 00 00 00
B: 15 00 00 00 00 00 00 00 00


I will update this further with the results of running udevadm --update

Comment 5 Will Thames 2018-04-26 00:16:05 UTC
Created attachment 1426926 [details]
event6 output log

The change to the quirks hwdb didn't seem to have much effect.

This log contains the three BTN_LEFT presses that I made (as well as an accidental BTN_SIDE press)

Comment 6 Peter Hutterer 2018-04-26 00:23:53 UTC
> libinput:mouse:input:b0003v045ep07a5*

common trap I fall into regularly, the hex codes have to be uppercase, 
b0003v045Ep07A5 in this case. When it works, udevadm info /sys/class/input/event6 (adjust if necessary) should show the LIBINPUT_MODEL... tag. Then the debouncing itself should go away. But at least this log doesn't show debouncing kicking in anyway, so there's a chance it's higher up in the stack.

Comment 7 Will Thames 2018-04-26 00:37:25 UTC
Based on that, I can't get it to take at all - LIBINPUT_MODEL isn't showing up in udevadm info

$ grep -B2 _NANO /usr/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb
# Microsoft Microsoft® Nano Transceiver v2.0"
libinput:mouse:input:b0003v045Ep0800*
 LIBINPUT_MODEL_MS_NANO_TRANSCEIVER=1
--
# Microsoft Microsoft® 2.4GHz Transceiver v9.0"
libinput:mouse:input:b0003v045Ep07A5*
 LIBINPUT_MODEL_MS_NANO_TRANSCEIVER=1

$ sudo udevadm hwdb --update

$ sudo udevadm info  /sys/class/input/event6
P: /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.1/0003:045E:07A5.0007/input/input32/event6
N: input/event6
S: input/by-id/usb-Microsoft_Microsoft®_2.4GHz_Transceiver_v9.0-if01-event-mouse
S: input/by-path/pci-0000:00:14.0-usb-0:2:1.1-event-mouse
E: DEVLINKS=/dev/input/by-id/usb-Microsoft_Microsoft®_2.4GHz_Transceiver_v9.0-if01-event-mouse /dev/input/by-path/pci-0000:00:14.0-usb-0:2:1.1-event-mouse
E: DEVNAME=/dev/input/event6
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.1/0003:045E:07A5.0007/input/input32/event6
E: ID_BUS=usb
E: ID_INPUT=1
E: ID_INPUT_MOUSE=1
E: ID_MODEL=Microsoft®_2.4GHz_Transceiver_v9.0
E: ID_MODEL_ENC=Microsoft®\x202.4GHz\x20Transceiver\x20v9.0
E: ID_MODEL_ID=07a5
E: ID_PATH=pci-0000:00:14.0-usb-0:2:1.1
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_2_1_1
E: ID_REVISION=0777
E: ID_SERIAL=Microsoft_Microsoft®_2.4GHz_Transceiver_v9.0
E: ID_TYPE=hid
E: ID_USB_DRIVER=usbhid
E: ID_USB_INTERFACES=:030101:030102:030000:
E: ID_USB_INTERFACE_NUM=01
E: ID_VENDOR=Microsoft
E: ID_VENDOR_ENC=Microsoft
E: ID_VENDOR_ID=045e
E: LIBINPUT_DEVICE_GROUP=3/45e/7a5:usb-0000:00:14.0-2
E: MAJOR=13
E: MINOR=70
E: SUBSYSTEM=input
E: USEC_INITIALIZED=342757333

Comment 8 Peter Hutterer 2018-04-26 04:17:17 UTC
Are you unplugging the device? If not, run sudo udevadm test /sys/class/input/event6 to see what udev does (sudo so it applies the properties directly, otherwise you have to run sudo udevadm trigger).

Comment 9 Will Thames 2018-04-26 04:25:19 UTC
Ah, no, I was turning the mouse off and on. Removing and returning the USB stick did indeed trigger the reload, and the udevadm output is now as expected. 

It hasn't made any difference though (as indeed you suggested it wouldn't)

Comment 10 Peter Hutterer 2018-04-26 04:36:22 UTC
Right, the only difference it would make is if the stuck button was inside libinput and caused by the debouncing code. So now it's down to Xorg vs the window manager. Since you're on xfce it'd be worth giving gnome a try for a while and testing if you can reproduce it there. If not, most likely an xfce bug. Otherwise it's an xserver bug which is going to be a nightmare to debug...

Comment 11 Will Thames 2018-04-26 04:56:32 UTC
Ok, I'll give gnome a try and report back. I guess the other option is to completely wipe my xfce settings after taking a backup (so that I can later get a diff), but I'll try gnome first.

Comment 12 Will Thames 2018-04-26 05:20:30 UTC
This is not improved by switching to Gnome. I also tried downgrading Xorg to see if a recent RPM update had had an effect, as this problem hasn't been happening very long.

Comment 13 Peter Hutterer 2018-04-30 22:28:14 UTC
hmm, next question: do you have a second mouse that you can try? If not, does disabling the touchpad make any difference? I'm wondering if the bug is actually with the touchpad but it obscures the mouse and that is the one you can remove. I had a similar bug once when a bluetooth touchpad decided to connect and messed up my buttons.

xinput disable "touchpad device name" should do the job, props if you guess the command to re-enable it ;)

Comment 14 Will Thames 2018-05-02 03:36:25 UTC
Sorry, I'm going to have to close this now - the laptop has been returned with a change of job. If I reproduce it again in future with the identical model I'll reopen.


Note You need to log in before you can comment on or make changes to this bug.