Multi-finger tapping broken

Daniel Newman wrote:
> [snip]
> Two and three finger tapping ceased working. Tried changing xorg.conf,
> adjusting MaxTapTime, FingerHigh and FingerLow, but was unable to get
> multi-finger tap working again.

Please try
http://launchpadlibrarian.net/17574591/xserver-xorg-input-synaptics_0.15.2-0ubuntu1%2Bwgrant1_i386.deb.

You may also need to run:

xinput set-int-prop "SynPS/2 Synaptics TouchPad" "Synaptics Tap Move" 32 200

--
William Grant

It worked, using my original xorg.conf settings, and it didn't need the
xinput command

Thanks for your help

Commit 9f0da9b3144a2561f6e555e6f08e15643cfda830 ("Disentangle two-finger tap and two-finger scrolling") breaks multi-finger tapping in many circumstances, it seems. We should talk to upstream about reverting this.

Please try the latest version in the archive, it reverted the change of MaxTapMove back to 220.

Huh, works for me with the new default, even though it didn't seem to work completely setting it through xinput.

That's.. interesting. Anyway, this bug can be closed now, yay.

on 23/09/08 21:03 Timo Aaltonen said the following:
> Please try the latest version in the archive, it reverted the change of
> MaxTapMove back to 220.
>
> ** Changed in: xserver-xorg-input-synaptics (Ubuntu)
> Status: Triaged => Incomplete
>
>
with version xserver-xorg-input-synaptics_0.15.2-0ubuntu2_i386.deb,
two-finger tapping is not working for me.

I'm using:

        Option "FingerLow" "25"
        Option "FingerHigh" "30"
        Option "MaxTapTime" "180"
        Option "MaxTapMove" "0"
        Option "MaxDoubleTapTime" "180"

With these settings version
xserver-xorg-input-synaptics_0.15.2-0ubuntu1+wgrant1_i386.deb
was working fine.

still broken for me in version 0.15.2-0ubuntu4

vertical scrolling works, multi-finger tapping doesn't.

Does 'xinput set-int-prop 3 "Synaptics Tap Move" 32 1000' make it any better? It's probably not so much an issue with the new logic as an issue with our tapping styles.

on 13/10/08 21:51 William Grant said the following:
> Does 'xinput set-int-prop 3 "Synaptics Tap Move" 32 1000' make it any
> better? It's probably not so much an issue with the new logic as an
> issue with our tapping styles.
>
>
Thanks for this suggestion. After that input, it responds to two and
three finger taps in the correct way, although it seems a bit more
sensitive to exactly how the tap is performed than was previously the
case. My current settings are:

xinput list-props 3
Device 'Synaptics Touchpad':
    Device Enabled: 0
    Synaptics Edges: 0, 1070, 0, 310
    Synaptics Finger: 10, 20, 256
    Synaptics Tap Time: 180
    Synaptics Tap Move: 0
    Synaptics Tap Durations: 180, 180, 100
    Synaptics Tap FastTap: 0
    Synaptics Middle Button Timeout: 75
    Synaptics Two-Finger Pressure: 257
    Synaptics Scrolling Distance: 20, 50
    Synaptics Edge Scrolling: 1, 1, 0
    Synaptics Two-Finger Scrolling: 0, 0
    Synaptics Edge Motion Pressure: 30, 160
    Synaptics Edge Motion Speed: 1, 121
    Synaptics Edge Motion Always: 0
    Synaptics Button Scrolling: 1, 1
    Synaptics Button Scrolling Repeat: 1, 1
    Synaptics Button Scrolling Time: 100
    Synaptics Off: 0
    Synaptics Guestmouse Off: 0
    Synaptics Locked Drags: 0
    Synaptics Locked Drags Timeout: 5000
    Synaptics Tap Action: 0, 0, 0, 0, 0, 2, 3
    Synaptics Click Action: 1, 1, 1
    Synaptics Circular Scrolling: 0
    Synaptics Circular Scrolling Trigger: 0
    Synaptics Circular Pad: 0
    Synaptics Palm Detection: 1
    Synaptics Palm Dimensions: 10, 200
    Synaptics Pressure Motion: 30, 160
    Synaptics Grab Event Device: 1

Should I adjust any of these to improve things?

Please try the package from my PPA. It now only considers maxtapmove for one-finger taps, or two-finger taps if two-finger scrolling is enabled.

This always makes three-finger taps easy (I was never able to do them with the current code, although with the old code it was fine), and two-finger taps much easier (unless you have two-finger scrolling enabled, in which case you want it to be harder).

Also, do not implement the Synaptics Tap Move workaround when testing this package.

on 14/10/08 09:48 William Grant said the following:
> Please try the package from my PPA. It now only considers maxtapmove for
> one-finger taps, or two-finger taps if two-finger scrolling is enabled.
>
> This always makes three-finger taps easy (I was never able to do them
> with the current code, although with the old code it was fine), and two-
> finger taps much easier (unless you have two-finger scrolling enabled,
> in which case you want it to be harder).
>
> ** Changed in: xserver-xorg-input-synaptics (Ubuntu)
> Assignee: (unassigned) => William Grant (wgrant)
> Status: Confirmed => In Progress
>
>
Using version 0.15.2-0ubuntu6~wgrant1,

with

        Option "MaxTapMove" "0"

in xorg.conf, and without any xinput commands, both two and three finger
tapping seem to work well. I don't use two-finger scrolling at all.

I'd ideally like testing without such a line (particularly as you shouldn't have touchpad config in your xorg.conf any more, as it's removed on upgrade and is more likely to break things than set things properly), but testers on IRC have confirmed it works fine.

on 14/10/08 12:14 William Grant said the following:
> I'd ideally like testing without such a line (particularly as you
> shouldn't have touchpad config in your xorg.conf any more, as it's
> removed on upgrade and is more likely to break things than set things
> properly), but testers on IRC have confirmed it works fine.
>
>
Ok, I've removed all the tap-related entries from my xorg.conf, and the
multi-finger tapping still seems to be working correctly with your ppa
version. Thanks for all your help.

So, this bug is marked release-critical. Has the PPA fix been reviewed? Bryce/Timo?

I've reviewed the PPA fix, which contains a fix both for this bug and for 282735. The fix for this bug is:

+ touch = finger && !priv->finger_state;
+ release = !finger && priv->finger_state;
+- move = (((abs(hw->x - priv->touch_on.x) >= para->tap_move) ||
++ move = ((priv->tap_max_fingers <= ((priv->horiz_scroll_twofinger_on || priv->vert_scroll_twofinger_on)? 2 : 1)) &&
++ ((abs(hw->x - priv->touch_on.x) >= para->tap_move) ||
+ (abs(hw->y - priv->touch_on.y) >= para->tap_move)));
+

From a risk standpoint, this looks quite safe, with all risk localized to touchpad behavior, so I'm comfortable with it. Also, given the confirmation in comment #15, it sounds ready for upload.

Fix is uploaded; waiting on release team approval.

Fix accepted.

The fix wasn't actually enabled. It will be fixed shortly.

Forgot to actually enable the patch in the previous upload; this fixes that.

Thanks for finding a reasonable fix to this problem. The root culprit is likely that during two- and three-finger taps, many touchpad drivers lose track of which finger is the tracking one. This results in sudden jumps of the
pointer, which due to the MaxTapMove logic cancels the tapping action. The reasonable default otherwise is something like a finger wide, which is what the new auto-set defaults will give you in the next upstream release. I will have a look at the possibility to fix the tracking finger better, since this would also remove the disturbing behavior of a moving pointer during multi-finger actions.

On a different note, I have trouble seeing how

        Option "MaxTapMove" "0"

can work, since it counteracts the idea behind MaxTapMove.