Bug 1575260

Run sudo libinput debug-events in a terminal and reproduce the bug. Do you see the event stream stop when the cursor stops? If so, it's a libinput (or hw) bug. Re-run with --verbose to see if anything interesting happens in that case, maybe there's a spurious palm detection happening or something like that.

(In reply to Peter Hutterer from comment #1)
> Do you see the event stream stop when the cursor stops?

Yes indeed it does (stop).

> Re-run with --verbose to see if anything interesting happens in
> that case, maybe there's a spurious palm detection happening or something
> like that.

That is exactly what happens:

event6  - palm: touch size exceeded
event6  - palm: palm detected (touch size)
event6  - touch-size: end touch
event6  - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE

Run the libinput measure touch-size tool please (as root) and follow the instructions. See also https://wayland.freedesktop.org/libinput/doc/latest/touchpad_pressure.html#touchpad_touch_size_hwdb

The maximum touch-size I was able to get with a single finger was in the lower 900s and even that was a rare occurrence that I cannot reliably reproduce.

These guys here https://gist.github.com/roadrunner2/1289542a748d9a104e7baec6a92f9cd7 have been setting the palm size detection threshold to 1200 on some newer MacBook Pros.

However, for me

# cat /etc/udev/hwdb.d/99-touchpad-pressure.hwdb
libinput:name:bcm5974:dmi:*svnAppleInc.:pnMacBookPro5,5*
 LIBINPUT_ATTR_PALM_SIZE_THRESHOLD=1000

seemed to do the trick.

A match line

libinput:name:bcm5974:dmi:*:svnAppleInc.:pnMacBookPro5,5:*

with the added colons especially at the end is probably slightly safer.

rightyo, that works. Mind sending me this as git formatted patch for libinput (to the bugzilla email or the one in the libinput git logs). The line goes into 99-libinput-model-quirks.hwdb. That way I can apply it directly and you get all the fame and fortune from proper patch accreditation :)

Done. I assume you meant 90-libinput-model-quirks.hwdb

got it, thanks. I just remembered when double-checking - the apple touchpads are all USB and use product ids correctly. So it'd be better to use an modalias here, the match is going to be:

libinput:touchpad:input:b0003v05ACpXXXX*

where XXXX is the 4 digit zero-prefixed uppercase hex product id of your touchpad, see the Input Device ID line in the evemu-record output. Can you please test that and let me know what the final match line is? I'll change it locally. Based on https://bugs.freedesktop.org/show_bug.cgi?id=106489 it should be 0237

Thanks

libinput-1.10.6-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-84a230db9e

I see yeah, that's better - makes it apply to more people with similar hardware.

Tested it and the match line is as you suggest:

libinput:touchpad:input:b0003v05ACp0237*

libinput-1.10.6-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-84a230db9e

Thanks, updated and pushed to libinput git master as commit d7ff5a8f0d876b3125978fd357716ac0f5619de0

libinput-1.10.6-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.