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
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.
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.
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...).
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)
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.
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.
Created attachment 135402 [details] libinput-debug-events.1.8.4.log
Created attachment 135403 [details] libinput-debug-events.1.9.log
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.
you need python3-evdev for the tool, should be in your package repository
ping?
@Peter Do you need further information by me? Do you think that my case is related to the wrong touch size?
Most likely it is, but I can't say for sure without the measurement data, sorry.
@Peter what further data do you need by me?
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
@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.
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: https://wayland.freedesktop.org/libinput/doc/latest/faq.html#faq_hwdb_changes
a month in needinfo, closing. please re-open when the required data has been supplied
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.
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.:* LIBINPUT_ATTR_PRESSURE_RANGE=100:100 - 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: LIBINPUT_ATTR_TOUCH_SIZE_RANGE=150:130 A relogin didn’t help either. I will contribute every log or command output you need to fix this.
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"
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:touchpad:input:b0005v05ACp030E* 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)...
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.
> "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?
Yes, its the same problem.
*** Bug 103970 has been marked as a duplicate of this bug. ***
Instead of adding: libinput:touchpad:input:b0005v05ACp030E* 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: libinput:touchpad:input:b0003v05ACp* libinput:touchpad:input:b0005v05ACp* LIBINPUT_MODEL_APPLE_TOUCHPAD=1 ### Delete the below because the rule matches too many different touchpads ### LIBINPUT_ATTR_SIZE_HINT=104x75 LIBINPUT_ATTR_TOUCH_SIZE_RANGE=150:130 LIBINPUT_ATTR_PALM_SIZE_THRESHOLD=800 ### 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?
Actually, no. Let's be conservative for now. I'll prepare a patch in a sec...
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
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.
Created attachment 137637 [details] [review] 0001-Fix-Apple-Magic-Trackpad-sensitivity.patch Try this.
> 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.
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.
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?
> 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.
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.
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.
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.
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
Sorry. Just noticed I was not subscribed to this bug. Only the other bug.
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.
(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.
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.
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.
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.
ftr, the sensitivity is too high, not too low :) Daniel, can you re-spin your patch against git master please, thanks
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.
Created attachment 138872 [details] [review] fix-Apple-Magic-Trackpad-20180417.patch A fresh patch.
> 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.
That might be true, but I'm not looking at this any more. I just tested 20:10 as was suggested.
Sigh. Maximilian, can you please test this with 60:10, thanks.
Sorry. I'll get back to this tomorrow if it's not already done.
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.
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.
Just compared 60:20 and 20:10: Go with 20:10. Makes a noticeably difference in ‚initial thrust‘ and accuracy.
Created attachment 138891 [details] [review] fix-Apple-Magic-Trackpad-20180418.patch Here's an updated patch using 60:10. I find this works fine and can't reproduce any kind of "initial thrust" problems.
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.
I don't mind if we go with attachment 138872 [details] [review] or attachment 138891 [details] [review] But it's not my call.
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.