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.
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.
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.
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.
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
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)
> 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.
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
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).
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)
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...
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.
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.
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 ;)
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.