<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - Apple Magic Trackpad scrolling prevented by speed-based thumb detection (libinput 1.10)" href="https://bugs.freedesktop.org/show_bug.cgi?id=105696#c9">Comment # 9</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - Apple Magic Trackpad scrolling prevented by speed-based thumb detection (libinput 1.10)" href="https://bugs.freedesktop.org/show_bug.cgi?id=105696">bug 105696</a> from <a class="email" href="mailto:benjamin.tissoires@gmail.com" title="Benjamin Tissoires <benjamin.tissoires@gmail.com>"> Benjamin Tissoires</a> <pre>(In reply to Peter Hutterer from <a href="show_bug.cgi?id=105696#c7">comment #7</a>) > First I think there's something wrong with your kernel > > E: 0.253846 0001 0145 0002 # EV_KEY / BTN_TOOL_FINGER 2 > > I haven't seen that before, a repeat event for BTN_TOOL_FINGER? Benjamin, > any ideas? That's because the input device is created partly from the report descriptor, partly from scratch. The EV_REP bit is set because of the keyboard emulation in the device, and so any key event will get repeated. We can safely ignore those. > Also, the slot association is strange, usually the slot numbers > match the fingers down and get re-used, this recording seems to use them in > seemingly arbitrary order. That's generally fine, just unusual. > That's because it's one of these devices where the slot is directly forwarded from the device, not generated by the kernel. IIRC, on the magicmouse, if you touch at one place, release, then touch at the same spot, the slot will stay the same. If you touch anywhere else, the slot will be different. It's information, but we don't do anything about it under Linux as only those 2 devices are consistently reporting this that way.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>