mbp-2016-linux Tricks for better usage of the touchpad

As I want to mimic the same touchpad experience as on macos there probably are a lot of tricks to do so.

What I found so far (I'm under Gnome on Wayland) is that you need to go to the Tweaks section, then Keyboard and Mouse and change the Touchpad click method to fingers.

I haven't solved the occasional "jumps" of the trackpad. I built from source the latest libinput (1.7) but the palm rejection is still not functioning as well as I'd wanted.

Anyone has some tricks/suggestions?

@Dunedan I didn't know any other location to start this issue.

Apr 27 '17 05:04 tudorbarascu

Absolutely fine to use issues here for such topics. :+1: This repo is all about Linux on the recent Macs so all discussion about it is welcome, even though some things might be to distribution-/application-specific to include them in the README.

Apr 27 '17 16:04 Dunedan

As far as I know, libinput's palm rejection only works if you touch the touchpad on the sides of the touchpad. Obviously that works for smaller touchpads, but not those on MacBooks.

I see some work has been done in this branch of libinput on palm detection based on touch-sizes, but the branch seems a bit stale at the moment.

Jun 30 '17 07:06 peterychuang

I can imagine @whot would appreciate if somebody would try it out on one of the recent mobile Macs.

There is also a patch-set on wayland-devel regarding touch size detection for Apple devices, which seems to lack real world tests (https://lists.freedesktop.org/archives/wayland-devel/2017-March/033593.html). @roadrunner2: Maybe interesting for you? I don't know if that somehow relates to your collection of touchpad ranges for hwdb.

Jun 30 '17 16:06 Dunedan

In here, it says:

major/minor is largely useless on anything but the Apples and even there we need hwdb-specific entries (which this patch doesn't have). Right now, this series is only useful on the magic trackpad, the only device it's been tested on.

Whatever that means, the patchset won't work on current MacBook Pro.

He's mentioned hwdb though. Perhaps that's what @roadrunner2 is working on?

Jul 01 '17 05:07 peterychuang

the apple touch hardware is quite similar, it may work on the MBP, I just don't know. The hwdb entry comment just means we need a LIBINPUT_ATTR_TOUCH_SIZE where this can be set for each device rather than the patchset's hardcoded one. A fairly simple addition, but you can even try to just get the patchset working with the magic numbers adjusted for your hw. moving that to a hwdb will take me less than 30min.

Jul 01 '17 05:07 whot

Hi @whot, sorry for the misunderstanding.

I've built libinput with those patches, though I'm not sure how exactly to make it work.

Jul 01 '17 09:07 peterychuang

@peterychuang I've rebased the branch, it's available on https://github.com/whot/libinput/tree/wip/touchpad-apple-touch-major. The interesting commit for you would be "touchpad: add touch-size based touch handling", specifically the tp_init_touch_size() function. The low/high thresholds are the numbers to tweak.

Since that patchset I found that the values the touchpad provides aren't in mm, so that code needs to be changed, but for now you can just change those numbers around to test. Likewise, the "touchpad: add touch-size-based palm detection" commit has a hardcoded 17mm in tp_init_palmdetect_edge(), that's the other number to tweak for palm detection.

Jul 03 '17 06:07 whot

@whot thanks very much. I've tested it for a bit, but it doesn't seem to make much difference.

I'm wondering if the fact that the touchpad's running on an out-of-tree driver (see this and this) is the reason for the apparent lack of touch-size based palm rejection.

Jul 03 '17 11:07 peterychuang

After some trial-and-errors, I've managed to make both touch-size based palm rejection and disable-while-typing work, sort of. Since I'm not really familiar with C, I suspect what I've done is probably wrong, even though it seems to work.

https://github.com/peterychuang/libinput/tree/wip/touchpad-apple-touch-major

Comments welcome.

Jul 04 '17 17:07 peterychuang

@peterychuang I left a few comments in those patches, bottom line is that I think you don't need anything but two hwdb entries. I'd like to merge the test additions but tbh only if they represent the upstream kernel, handling out-of-tree drivers in the test suite will lead to combinatorial explosion.

Jul 05 '17 05:07 whot

@whot thanks very much for your comments, and I apologise for the mistakes I've made, as I'm pretty beginner in this.

I agree that this may be problematic with the out-of-tree driver. I'm not sure if @cb22 and/or @roadrunner2 are working on mainlining the driver?

Jul 05 '17 05:07 peterychuang

@peterychuang, @whot: work is being done right now to get some core acpi support mainlined, and I think the aim is definitely to get this module get mainlined in the not too distant future.

Jul 05 '17 06:07 roadrunner2

@whot I've reduced the patch to include basically just two new hwdb entries. I'm also experimenting with different thresholds.

I'll perhaps add back the test stuff after the driver is mainlined.

https://github.com/peterychuang/libinput/tree/wip/touchpad-apple-touch-major-v2

Jul 06 '17 11:07 peterychuang

@peterychuang I just pushed a new branch to https://github.com/whot/latest/tree/wip/touchpad-apple-touch-major-v2, it's almost the same bits but with the mm conversion removed so now it's all in device units. It includes a new tool now too to measure those units which makes life a lot easier for you :)

sorry I had been working on this for two days now and creatively enough I decided to give it the same branch name :)

Jul 07 '17 10:07 whot

@whot thanks very much, the new tool has been helpful.

I've force-pushed my new changes to the same branch, and I've been using it for a few days now. So far this has been working fine, but more tests from others will be appreciated.

One issue I have is that when I release my palm very slowly, sometimes the touchpad fails to response on the first subsequent finger-contact, and I have to touch it one more time before the cursor can move. I notice that when that happens, even evemu-record freezes a bit, and the libinput measure touchsize gets stuck above the threshold I set in the hwdb file. I'm not sure where the problem actually lies. Fortunately the problem doesn't happen too often in real-world usage.

Jul 10 '17 16:07 peterychuang

@peterychuang I'm gonna say that if evemu freezes the issue is going to be in the kernel. evemu prints the events that libinput sees too, so if it has nothing to print, libinput has nothing to process.

The two patches you have in the tree on top look good to me, please send these to [email protected] when the driver is mainlined. But if you're happy with other patches, I'll get those upstream (also for more exposure). Thanks for testing.

Jul 11 '17 02:07 whot

@whot I have a few problems/suggestions.

First, I wonder if palm rejection by edge exclusion zone is still necessary when touch-size-based palm rejection is available, or at least it will be much nicer if its behaviour is consistent with touch-size-based palm rejection. Right now, if something (palm or finger) touches the edge zone while a finger moves in the middle of the touchpad, this combination triggers scrolling instead of cursor movement for some reason; while the combination of a touch-size-based rejected palm input outside of the edge area and a single-finger movement triggers cursor movement. IMHO it makes better sense to have both cases triggering cursor movement.

Second, when a palm is rested on the touchpad, tappings (both one- and two-finger tappings) on the rest of the touchpad trigger some erratice responses at times: one-finger tap sometimes (but not 100% of the time) triggers responses that resemble right-click (or a normal two-finger tap when there's nothing else on the touchpad), and two-finger tap sometimes (but not always) behaves like three-finger tap.

Third, I wonder if there's a way to reject click inputs from a palm. Right now, libinput is doing a nice job in ignoring palm movement across the surface of the touchpad. However, if a palm is pressed on the touchpad hard enough, there are still ocassions when it's registered as click.

Thanks very much again for your help.

Aug 07 '17 10:08 peterychuang

sorry, was at a conference/on holidays @peterychuang: touch size at the edge is unreliable because the finger is likely to hang over the side and not give us the right touch size. the edges are still needed.

Right now, if something (palm or finger) touches the edge zone while a finger moves in the middle of the touchpad, this combination triggers scrolling instead of cursor movement for some reason;

Related to https://bugs.freedesktop.org/show_bug.cgi?id=99703, but yeah, the behaviour should be the same for both methods. Please file a bug for that.

tappings (both one- and two-finger tappings) on the rest of the touchpad trigger some erratice responses at times

Not something I can comment on much, I'll need a bug report with evemu-recordings for each busted event sequence. I do wonder though why you have a palm on the touchpad while tapping, one of the assumptions we've taken so far is that the palm is removed before real interaction and the whole palm detection thing is largely one to stop interfering with keyboard usage.

I wonder if there's a way to reject click inputs from a palm.

tbh, I don't have any plans for this atm. Except for the Lenovo T440 series, the resistance of the touchpads is usually enough that clicks aren't fully accidental and can be avoided. So we've basically always gone with the "a click is intentional". I'd be surprised if the new apple touchpads are that sensitive to really reconsider that. How much pressure do you need to trigger the click?

Aug 17 '17 02:08 whot

Thanks @whot, hope you've had a nice vacation!

touch size at the edge is unreliable because the finger is likely to hang over the side and not give us the right touch size. the edges are still needed.

After trying to disable the edge exclusion myself, I agree it's still necessary to have that feature, though perhaps it doesn't have to be 8% on both sides and top of the touchpad, as the touchpads on the current MacBook Pros (and 12-inch MacBook too? not sure) are pretty massive. The 13-inch model, which I have, has a touchpad measuring 135mm x 83mm, so 8% on the sides is more than 1cm. A lot of legitimate finger touch inputs are rejected with a exclusion zone this wide IMO.

Related to https://bugs.freedesktop.org/show_bug.cgi?id=99703, but yeah, the behaviour should be the same for both methods. Please file a bug for that.

Will do

Not something I can comment on much, I'll need a bug report with evemu-recordings for each busted event sequence. I do wonder though why you have a palm on the touchpad while tapping, one of the assumptions we've taken so far is that the palm is removed before real interaction and the whole palm detection thing is largely one to stop interfering with keyboard usage.

Again, this is because the touchpad is pretty massive. Here's a picture of my left hand casually placed on the laptop. As you can see, it is quite impossible for a hand to not touch at least a small part of the touchpad unless the hand is placed way out to the side or hovering above. At the same time, even with part of the touchpad covered the left hand, the remaining area of the touchpad remains large enough that one should expect to be able to still use the touchpad normally. I have removed macOS entirely from my machine, so I can't confirm it right now, but I remember it's entirely possible to use the touchpad normally with one hand while another hand is on the touchpad.

Let me know specifically what logs you may need to look into this (the raw evemu-record may seem a bit too noisy?), and I'll file a bug on this.

tbh, I don't have any plans for this atm. Except for the Lenovo T440 series, the resistance of the touchpads is usually enough that clicks aren't fully accidental and can be avoided. So we've basically always gone with the "a click is intentional". I'd be surprised if the new apple touchpads are that sensitive to really reconsider that. How much pressure do you need to trigger the click?

I think this one is tricky implement. I suspect because it's a force touch touchpad, whether it interprets a touch as a click (and gives haptic feedback) or not doesn't appear to be a simple function of the pressure exerted on the touchpad. For example, I can put my palm on the touchpad slowly but press really hard without trigger a click, but if I lift my palm and then drop my hand from, say, 1cm away from the touchpad, and only press lightly, then immediately withdraw my palm, it registers that touch input as a legitimate click, and this is quite easily triggered by accident. And if tap-to-click is enabled, it complicates things even further...

Aug 17 '17 09:08 peterychuang

On Thu, Aug 17, 2017 at 02:07:05AM -0700, Peter Y. Chuang wrote:

Thanks @whot, hope you've had a nice vacation!

touch size at the edge is unreliable because the finger is likely to hang over the side and not give us the right touch size. the edges are still needed.

After trying to disable the edge exclusion myself, I agree it's still necessary to have that feature, though perhaps it doesn't have to be 8% on both sides and top of the touchpad, as the touchpads on the current MacBook Pros (and 12-inch MacBook too? not sure) are pretty massive. The 13-inch model, which I have, has a touchpad measuring 135mm x 83mm, so 8% on the sides is more than 1cm. A lot of legitimate finger touch inputs are rejected with a exclusion zone this wide IMO.

yeah, agree. that's a leftover that has never been really changed - percentages aren't in vogue anymore :) feel free to change this to a fixed size - on most of the touchpads tested the 8% map to 8mm anyway.

coincidentally: is the touchpad size reported correctly for those devices? libinput list-devices should show the touchpad size, run the touchpad-edge-detector tool if it's not correct to within a mm or two.

Not something I can comment on much, I'll need a bug report with evemu-recordings for each busted event sequence. I do wonder though why you have a palm on the touchpad while tapping, one of the assumptions we've taken so far is that the palm is removed before real interaction and the whole palm detection thing is largely one to stop interfering with keyboard usage.

Again, this is because the touchpad is pretty massive. Here's a picture of my left hand casually placed on the laptop. As you can see, it is quite impossible for a hand to not touch at least a small part of the touchpad unless the hand is placed way out to the side or hovering above. At the same time, even with part of the touchpad covered the left hand, the remaining area of the touchpad remains large enough that one should expect to be able to still use the touchpad normally. I have removed macOS entirely from my machine, so I can't confirm it right now, but I remember it's entirely possible to use the touchpad normally with one hand while another hand is on the touchpad.

hmm. I'm going to formally scratch my head and put this into the "maybe" basket for now :) I'm still working off my todo list from the holidays but at some point you'll need to file a bug for this so it's tracked somewhere more reliable than my inbox.

Coincidentally, if the palm is tracked, it should be ignored for most interactions, so this should hopefully not be a massive issue to fix.

Let me know specifically what logs you may need to look into this (the raw evemu-record may seem a bit too noisy?), and I'll file a bug on this.

the raw record is actually exactly what I need because it enables me to replay it locally and have a look at what libinput sees, etc. Just keep the recording short enough please so there are only events in there that somewhat relate to the sequence.

tbh, I don't have any plans for this atm. Except for the Lenovo T440 series, the resistance of the touchpads is usually enough that clicks aren't fully accidental and can be avoided. So we've basically always gone with the "a click is intentional". I'd be surprised if the new apple touchpads are that sensitive to really reconsider that. How much pressure do you need to trigger the click?

I think this one is tricky implement. I suspect because it's a force touch touchpad, whether it interprets a touch as a click (and gives haptic feedback) or not doesn't appear to be a simple function of the pressure exerted on the touchpad. For example, I can put my palm on the touchpad slowly but press really hard without trigger a click, but if I lift my palm and then drop my hand from, say, 1cm away from the touchpad, and only press lightly, then immediately withdraw my palm, it registers that touch input as a legitimate click, and this is quite easily triggered by accident. And if tap-to-click is enabled, it complicates things even further...

two things I can think of here:

it's likely touch size based. once the palm is detected, the pressure is ignored and doesn't trigger a click. that's quite easy to handle. on a quick tap-click, the palm detection never triggers and it's interpreted as large finger - large fingers are considered high pressure and there you have the click. that's quite similar to the issues we've seen with palm detection. Happy to hear they have the same problems ;)
if the click + tap is an issue, it may be worth combining the two and forcing clickfinger with tapping. Not 100% sure but if we can (partially) combine the two we might be able to filter those accidental clicks out. That's going to be tricky though for me without a device

Cheers, Peter

Aug 18 '17 00:08 whot

@peterychuang Any updates regarding this topic?

Nov 19 '17 12:11 Dunedan

A few bug reports have been filed, and some works are being done (thanks @whot). See this, this, and this (they are not MacBook-specific bugs necessarily, so I guess solving them will benefit users of other touchpads as well).

At the moment, tracking, tapping, and two-finger scrolling should all work properly when touch-size-based palm rejection is triggered, meaning you can place one palm on the touchpad (but not within the edge exclusion zone, as described below) and use the rest of the touchpad pretty much normally as though the palm isn't there. Those changes now live in this branch, pending to be merged to git master.

In addition, since libinput 1.9.1, the size of edge exclusion zone is limited to 8mm. I personally think that 8mm still feels a bit too large, but I'm not sure what can be done to make it smaller, or better still, completely eliminating it. I compile my own version of libinput to limit the width of the zone to 3mm, and that seems sufficient to me.

I guess the most intractable problem at the moment is related to two-finger scrolling and edge exclusion zone. Currently, two-finger scrolling can be triggered with one finger moving while the second finger remains stationary. Given there's no reliable way (yet) to distinguish between a finger and a palm around the edges (because touch size measurements aren't accurate around the edges), anything that touches the edge exclusion zone is treated as a finger in the context of two-finger scrolling. As a result, single-finger movement is mistaken for two-finger scrolling when the edge zone is touched. If one-finger-moving-one-finger-stationary scrolling behaviour must be preserved, there's no obvious way yet to prevent this problem unless there's a way to distinguish between a finger and a palm around the edges; and if there's a way to do so, perhaps the edge exclusion zone can be eliminated... I hope.

The final major problem, in my own usage, is that disable-while-typing isn't 100% reliable. There isn't any bug report for that yet, since I haven't got any idea how the problem is triggered at the moment (see this comment).

Nov 19 '17 13:11 peterychuang

Random small input here from someone who was “forced” to switch back to macOS: yes, you can still use the pad normally while a palm is on the other side of it. So, reasonable feature to bring over. Thanks.

Nov 20 '17 09:11 puellanivis

The change to allow normal usage of the touchpad (i.e. tapping) when touch-size-based palm rejection is trigger has been merged.

Nov 20 '17 13:11 peterychuang

Thanks @peterychuang and @whot for all the work you're doing on the touchpad-front. :+1:

Nov 20 '17 20:11 Dunedan

I've stumbled across a little problem in relation to thumb rejection, in that when thumb rejection is active, tapping produces somewhat inconsistent behaviours, as documented in this bug report. Unfortunately, @whot has been unable to replay/reproduce the behaviour, and I can confirm that the behaviour can't be replayed on my non-Apple machine with evemu-play, so we are having a little trouble in figuring out the exact problem.

I am not sure what it is. Could this be a driver issue?

Nov 30 '17 13:11 peterychuang

I don't think it's a driver issue because what comes out of the kernel is driver-agnostic. And uinput (via evemu) replays it identically, so libinput should not see any difference between the two event streams. So the only thing I can think of is that it's a timing issue - we can't reproduce the event timing 100% exact because the kernel gets in the way. But that has never been that much of an issue in the past.

Nov 30 '17 22:11 whot

hm... any thoughts? @roadrunner2

Dec 02 '17 06:12 peterychuang

Two-finger clicks and three-finger clicks register and a button1 click for me. Did anyone run into this issue?

I'm using this SPI driver. I tried both with and without BlueDragonX/xf86-input-mtrack.

Mar 10 '18 02:03 WhyNotHugo

@WhyNotHugo I've filed some bugs to libinput in relation to clickfinger (see 1, 2, 3), but I believe all of them are in the context of when palm rejection or thumb rejection is active. If your problem happens without your palm or thumb anywhere near the touchpad, then I don't think I've run into the issue you are having.

Mar 10 '18 03:03 peterychuang

Huh, looks like xf86-input-mtrack wasn't picking up, and I'm just using libinput.

This seems to have fixed my clicking:

Section "InputClass"
    Identifier "touchpad"
    Driver "libinput"
    MatchIsTouchpad "on"

    Option "Tapping" "off"
    Option "NaturalScrolling" "true"
    Option "ClickMethod" "clickfinger"
    Option "AccelProfile" "flat"
EndSection

ClickMethod the important bit here. It seems that, without this setting, tapping the bottom-right corner does a right-click (like some very old trackpads used to do). It worked sometimes when my palm was down merely because my palm was touching that corner. :stuck_out_tongue:

I am noticing that the touchpad is not very sensitive in terms of distance -- I need to scroll a lot in order to get the cursor from one edge to the other. Is this somehow configurable? I tried maxing the acceleration, but:

Acceleration isn't the same as speed.
Even at the maximum, it's still not really enough.

Edit: I've managed to tweak mouse speed by using:

xinput --set-prop "Apple SPI Touchpad" "Coordinate Transformation Matrix" 5 0 0 0 5 0 0 0 1

Set 5 to any value that works best for you.

Mar 10 '18 13:03 WhyNotHugo

Apple devices should have the clickfinger method enabled but iirc this device still set pid/vid to 0, so we can't auto-detect it. The acceleration is https://bugs.freedesktop.org/show_bug.cgi?id=101139. If you have a hidpi screen, your compositor needs support for acceleration too (mutter does, nothing else afaikt). Judging by your matrix hack, that's the case here.

Mar 12 '18 04:03 whot

mbp-2016-linux mbp-2016-linux copied to clipboard

Tricks for better usage of the touchpad

mbp-2016-linux
mbp-2016-linux copied to clipboard