Hello, after #103572 fixed the overall Magic Trackad sensitivity regression introduced in libintput 1.9, the patch does not fully restore the previous level of sensitivity. Most of the time, cursor movement works reliable but scrolling is still a hit or miss. I have rather small fingers and soft skin and thought the new touch range of 60:40 must be set too high (see #103572). I have followed the instructions in comment 22 to alter the value to 20:10, and now "sudo udevadm test /sys/class/input/event21" reports "LIBINPUT_ATTR_TOUCH_SIZE_RANGE=20:10". But this did not fix the scrolling problem (maybe a tiny bit better than before but this might be an illusion). Sometimes, I need to really put pressure on the trackpad to start scrolling. It’s really annoying and I can’t remember this device being so insensitive to simple scroll gestures in Linux since I have bought it in 2011. To illustrate this, I have recorded a video (pardon the upright format but in this case it actually makes sense): https://youtu.be/s-qtTzMP5HA Interestingly, gestures with more fingers seem to work more reliably (Kwin effects triggered by libinput-gestures).
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.
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.