Bug 103572 - Libinput: 1.9+: Apple Magic Trackpad stutters, is unresponsive
Summary: Libinput: 1.9+: Apple Magic Trackpad stutters, is unresponsive
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Wayland bug list
QA Contact:
: 103970 (view as bug list)
Depends on:
Reported: 2017-11-04 17:18 UTC by Maximilian Böhm
Modified: 2018-04-19 04:26 UTC (History)
7 users (show)

See Also:
i915 platform:
i915 features:

libinput-debug-events.1.8.4.log (45.93 KB, text/x-log)
2017-11-11 20:54 UTC, Maximilian Böhm
libinput-debug-events.1.9.log (45.58 KB, text/x-log)
2017-11-11 20:54 UTC, Maximilian Böhm
0001-Fix-Apple-Magic-Trackpad-sensitivity.patch (1.46 KB, patch)
2018-02-27 08:02 UTC, Daniel van Vugt
Details | Splinter Review
a patch using a pair of values (60:40) to fix the issue (460 bytes, patch)
2018-02-28 11:42 UTC, Mario
Details | Splinter Review
a signoff version of the previous patch with 60:40 thresholds (829 bytes, patch)
2018-03-01 10:58 UTC, Mario
Details | Splinter Review
fix-Apple-Magic-Trackpad-20180417.patch (1.37 KB, patch)
2018-04-17 02:50 UTC, Daniel van Vugt
Details | Splinter Review
fix-Apple-Magic-Trackpad-20180418.patch (1.37 KB, patch)
2018-04-18 03:10 UTC, Daniel van Vugt
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Maximilian Böhm 2017-11-04 17:18:59 UTC
After the 1.9 libinput update, my Magic Trackpad stopped working correctly. The cursor stutters, hangs, is unresponsive. A downgrade to 1.8.3 solves this for me.
Distro: Antergos/Arch
Comment 1 Mario 2017-11-04 20:40:44 UTC
The same here with a Magic Trackpad (the old model with the AA batteries). I had to rollback to the 1.8.3 version of libinput on Arch Linux.
Comment 2 Peter Hutterer 2017-11-07 05:41:26 UTC
Run sudo libinput debug-events --verbose and look at the output, is it detecting a lot of begin/end touches based on pressure? I have the old model here and I can reproduce what I think is the issue by very lightly pressing on the touchpad with my fingertip only. Try pressing harder and see if the issue disappears, if so we know that the pressure ranges are the problem.
Comment 3 Mario 2017-11-08 17:37:41 UTC
I will report the requested details when at home (my Magic Trackpad is there) but I can put in advance that:
- yes, I got an old model of the Magic Trackpad;
- yes, the weird behavior happened when I was lightly touching the pad (as I'm used to); pressing harder looked to "fix" the problem (very annoying...).
Comment 4 Peter Hutterer 2017-11-09 03:54:16 UTC
run sudo libinput measure touchpad-size and follow the instructions there (and in the man page). might have to adjust the touch pressure sizes for your touchpad.

by "very lightly" i meant taking care to almost not touch the touchpad, you should not need any downward pressure to trigger a touch (beyond gravity)
Comment 5 Mario 2017-11-09 08:51:34 UTC
This is the output of the measurement test:

sudo libinput measure touch-size /dev/input/event22
Ready for recording data.
Touch sizes used: 130:150
Palm size used: 800
Place a single finger on the device to measure touch size.
Ctrl+C to exit

Sequence: major: [  0..268] minor: [  0..298]  down           
Sequence: major: [  0..248] minor: [  0..306]  down           
Sequence: major: [  0..256] minor: [  0..333]  down           
Sequence: major: [  0..256] minor: [  0..337]  down           
Sequence: major: [  0..260] minor: [  0..276]  down           
Sequence: major: [  0..244] minor: [  0..300]  down

I'm not sure what kind of touch I was supposed to record. I applied the typical touch pressure I use on all my touchpads to get a click, getting the expected behavior until libinput 1.9.1.
Comment 6 Mario 2017-11-09 09:10:10 UTC
On the previous test it looks that libinput 1.9.1 get the correct 'down' event on my attempt: I'm wondering if the problem is different. 
I get spurious click just when I move the cursor with the, usual, light pressure. It's also very difficult to get a proper 2-3-or-4 fingers swipe gesture.
Comment 7 Maximilian Böhm 2017-11-11 20:54:12 UTC
Created attachment 135402 [details]
Comment 8 Maximilian Böhm 2017-11-11 20:54:38 UTC
Created attachment 135403 [details]
Comment 9 Maximilian Böhm 2017-11-11 21:00:48 UTC
So, I tried "sudo libinput measure touchpad-size" with all /etc/input/event[n], just got each time:

»"Traceback (most recent call last):
  File "/usr/lib/libinput/libinput-measure-touch-size", line 29, in <module>
    import evdev
ModuleNotFoundError: No module named 'evdev'«

But I run "sudo libinput debug-events --verbose" and uploaded the logs as attachments. I can confirm: Light touches seem to be missed, strong touches are recognized more often. I have the original metallic Magic Trackpad too.
Comment 10 Peter Hutterer 2017-11-13 04:05:28 UTC
you need python3-evdev for the tool, should be in your package repository
Comment 11 Peter Hutterer 2017-11-16 23:56:50 UTC
Comment 12 Mario 2017-11-17 08:35:36 UTC
@Peter Do you need further information by me? Do you think that my case is related to the wrong touch size?
Comment 13 Peter Hutterer 2017-11-17 09:11:50 UTC
Most likely it is, but I can't say for sure without the measurement data, sorry.
Comment 14 Mario 2017-11-17 09:38:58 UTC
@Peter what further data do you need by me?
Comment 15 Peter Hutterer 2017-11-17 10:06:04 UTC
Play with the libinput tool from above and see what the ranges are that you need to detect the touches correctly. I don't have a touchpad with size in front of me right now, but iirc it prints 'down' when it considers a touch logically down. so basically what you do is run the tool and check if it prints it correctly when you use the touchpad. check the man page too, you can tweak the pressure values and see if they need changing from the current 130:150 threshold.

note that the tool has no effect on the running session
Comment 16 Mario 2017-11-17 10:49:19 UTC
@Peter note that I used 'libinput measure touch-size'. I remember that I didn't find the module 'libinput measure touchpad-size'. Is it correctly spelled?

As reported, I had problem of spurious clicks during a linear moving of the finger on the touchpad. I assume that detecting the "correct size" should solve this problem too, right?

Can you specify how to locally apply the new rage if I want to see if it fix my problem? I don't want to bother you more than the strictly necessary.
Comment 17 Peter Hutterer 2017-11-20 04:05:49 UTC
same tool yeah, sorry, just mis-remembered the exact name

look at commit 64fcd7bd024124acdaa3dd1e544775dc906f7c45 for a pressure range example.  the hwdb match has to match your system's dmi modalias. 

how to apply hwdb changes:
Comment 18 Peter Hutterer 2017-12-18 04:56:05 UTC
a month in needinfo, closing. please re-open when the required data has been supplied
Comment 19 Mario 2017-12-18 07:27:57 UTC
Sorry, I had busy weeks and no time to play with the measurement tools in order to find proper params. I'm stick with libinput 1.8.3 now...

I'll reopen or make a PR when I find proper values for the Magic Trackpad.
Comment 20 Maximilian Böhm 2018-02-11 20:47:53 UTC
Hey, sorry for my former retirement on this issue. To be honest, I just downgraded and hoped someone™ would fix it. But now, Plasma 5.12 is forcing me to use libinput 1.9, so here I am again.
On Arch, I had to install python-evdev and python-pyudev, then I was able to run "sudo libinput measure touch-size /dev/input/event21".
It seems to be a pressure issue indeed. Using my thumb works best to move the cursor ("down").

Unfortunately, this seems broken:
$ sudo libinput measure touchpad-pressure --touch-thresholds=100:100
libinput-measure: unrecognized option '--touch-thresholds=10:8'
Usage: libinput measure [--help] <feature> [/dev/input/event0]

So I created a /etc/udev/hwdb.d/99-touchpad-pressure.hwdb
libinput:name:*Trackpad von maximilian:dmi:bvnAmericanMegatrendsInc.:bvrF3i:bd10/07/2014:svnGigabyteTechnologyCo.,Ltd.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnGigabyteTechnologyCo.,Ltd.:rn990FXA-UD3:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvrToBeFilledByO.E.M.:*

- to test other ranges. I got the name and DMI from evemu-record:

/dev/input/event21:     Trackpad von maximilian
Select the device event number [0-21]: 21
# EVEMU 1.3
# Kernel: 4.15.2-2-ARCH
# DMI: dmi:bvnAmericanMegatrendsInc.:bvrF3i:bd10/07/2014:svnGigabyteTechnologyCo.,Ltd.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnGigabyteTechnologyCo.,Ltd.:rn990FXA-UD3:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvrToBeFilledByO.E.M.:
# Input device name: "Trackpad von maximilian"
# Input device ID: bus 0x05 vendor 0x5ac product 0x30e version 0x160
# Size in mm: 132x111

But after running "sudo udevadm hwdb --update", "sudo udevadm test /sys/class/input/event21" still shows:
A relogin didn’t help either.
I will contribute every log or command output you need to fix this.
Comment 21 Maximilian Böhm 2018-02-25 00:17:52 UTC
I absolutely want to pinpoint the wrong value but you need to help me with your tools.
Like I said, "sudo libinput measure touchpad-pressure --touch-thresholds=n:n" results in 
"libinput-measure: unrecognized option '--touch-thresholds=n:n". This feature is non-functional.
And my custom preset in /etc/udev/hwdb.d/99-touchpad-pressure.hwdb gets just ignored by libinput. Might be because of my complex DMI but I have just followed the exact instructions. Please tell me how I can successfully override LIBINPUT_ATTR_TOUCH_SIZE_RANGE.

BTW, "sudo libinput measure touchpad-pressure" does output:
"Using Trackpad von maximilian: /dev/input/event21
Error: device does not have ABS_MT_PRESSURE"
Comment 22 Mario 2018-02-25 07:39:21 UTC
I was able to make changes to the DB in order to change some parameter for the  Trackpad. I was not able to find proper params to restore the previous behavior... 

On the Magic Trackpad you can just measure the touchsize using:
$ libinput measure touch-size /dev/input/event<put your device id>

I created a file /etc/udev/hwdb.d/99-my.hwdb with content:
 LIBINPUT_ATTR_TOUCH_SIZE_RANGE=<put one number>:<put another number>

To reload the database you can use:
$ sudo udevadm hwdb --update
$ sudo udevadm trigger /sys/class/input/event<put your device id>

I still have many problems to get reliable multi-touch gestures. I got a Dell XPS 13 and, using the same gesture with almost the same pressure on the internal touchpad, I'm not able to get a consistent behavior on both devices. Libinput 1.9 was a big regression for the external touchpad (in my experience)...
Comment 23 Mario 2018-02-25 07:41:23 UTC
Last sentence was not so clear: libinput works well on the internal touchpad of my Dell XPS 13 but the external device is not able to consistently recognize the "same" gesture. On the internal touchpad libinput is perfect.
Comment 24 Peter Hutterer 2018-02-27 05:24:02 UTC
> "libinput-measure: unrecognized option '--touch-thresholds=n:n".
> This feature is non-functional.

sorry about that, this was bug 105246 that I fixed yesterday.

As for the hwdb match, the libinput:touchpad:input:b0005v05ACp030E* is the one recommended because this device can change names. You cannot measure the pressure because that device doesn't have pressure, only touch size. Having said that, this is now the same as bug 103970, no?
Comment 25 Mario 2018-02-27 06:22:43 UTC
Yes, its the same problem.
Comment 26 Daniel van Vugt 2018-02-27 07:23:15 UTC
*** Bug 103970 has been marked as a duplicate of this bug. ***
Comment 27 Daniel van Vugt 2018-02-27 07:27:49 UTC
Instead of adding:

 LIBINPUT_ATTR_TOUCH_SIZE_RANGE=<put one number>:<put another number>

I think we should fix the root cause, which is an over-general match here:

### Delete the below because the rule matches too many different touchpads ###
### Whoever owns them should re-add a new more specific rule for theirs ###

Maybe then adding LIBINPUT_ATTR_TOUCH_SIZE_RANGE would not be necessary?
Comment 28 Daniel van Vugt 2018-02-27 07:40:01 UTC
Actually, no. Let's be conservative for now. I'll prepare a patch in a sec...
Comment 29 Mario 2018-02-27 07:50:31 UTC
Daniel, what values are you going to put in the patch. I think we should test and agree on the proper values before to submit it. IMHO
Comment 30 Daniel van Vugt 2018-02-27 07:52:47 UTC
I tested your suggestion of 60:40 but found it still couldn't sense light touches with fingertips, so have dropped it to 20:10. Since 20 is about the smallest touch I can produce.
Comment 31 Daniel van Vugt 2018-02-27 08:02:52 UTC
Created attachment 137637 [details] [review]

Try this.
Comment 32 Peter Hutterer 2018-02-27 08:10:17 UTC
> is about the smallest touch I can produce.

is that a realistic touch though? We don't want to go the other way, detecting touches that are just barely skimming the surface isn't useful either. Avoiding those was the original reason for the pressure-based touch detection, a good middle ground is needed here.
Comment 33 Daniel van Vugt 2018-02-27 08:14:28 UTC
Just barely skimming the surface is still perceptible by the user as a touch. Thus if the hardware registers that as no longer touching it is an annoyance.

At the kernel level, this device correctly resets ABS_MT_TOUCH_MAJOR/MINOR to zero on release. And I think that 0 is quite far enough away from 20/10 given that 20 is a touch perceptible by the user.
Comment 34 Mario 2018-02-27 09:02:59 UTC
Daniel, I agree with Peter. Going in the direction suggested by him, do you have a different feeling using greater values like 60:40? Can you test them on a real session?
Comment 35 Peter Hutterer 2018-02-27 09:18:32 UTC
> Just barely skimming the surface is still perceptible by the user as a touch. 
> Thus if the hardware registers that as no longer touching it is an annoyance.

light touches are easy to make inadvertently, so you should have a normal contact with the touchpad surface before a touch registers.
Comment 36 Mario 2018-02-28 11:42:39 UTC
Created attachment 137686 [details] [review]
a patch using a pair of values (60:40) to fix the issue

As I don't see any kind of collaboration here..., I decided to create a personal patch using a less extreme pair of values (60:40) to fix the issue. I used it in the last two days and I can say that, for me, it restores the previous behavior of my Magic Trackpad. Clearly this is a strictly personal feeling.

The decision is up to Peter. Thanks.
Comment 37 Peter Hutterer 2018-03-01 03:31:04 UTC
Mario, please make this a signed-off git-formatted-patch, thanks. I'm gonna go with 60:40 for now, it's better to reduce the limits when we have to than to go the other way.
Comment 38 Mario 2018-03-01 10:58:29 UTC
Created attachment 137716 [details] [review]
a signoff version of the previous patch with 60:40 thresholds

I hope it is in the proper format. Thanks.
Comment 39 Peter Hutterer 2018-03-02 04:47:55 UTC
pushed, thanks. please re-open if the 60/40 is too high and we need to reduce it further.

commit f47eb2d796ef459c52394681083d0110d56b4ce3
Author: Mario Di Raimondo <>
Date:   Thu Mar 1 11:52:35 2018 +0100

    Fix Apple Magic Trackpad sensitivity
Comment 40 Daniel van Vugt 2018-03-02 10:03:50 UTC
Sorry. Just noticed I was not subscribed to this bug. Only the other bug.
Comment 41 Daniel van Vugt 2018-03-02 10:41:01 UTC
Mario, I was not ignoring the discussion. I never received the above messages. I assumed I would get an email if people had further comments about this bug, but no emails came. Turns out bugzilla does not automatically subscribe users from duplicate bugs like other bug trackers do.
Comment 42 Daniel van Vugt 2018-03-02 10:43:31 UTC
(In reply to Peter Hutterer from comment #35)

> light touches are easy to make inadvertently, so you should have a normal
> contact with the touchpad surface before a touch registers.

That is incorrect. The Apple Magic Trackpad is a standalone device usually positioned off to the side of one's keyboard, like a mouse. You have to go out of your way to touch it. It's not like a laptop touchpad.
Comment 43 Peter Hutterer 2018-03-03 05:49:34 UTC
note that we have two pressure thresholds, one for the finger, one for the palm. the former is not for palm detection but for inadvertent finger interaction. This can happen when the user moves quickly over the touchpad when resetting the finger, or when switching between two and three-finger scrolling. Or when a thumb is used for pressing on a clickpad. These are all cases that can occur on an external touchpad as well. and those are the thresholds we set with this patch.

These were also the original motivation for the finger thresholds (iirc), palm detection was independent of that.
Comment 44 Daniel van Vugt 2018-03-06 01:49:52 UTC
I feel it's trying to solve problems that don't really exist, or that the medicine might be worse than the disease... Using a macOS/Macbook recently seems to be very sensitive by default and I doubt Apple gets complaints about those.

But this bug is now fixed, which is great. If I find anything is particularly problematic in future then I will report separate bugs.
Comment 45 Maximilian Böhm 2018-04-15 01:52:09 UTC
Hello, I‘m following Peter’s appeal in comment 39 to re-open this bug of the sensitivity would be too low.
It is. ;)
I have tested 20:10 threshold and would recommend this as the new standard. A tiny bit more responsive for me without any disadvantages. The mistake heuristic of the Magic Trackpad is outstanding, don’t compare this with cheap notebook trackpads.
Comment 46 Peter Hutterer 2018-04-16 22:42:58 UTC
ftr, the sensitivity is too high, not too low :)

Daniel, can you re-spin your patch against git master please, thanks
Comment 47 Daniel van Vugt 2018-04-17 02:42:51 UTC
Just retested the Magic Trackpad after not having used it in a while. While it is quite usable now (v1.10.4), I can also confirm libinput-measure-touch-size shows events are going missing (not reported as "down" when finger is still down). So it could be better...

I have also confirmed that 20:10 solves it.

But I think that once again the palm threshold is also a problem. I was able to occasionally exceed that with a single finger. So I'll fix that too.
Comment 48 Daniel van Vugt 2018-04-17 02:50:04 UTC
Created attachment 138872 [details] [review]

A fresh patch.
Comment 49 Peter Hutterer 2018-04-17 06:52:51 UTC
> not reported as "down" when finger is still down

Are we talking about accidental releases here? Because that's better fixed by by just having a higher range, e.g. 60:10. Or are some touches not detected at all?

60:10 is "safer" than 20:10, simply because it has a higher threshold to trigger, but a equally low threshold to release, so once a finger is down, it should stay down.
Comment 50 Daniel van Vugt 2018-04-17 06:56:01 UTC
That might be true, but I'm not looking at this any more. I just tested 20:10 as was suggested.
Comment 51 Peter Hutterer 2018-04-17 07:07:40 UTC
Sigh. Maximilian, can you please test this with 60:10, thanks.
Comment 52 Daniel van Vugt 2018-04-17 07:10:29 UTC
Sorry. I'll get back to this tomorrow if it's not already done.
Comment 53 zilla 2018-04-17 07:14:03 UTC
I'd be willing to test too but I'm not quite sure how to try out the different settings. Is there a howto somewhere?

The new settings are way better than before (initial bug report vs now) but when I go back to my trackpad after some inactivity (30 seconds or so) it sometimes doesn't respond right away. Or it takes a ferw seconds to actually scroll. Sometimes it feels like I have to horizontally align my index and middle finger to make it scroll. Feels a bit weird. Sorry for the imprecise description but I don't really understand which parameters I'm talking about.
Comment 54 Daniel van Vugt 2018-04-17 07:17:46 UTC
There's really no need to be afraid of 20 as the down threshold. This is a very high quality piece of equipment with no apparent hardware jitter. It's also a peripheral designed to be placed in your periphery, so you can't touch it by accident.
Comment 55 Maximilian Böhm 2018-04-17 10:25:27 UTC
Just compared 60:20 and 20:10: Go with 20:10. Makes a noticeably difference in ‚initial thrust‘ and accuracy.
Comment 56 Daniel van Vugt 2018-04-18 03:10:24 UTC
Created attachment 138891 [details] [review]

Here's an updated patch using 60:10.

I find this works fine and can't reproduce any kind of "initial thrust" problems.
Comment 57 Maximilian Böhm 2018-04-18 11:37:01 UTC
I assure you, it makes a difference for me, with 20:10 it feels a bit more responsive – without any disadvantages, no touches by accident etc., I might be in illusion but it even feels better than before libinput 1.9. So, as long as there are no drawbacks, please change it to 20:10. And as it was said numerous times here: This is a standalone device, sitting on the side of your keyboard, you’re not hitting it by accident (and even then it does the right thing). It is featuring the iPhone touch controller which gives it the best touch processing in the industry.
Comment 58 Daniel van Vugt 2018-04-19 01:46:59 UTC
I don't mind if we go with
  attachment 138872 [details] [review]
  attachment 138891 [details] [review]

But it's not my call.
Comment 59 Peter Hutterer 2018-04-19 03:32:59 UTC
I ended up taking the 20:10 version, thanks.

commit d5b45586753079b1f7149c649919e92727bf3975
Author: Daniel van Vugt <>
Date:   Tue Apr 17 10:43:32 2018 +0800

     Improve responsiveness for Apple Magic Trackpad

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.