Bug 105696

I'll need an evemu-record output of a scroll sequence that doesn't get detected correctly please, thanks.

Created attachment 138321 [details]
evemu-record of a scroll sequence that doesn't get detected correctly

sorry, I can't replay this one, you cut off the top of the file that contains the description of the touchpad. Without that, evemu can't create a virtual device and thus I can't reproduce it here. I'll need the whole file please. If it's difficult to reproduce, use --autorestart (see the man page) to keep the recording short.

Created attachment 138609 [details]
evemu-record 2

Sorry man, thought all you need is looking at the log. Here is a proper output file.

Created attachment 138610 [details]
evemu-record 3

Just more of the same.

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? 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.

Back to libinput: the issue is definitely the touch size threshold, there are only few events below 60, followed immediately by events above the threshold.

The problem appears to be:
 event25 - touch 7 is speed-based thumb
 event25 - touch 2 is speed-based thumb
 event25 - touch 4 is speed-based thumb
 event25 - touch 10 is speed-based thumb

This appears before every POINTER_MOTION sequence when two fingers are down. In short, the problem here is that the second finger is detected as thumb after the first finger moved. Not 100% sure yet why this happens, e.g. 3.712742 starts touch 7 after a single event of touch 9. We require 4 events for speed-based thumb detection though, so this simply shouldn't happen. I'll try to dig into this.

commit 928bad9104f6270dc638022ba8cc20f42a0e1b41
Author: Peter Hutterer <>
Date:   Thu Apr 5 11:18:40 2018 +1000

     touchpad: don't process state for a touch in TOUCH_NONE

(In reply to Peter Hutterer from comment #7)
> 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.

So, "resolved fixed" means that you have already fixed this in code?

Yes, the commit in comment 8 is on git master now, either use that or get your distribution to cherry-pick that commit. Or wait for the next 1.10.x stable branch release, I'll probably copy that over.

Thanks! :) Must have overlooked this.