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?

Improve this question
1

1 Answer 1

Reset to default
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.

Improve this answer
6
  • 1
    i think libinput is replacing evdev in X these days. Commented Nov 10, 2017 at 9: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. Commented Nov 10, 2017 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 wiki.archlinux.org/index.php/Libinput and github.com/freedesktop/xorg-xf86-input-libinput Commented Nov 10, 2017 at 13:09
  • 1
    the stack diagrams at 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. Commented Nov 10, 2017 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. Commented Nov 10, 2017 at 14:44

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.