Skip to content

Multi-finger tap-and-drag enhancements

satrmb requested to merge satrmb/libinput:enforce-nfgtap-1fgdrag into master

Closes #570 (closed), refer to that issue for a detailed discussion of how we arrived at the changes.

Tap-and-drag is supposed to be performed with a single finger in the drag part of the interaction, which may not necessarily be the same number of fingers used in the tap part.

Tapping and dragging with the same number of fingers worked for 2fg but not 3fg because we don't support three fingers during a tap (yet?). Since there are some requested features which might conflict with that, let's avoid users getting used to something that may not stay around, and restrict dragging to one finger. However, restricting it to one finger throughout the entire drag would break finger-swapping which users may perform in long-distance drags, so the restriction only applies to the start of the drag (including a restart from drag-lock state).

This reverts most of 44912aa3, but avoids the original issue fixed in that commit in a different way - a few changed transitions in the tapping state machine.

Also included is a usability enhancement for 2fg-/3fg-tap-and-drag which I've been sitting on for too long: because changing hand shape from multi-finger tap to single-finger drag takes a little bit of extra time, elongate the timeout for starting the drag slightly in these cases. This flaw was revealed by testing with a slower user in !463 (comment 632362) and following comments.

Finally, while fixing up tests to deal with the new finger count restriction, the test suite started spewing "system is too slow" messages on my system. I changed something that looked suspicious relating to drag-lock timeout, and that shut it up, so the change is included too.

@whot, I'm a bit dubious about the test suite adjustments. The way I changed them made the test cases pass again (inserting a timeout to force us from DRAGGING_OR_DOUBLETAP into DRAGGING, or in one case a movement with the same effect for additional coverage), but some of them are doing two-finger stuff in a drag that's clearly not a finger-swap, most egregiously touchpad_multitap_n_drag_2fg. The one dealing with a palm (touchpad_tap_palm_on_drag_2fg) even raises a sort-of-valid issue (tap, then finger + palm down, but the palm doesn't immediately get detected as such -> no drag for you) - should we just give that the "too unlikely to worry about" treatment?

Merge request reports