For the last several weeks, my Microsoft (wireless) All-in-One Media Keyboard has required a triple-tap on the trackpad to highlight a single word of text. It only used to need a double-tap (as you'd expect), so I know this is a fairly recent bug. It has nothing to do with my desktop environment (KDE), as the problem occurs in LXDE too. Both run on X, BTW: I don't use Wayland yet. I have obviously tested it using different applications (i.e. not just my web browser) as well. It's important to note that it only happens with tapping (i.e. not clicking). If I double-click on the same part of the trackpad, the word is highlighted as expected. However, if I instead double-tap, nothing happens. The relevant output from the "usb-devices" command is as follows: T: Bus=02 Lev=01 Prnt=01 Port=11 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=045e ProdID=0800 Rev=09.34 S: Manufacturer=Microsoft S: Product=Microsoft® Nano Transceiver v2.0 C: #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=100mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid I: If#=0x1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid I: If#=0x2 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid I originally reported this bug to the 'linux-usb' mailing list. They suggested it might instead be a 'libinput' problem, which it is. After issuing "downgrade libinput" (on Arch Linux), choosing v1.8.3, and relaunching X, the problem went away. Jumping (back) up to v1.9.1 (or newer) made it reappear. This means the offending section of code was incorporated somewhere between those versions. Let me know if you need me to narrow it down further. I'm happy to run more tests and/or supply additional information.
please attach an evemu-record output of a sequence that gets misdetected, should be easy enough to identify. thanks
ping?
Created attachment 136870 [details] Tapping sequence captures
I'm sorry for taking so long to reply, Peter. I'm usually more responsive than this. I've been a bit busy with work lately. I have run the tests you requested and attached the results. Unfortunately, I don't think they identify the problem. When I run the v1.9.1 recordings using v1.8.3 (via 'evemu-play'), they work just fine. Similarly, when I run the v1.8.3 recordings using v1.9.1, they behave the same as the v1.9.1 recordings. I don't think the problem is in the sensing code. I think, higher up, the v1.9.1 code is set to always ignore the first tap in a sequence. That'd explain why it needs three (to highlight a word) rather than two. I hope this information has been helpful. Let me know if you'd like me to run any further tests.
Ok, the issue here is the new button debouncing code. The event sequence shows this for the second button press: E: 0.135988 0004 0004 589825 # EV_MSC / MSC_SCAN 589825 E: 0.135988 0001 0110 0001 # EV_KEY / BTN_LEFT 1 E: 0.135988 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +8ms E: 0.145980 0004 0004 589825 # EV_MSC / MSC_SCAN 589825 E: 0.145980 0001 0110 0000 # EV_KEY / BTN_LEFT 0 E: 0.145980 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +10ms i.e. the device pretends the button was pressed 8ms after releasing it and released 10ms after pressing it. This is too short a timeout for real-world button clicking and is usually a sign of broken buttons. Because it is pressed and released within the timeouts the button event is discarded (you should have a message in the log warning you about this). I can't think of a good way to fix this but I guess not debouncing of this set of devices is a workaround.
I'd say that's the way to go. Whether you like or hate Microsoft, there's no denying their high engineering standards. They've probably got their own debouncing circuit/code built into the keyboard/transceiver.
any chance you can work on this? needs an LIBINPUT_MODEL_foo tag, parsed in evdev.c, then checked for during the button debouncing initialization code in fallback_init_debounce(). Needs some sort of setting for want_debounce or maybe a custom DEBOUNCE_STATE_DISABLED state that just never goes anywhere but itself (not sure which one will be nicer in code).
I last coded in C back in 2007. My knowledge of it has deteriorated over the years. On top of that, I've never even so much as inspected the 'libinput' codebase. I can take a look at this when I get time, but I wouldn't hold my breath if I were you.
Created attachment 137101 [details] [review] 0001-evdev-add-a-quirk-to-disable-debouncing-on-the-MS-Na.patch Give this one a test please. You'll need to update the hwdb accordingly, see: https://wayland.freedesktop.org/libinput/doc/latest/udev_config.html#hwdb Unless I typoed something, it should work after the above commands and a restart. Make sure the udev property appears in the udevadm info output before you restart though.
The patch works well (on git-master), Peter. I've tested it with both double and triple taps. Thanks very much for your efforts! I look forward to seeing it in the next (presumably v2.0.0) release. I perused the code a few days ago and felt reasonably confident about being able to fix the problem. Looking at all the changes made in your patch, though, I fear my solution would have been too simplistic.
thanks for testing, much appreciated. Reopening because it's not on git master yet, will be closed once it's pushed.
https://lists.freedesktop.org/archives/wayland-devel/2018-February/036743.html
commit 3a3fd645c4a78ff85e66327d51c4262292c5b09a Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Wed Jan 31 16:18:15 2018 +1000 evdev: add a quirk to disable debouncing on the MS Nano Transcievers
This bug has returned in libinput v1.12.0. It was not present in v1.11.3, so I have reverted to that for the time being. When you fix it this time, are you able to do so *permanently*?
just a typo in the transition from the hwdb to the quirks system, fixed with 0ffe6043a65319b72f2a226b91bdacbd5eacdc2f
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.