Bug 104415 - My wireless all-in-one (keyboard/mouse) requires a triple-tap to highlight a word
Summary: My wireless all-in-one (keyboard/mouse) requires a triple-tap to highlight a ...
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: low minor
Assignee: Peter Hutterer
QA Contact:
URL: https://www.microsoft.com/accessories...
Depends on:
Reported: 2017-12-30 00:55 UTC by Xavion
Modified: 2018-09-17 21:55 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

Tapping sequence captures (1.47 KB, application/x-bzip)
2018-01-21 04:06 UTC, Xavion
0001-evdev-add-a-quirk-to-disable-debouncing-on-the-MS-Na.patch (8.09 KB, patch)
2018-02-01 01:13 UTC, Peter Hutterer
Details | Splinter Review

Description Xavion 2017-12-30 00:55:39 UTC
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.
Comment 1 Peter Hutterer 2018-01-05 00:22:11 UTC
please attach an evemu-record output of a sequence that gets misdetected, should be easy enough to identify. thanks
Comment 2 Peter Hutterer 2018-01-16 06:53:14 UTC
Comment 3 Xavion 2018-01-21 04:06:18 UTC
Created attachment 136870 [details]
Tapping sequence captures
Comment 4 Xavion 2018-01-21 04:08:01 UTC
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.
Comment 5 Peter Hutterer 2018-01-21 23:10:39 UTC
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.
Comment 6 Xavion 2018-01-22 22:08:03 UTC
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.
Comment 7 Peter Hutterer 2018-01-23 05:29:52 UTC
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).
Comment 8 Xavion 2018-01-23 23:39:24 UTC
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.
Comment 9 Peter Hutterer 2018-02-01 01:13:44 UTC
Created attachment 137101 [details] [review]

Give this one a test please. You'll need to update the hwdb accordingly, see:

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.
Comment 10 Xavion 2018-02-01 06:57:07 UTC
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.
Comment 11 Peter Hutterer 2018-02-01 07:23:43 UTC
thanks for testing, much appreciated. Reopening because it's not on git master yet, will be closed once it's pushed.
Comment 13 Peter Hutterer 2018-02-13 06:08:48 UTC
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
Comment 14 Xavion 2018-09-15 01:13:30 UTC
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*?
Comment 15 Peter Hutterer 2018-09-17 21:55:09 UTC
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.