Created attachment 135994 [details] evemu output I am using git-version from commit 6a8d5a6e: "meson.build: bump to 1.9.900". Sometimes middle click stops working in all applications in the system i.e. I can't scroll, open a new tab, paste from primary clipboard. I can use keyboard, but the only action that makes the button to start working again is clicking a distinct mouse button, e.g. the Left one. The attached `evemu-record` output is written after Middle-mouse button stopped working, by clicking it many times. Afterwards I clicked Left Mouse button (thus Middle Mouse button started working), and a few times Middle Mouse Button again. $ udevadm info /dev/input/event3 P: /devices/pci0000:00/0000:00:12.0/usb4/4-1/4-1:1.0/0003:192F:0716.0008/input/input20/event3 N: input/event3 S: input/by-id/usb-192f_0716-event-mouse S: input/by-path/pci-0000:00:12.0-usb-0:1:1.0-event-mouse E: DEVLINKS=/dev/input/by-path/pci-0000:00:12.0-usb-0:1:1.0-event-mouse /dev/input/by-id/usb-192f_0716-event-mouse E: DEVNAME=/dev/input/event3 E: DEVPATH=/devices/pci0000:00/0000:00:12.0/usb4/4-1/4-1:1.0/0003:192F:0716.0008/input/input20/event3 E: ID_BUS=usb E: ID_INPUT=1 E: ID_INPUT_MOUSE=1 E: ID_MODEL=0716 E: ID_MODEL_ENC=0716 E: ID_MODEL_ID=0716 E: ID_PATH=pci-0000:00:12.0-usb-0:1:1.0 E: ID_PATH_TAG=pci-0000_00_12_0-usb-0_1_1_0 E: ID_REVISION=0000 E: ID_SERIAL=192f_0716 E: ID_TYPE=hid E: ID_USB_DRIVER=usbhid E: ID_USB_INTERFACES=:030102: E: ID_USB_INTERFACE_NUM=00 E: ID_VENDOR=192f E: ID_VENDOR_ENC=192f E: ID_VENDOR_ID=192f E: LIBINPUT_DEVICE_GROUP=3/192f/716:usb-0000:00:12.0-1 E: MAJOR=13 E: MINOR=67 E: SUBSYSTEM=input E: USEC_INITIALIZED=90643469340
My guess here is that at some point the button debouncing enables. But it shouldn't get stuck anymore, not after the recent fixes that you already have. Pease run libinput-debug-events --verbose > somefile.txt on the side. When the issue happens the first time, look at the last set of events and whether there's a warning or something in there.
I think I better off close it for now. A few days ago this happened again, and I accidentally looked Xorg.log, and found some entries about spuriosity. This woke up a recall that right the next commit after "meson.build: bump to 1.9.900" is called "debounce: handle a timeout in MAYBE_SPURIOUS state". Before reporting the bug I did see it, however it seemed to be just docs, and also I couldn't imagine what's so spurious in my situation; so I deemed there's no reason in upgrading to this commit and waiting for the problem again. Now that I did it, I haven't experienced this yet.
It should also be noted I probably got **extremely** unlucky :D From looking the log it seems that both commits happened at the exact same second, so mine "git clone" probably have happened within some milliseconds delay between the commits. That is some vivid example of the real world data races :D
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.