3

A few days ago, my mouse button releases began sometimes not being recognised when I release two of the buttons simultaneously. The logical state of one button therefore gets stuck on "down", causing annoying unintended actions until I press it again to reset it.

I could reproduce the issue monitoring mouse events in xev (output sometimes doesn't show expected key release events). I could not reproduce the issue by monitoring events in /sys/kernel/debug/usb/usbmon (output is always consistent with reality).

So the fault clearly lies with a software component at some abstraction below X11, but above USB.

What could be causing this? How could I narrow this down further?

Anko
  • 4,526

1 Answers1

5

The levels between USB events and X events are:

  • Unless your mouse is special and has its own driver, it's very likely a HID device. Find the corresponding hidraw device (check dmesg), and verify you get events there. USB to HID translation is done by the kernel.

  • All input events leave the kernel through the input-layer, the corresponding devices are in /dev/input. Run evtest as root, select your mouse, see if you get events. Translation from HID events to input events is done by the kernel.

  • X automatically loads drivers for all input devices, in most cases the evdev driver. See /var/log/Xorg.0.log about which driver(s) get loaded. These drivers translate input events to X events.

dirkt
  • 32,309
  • 1
    i think libinput is replacing evdev in X these days. – quixotic Nov 10 '17 at 09:37
  • @quixotic: libinput is for Wayland what evdev is for X. So unless you are using an X emulation under Wayland instead of "real" X, you are using evdev. – dirkt Nov 10 '17 at 12:32
  • 2
    there's a wrapper driver for Xorg as well. on Arch this is provided by the xf86-input-libinput package. see https://wiki.archlinux.org/index.php/Libinput and https://github.com/freedesktop/xorg-xf86-input-libinput – quixotic Nov 10 '17 at 13:09
  • 1
    the stack diagrams at https://en.wikipedia.org/wiki/Evdev point out the distinction between evdev the kernel driver and xf86-input-evdev the Xorg driver: kernel > libevdev > xf86-input-evdev > Xserver > Xclient vs kernel > libevdev > libinput > xf86-input-libinput > Xserver > Xclient. as you point out, which driver is loaded and used should show up in the Xorg logfile. – quixotic Nov 10 '17 at 13:17
  • 1
    @quixotic @dirkt Thank you both for your knowledge! Results: My evtest output looks correct even when the issue occurs, so the kernel and libevdev must be innocent. I don't have xf86-input-evdev installed, so the correct route up must be through libinput → xf86-input-libinput → X11. The logging tool for libinput is apparently libinput debug-events, where the problem finally appears in the logs! That narrows it down to libinput. I'll contact the developers. – Anko Nov 10 '17 at 14:44
  • So the obvious (at least temporary) thing to try is to deinstall xf86-input-libinput, and install xf86-input-evdev instead, and see if that fixes the problem. – dirkt Nov 10 '17 at 16:23