Bug 103208

sorry, that recording doesn't start from a neutral touchpad state, I can't replay this here. Can you re-record please, starting with no fingers on the touchpad? Thanks

Created attachment 134857 [details]
evemu-record for the event (v2)

Linking to bug 95417 here because we introduced that behaviour there. There is a problem with 2fg scrolling and edge palm detection: our edge palm detection triggers when a finger is within the edge zone and either stays there or moves vertically within that zone. see this link for an illustration of the process:
http://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html

for 2-finger scrolling, the vertical motion is almost guaranteed. especially on small touchpads (but not exclusively so), having one finger in the edge zone is not that uncommon. so we purposely ignore palm edge fingers for 2-finger scrolling and treat the finger normally.

Not sure what to do here, having this as a hardware-specific exception would make this a lot harder to maintain.

With respect to bug 95417, I think that's fair to let 2fg scrolling function around the edge area. The problem I have is that anything on the edge zone becomes part of a 2fg-scrolling movement even when nothing moves on the edge zone.

I'm not a programmer, so I don't know how to fix this, but I suppose (and I may be completely wrong on this) this may not require a hardware-specific exception.

1. In a real 2fg-scrolling, both finger should move in the same direction. So if the touch input on the edge zone is stationary, it should be treated as a palm, and hence be ignored.

2. In a real 2fg-scrolling, the two fingers should be reasonably close to each other. So if, e.g., the left edge is touch while the other finger is moving aound the middle area, the input on the left edge should be treated as a palm, and hence be ignored.

3. Maybe, just maybe, there's a way to detect palm around the edges properly, so that we can do away with the edge zones altogether.

Just a few thoughts... not sure if any of the above makes any sense.

Regarding your comments above:
1) we don't actually have that requirement, you can scroll with one finger stationary which gives you finer granularity. besides, the big problem with this is that 'movement' is quite ambiguous here. palms move around a bit too and usually scrolling needs to start well before we have an idea of whether it's a palm or not

2) nontrivial and would likely only work in the extreme case where the distance is truly unreasonable. that would only work on large enough touchpads, but it's a reasonable suggestion otherwise. but we alrady have e.g. bug 99830 open because selecting on finger position isn't always a good idea either.

3) let me know if you come up with an approach :)

I have to confess that until now I have had no idea that two-finger scrolling is supposed to be triggered with only one finger moving while the other remaining stationary. Now that I know this gesture exists, I don't really like using it, because it feels somewhat unnatural. So I wonder if this feature is really necessary. Indeed, this "gesture," for the lack of a better word, doesn't work on macOS.

I also believe that macOS checks whether the two fingers move together in reasonably parallel paths. For example, if two fingers initiate the touch input from roughly the same point (say the centre of the touchpad), and then both fingers move up while at the same time further apart (say both finger moving towards the top two corners of the touchpad), macOS treats this "gesture" as pinch, i.e. zooming, instead of two-finger scrolling, as libinput does. This is probably why zooming in and out with pinch gestures feels a lot smoother and more consistent on macOS than on Linux (I guess?), but that is a problem for another time.

For now, my main point is that it makes sense, IMHO, to impose check on a) whether two fingers are moving together, and b) whether they move in reasonably parallel paths in two-finger scrolling. With those checks, I think we can have 2fg-scrolling in edge zone without its being triggered by an accidental palm.

I agree with Pater that allowing two-finger scrolls when only one finger moves doesn't make a lot of sense, and introduces a lot of bugs like these in order to detect and handle it.

I'd also like to point out that since two-finger scrolling is called "two-finger scrolling," an average end-user would most likely not expect that enabling this feature would allow them to scroll with just one finger anyway.

we've had this feature since forever, synaptics also supports it and some people prefer it that way. not something I'll remove anytime soon. You're also overestimating the precision that current touchpads give you, any slow two-finger motion is likely to only have a single finger movement in any given event. 

we do check the finger motion to differ between pinch and scroll, but macos has the advantage of only having to care about the mac touchpads which are still better than almost anything else (and they probably having more people working on it too...).

see https://cgit.freedesktop.org/wayland/libinput/tree/src/evdev-mt-touchpad-gestures.c#n361 for the checks we have to detect the directions of the finger movements.

also leaving this one here: https://bugzilla.redhat.com/show_bug.cgi?id=1246868
we had finger distance in the past, but it does not work for everyone.

Also:

	/* palm edges are 8% of the width on each side up to a max of 8mm */
	mm.x = min(8, width * 0.08);
	edges = evdev_device_mm_to_units(device, &mm);
	tp->palm.left_edge = edges.x;

	mm.x = width * 0.92;
	edges = evdev_device_mm_to_units(device, &mm);
	tp->palm.right_edge = edges.x;

	if (!tp->buttons.has_topbuttons) {
		/* top edge is 5% of the height */
		mm.y = height * 0.05;
		edges = evdev_device_mm_to_units(device, &mm);
		tp->palm.upper_edge = edges.y;

It appears that only the left edge has been changed, if I'm not mistaken.

oops... add the wrong comment meant for bug103330

However little sense the one-finger-scrolling feature makes to me, and however useless this feature is to me, I don't really mind its existence so long as it doesn't mess with palm rejection around the edges. I just don't see any obvious logic to do that without some kind of checks on the movement of both fingers.

ok, let's be clear here: comments like that are not productive. Don't belittle the features others require/expect just because they don't match your expectations or usage patterns. And don't assume that we're changing them just because your usage pattern doesn't match the current implementation. Think about how to *fix* this rather than belittling everything that you don't like.

Couple of things:

1) Just because I express my dislike of a feature doesn't mean I belittle it, or believe that no one ever uses it, or believe it's worthless. In fact, I believe I have made myself quite clear that I am fine with keeping the feature as long as we remedy the problem it causes. My key point is that I don't see any obvious logic that can accommodate absolutely *everything*, so the question will, at some point, become which feature you would rather sacrifice (see point no. 4).

2) I also want to make clear that I dislike the feature not just as a user of MacBook, which has arguably the best touchpad around, but as a user of other touchpads as well, such as the one on XPS 13, and some older touchpads on some $300 laptops from like 5 years ago. So I am not proposing these things just because I think MacBook does them, but because I've used multiple touchpads and haven't found the offending feature useful when it isn't causing problems. But if other users find that feature useful, that's fine.

3) Of course I don't expect the feature to go away just because I don't like it. I have used Linux for long enough to know that things don't work like this here (or anywhere). 

4) If not everything can be accommodated, there will come a point in the future where one will have to choose one over another. As touchpads improve, it will be the old features that will have to go if they get in the way of accommodating new features, IMHO. That's not avoidable in the long-run.

5) Now, it's not like I haven't thought about how to fix this *without* gutting the feature. Here are **two other potential ways** I've come up since the last comment:

A) ABS_MT_ORIENTATION of palm touches on the left edge should always be positive, and those on the right should always be negative because of how the hands are normally placed, no matter how large the contact areas are. Incorporating orientation data may provide an extra check to identify real palms within the edge zones, or perhaps even help do away from edge exclusion zone altogether. Orientations of fingers tend to fluctuate around the edges in my observation, but since users don't often use the edges for tracking, finger detection at the edges does not have to be 100% perfect IMHO. Granted, this will probably make two-finger scrolling (and one-finger-moving-one-finger-stationary-scrolling) around the edges less consistent than in the middle of the touchpad. We can test and debate whether this decrease in consistency is worth it.

B) Call the one-finger-moving-one-finger-stationary-scrolling something else altogether, because it's not *really* two-finger scrolling. For now, let's call it Legacy Mode. Then create a new two-finger scrolling (or Experimental Mode for now) with new checks, so that end users can actually *test* and help refine the extra checks, and, if they don't like them, revert back to the Legacy Mode.

Created attachment 135393 [details]
evemu-records of single palm touching the area around the left edge

Created attachment 135394 [details]
evemu-records of single finger touching the area around the left edge

I want to expand a bit on the idea of using orientation to distinguish between a palm and a finger around the edges. I've uploaded two evemu-records. One of which is the recording of my left palm moving along the left edge and sideway within probably 1 or 2 cm from the left edge. The second is the recording of the same movements, but with one single finger.

By my count (not sure if iI've counted correctly), when a palm touches the left edge, orientation is a positive number about 96% of the time. In my observation, orientation on the left edge is correct (i.e. positive) even when the contact point is very small and way before touch-size-based palm detection can kick in.

When a finger touches the edge area, the result is less consistent. By my count, around 70% of time the orientation is not positive (i.e. either zero, negative, or nothing).

Given touch-size-based palm detection is not possible around the edges, orientation may be helpful, even if not 100% reliable (mostly, a single finger would be falsely identified as a palm; a palm falsely identified as a finger is much less of a problem). Since most real touch inputs aren't initiated within, say, 3mm from the edge anyway, perhaps orientation-based palm detection doesn't have to be 100% accurate. If this could work good enough, perhaps tapping and tracking could be enabled within the edge exclusion zone.

One of the downsides of it, other than being not 100% reliable, especially with single finger input, is that if one of the fingers in two-finger scrolling is placed within the zone where orientation-based palm detection is enabled, initiating two-finger scrolling will become less reliable too.

I'm also not sure if those measures are good in other touchpads.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/libinput/libinput/issues/9.