Bug 94911

which click method do you have enabled? software buttons? if so, that's a feature to avoid movement within the software buttons.

xinput list-props should tell us

I use multifinger, it's the default.

I also notice the same freeze when slowly moving from left or right edges towards the center. Starting from the top does not cause the freeze.

attach the output of xinput list <device name> please (under X, obviously :) and the evemu-record from such a sequence. For the left/right edge movement, if it's slow enough I suspect that may be palm detection kicking in.

https://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html

Created attachment 122918 [details]
From bottom edge

Created attachment 122919 [details]
From left edge

Created attachment 122920 [details]
From right edge

This is xinput list-props:

Device 'bcm5974':
	Device Enabled (138):	1
	Coordinate Transformation Matrix (140):	1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
	libinput Tapping Enabled (274):	0
	libinput Tapping Enabled Default (275):	0
	libinput Tapping Drag Enabled (276):	1
	libinput Tapping Drag Enabled Default (277):	1
	libinput Tapping Drag Lock Enabled (278):	0
	libinput Tapping Drag Lock Enabled Default (279):	0
	libinput Accel Speed (280):	-0.565919
	libinput Accel Speed Default (281):	0.000000
	libinput Natural Scrolling Enabled (282):	1
	libinput Natural Scrolling Enabled Default (283):	0
	libinput Send Events Modes Available (258):	1, 1
	libinput Send Events Mode Enabled (259):	0, 0
	libinput Send Events Mode Enabled Default (260):	0, 0
	libinput Left Handed Enabled (284):	0
	libinput Left Handed Enabled Default (285):	0
	libinput Scroll Methods Available (286):	1, 1, 0
	libinput Scroll Method Enabled (287):	1, 0, 0
	libinput Scroll Method Enabled Default (288):	1, 0, 0
	libinput Click Methods Available (289):	1, 1
	libinput Click Method Enabled (290):	0, 1
	libinput Click Method Enabled Default (291):	0, 1
	libinput Disable While Typing Enabled (292):	1
	libinput Disable While Typing Enabled Default (293):	1
	Device Node (261):	"/dev/input/event9"
	Device Product ID (262):	1452, 585
	libinput Drag Lock Buttons (294):	<no items>
	libinput Horizonal Scroll Enabled (263):	1

ok, easy explanation: look at the thumb detection section here:
https://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html

a slow move from the far bottom triggers the thumb. the two sections are 8mm and 15mm off the bottom edge. And the left/right edge is the palm detection kicking in, also explained on that page.

I see, thank you for the feedback.
Is it possible to change this behavior, or make it configurable? Thumb detection is particularly annoying because older MacBook's touchpad are built in such a way that the bottom part is the easiest to click on, so that's where the finger would be most of the time.
Also this is inconsistent with what happens on OSX, where there is no thumb or palm detection.

the mac touchpads are still the best ones, so I think the best solution would be to analyse the touch output and tune it for those. libinput has the ability to use device-specific palm/thumb detections but we mainly focus on the lenovos because that's what we have good access too.

I suggest that you looks at the evemu recordings and try to make sense of them, find some patterns on how to identify thumbs and palms and then we can see how we codify those.

fwiw, I don't have time to work on this right now, I'll rely on you to look at the recordings and see if you can spot some pattern.

a script to print a 3d graph of pressure values on a touchpad recording is here:
https://github.com/whot/input-data-analysis/blob/master/touch-pressure/touch-pressure.py

run it against a long-term touchpad data recording and it should show you the various pressure values in a mesh graph. Not perfect, but good enough to recognise the interesting ranges.

needinfo for too long, closing, sorry. Please re-open when you have time to contribute the requested information.