[AxxzyWasTaken]

Palm rejection for the M4 Max (T6041, tested on J616C) built-in trackpad. A palm resting on or landing on the pad no longer moves the pointer. Fingers and thumbs work as before.

The first commit is LiamRay11's J700 palm rejection from fix/j700-palm-rejection. It has no PR of its own yet and the second commit builds on it, so it's included unchanged.

How it works on T6041

The J616C trackpad sends the standard MTP report (ID 0x75, 38-byte header, 30-byte records), not the J700's C1FE layout. Its records carry the same per-contact bytes, though: contact ID and state in the first word, and the controller's own class in the low byte of the second (1 thumb, 2/3 finger, 6+ palm). Values recorded from HID debugfs on a J616C:

contact	class	tool area
moving finger	2 (3 rarely)	830-1010
resting thumb	1	~1750
resting palm	7	~2040
palm dragged across the pad	6/7/8	up to 5100

A palm's class flickers while the hand lands, so a contact is reported as MT_TOOL_PALM once:

• the controller classes it as a palm (>= 6) and its tool area is above 1400, which no finger reached, or
• its tool area passes 2200.

It then stays a palm until it lifts. Thumbs stay touches, so thumb clicks keep working. This is enabled with of_machine_is_compatible("apple,t6041"), since the class byte is only verified there. The T6040 is likely the same controller but is untested.

Userspace

libinput's Apple MTP entry treats a touch size above 1600 as a palm. On this trackpad, a resting palm only reaches ~1060, so that rule never fired for palms. As with the J700, distros should pair this with a quirk that turns size-based palm detection off:

[Apple MacBook Pro J616C Touchpad]
MatchUdevType=touchpad
MatchName=Apple*MTP*
MatchVendor=0x05AC
MatchDeviceTree=*j616c*
AttrPalmSizeThreshold=0

Testing

On a J616C running 7.2.10 with the quirk: resting palms while typing don't move the pointer or click, and pointer motion, two-finger scroll, clickfinger right-click and thumb clicks work as before. Built warning-free on integration/aurora (23827fe).

[RyanTheTide]

Reviewed for the M4 merge train. The T6041 commit looks reasonable, and it is gated on apple,t6041. Two things stop it from merging as is:

• The first commit is LiamRay11's J700 palm rejection, which changes the Neo's trackpad. That needs its own PR, with its own review and a Neo test. Can you rebase this onto the J700 change once it has a PR, or split the shared refactor out so the T6041 commit stands alone?
• We have no M4 Max here. Before a merge, please say which kernel and branch the J616C results were measured on, and confirm the T6040 (J616s) path is untouched. The of_machine_is_compatible("apple,t6041") gate suggests it is.

[AxxzyWasTaken]

Thanks. Both done:

• Split: the J700 commit is gone. The T6041 change now stands alone on integration/aurora 67c64c8. It brings its own contact-ID helper and gives report_finger_data() a tool argument, which the existing J314 path passes as MT_TOOL_FINGER. The C1FE path is untouched.
• Kernel: measured on our 7.2.10 J616C tree (7.2.10-j616c-b25, aurora-silicon/linux based), where the earlier version of this change sat on the J700 commit. It's been in daily use there since 30 Oct. This standalone version is the same logic, compile-tested with W=1 on 67c64c8.
• J616s: mtp_palms is set only when the root is apple,t6041 and the trackpad isn't the J700 C1FE one. A J616s (root apple,t6040) keeps it false, so its reports, axis ranges and tool types don't change.

[RyanTheTide]

Merge train (MTL, 06/11). Gates passed on test tree 0412501 (integration/aurora 2661d71 + this batch):

• Signed-off-by from the author on every commit. Adversarial review done.
• W=1 on the touched objects: 0 new warnings. KUnit: drm/apple 112/113 (1 skip), hid 19/19, SEP 158/163 (the 4 known apple_sep_host_store failures, profile tests all pass). dt_binding_check clean. apple-dcp host selftests 86/86, run-host-tests at base parity (with Merge train: G17 hang confinement (#928) plus its host-test fixture #989's fixture).
• Regression boots of 7.3.0-aurora-mtl1106a, compared with the fleet16/fleet17 rows: M2, M1 Pro, J700 and J616s all clean (0 err-level lines, 0 AVCs, displays, Wi-Fi, BT, Touch ID, camera, speakers at minimal volume with speakerguardd, s2idle, perf at parity).
• T6041-only paths: we have no J616C, so the gate is review plus your J616C evidence and regression boots of the other Macs (no change on T6040/T8140/T600x/T8112).