I was happy to note the following in the release announcement of xf86-input-synaptics-1.5.99.901:
“… the most notable features are the addition of multitouch support and support for ClickPads.”
As a MacBook Pro user, that sounded just what I needed. No more patching the bcm5974 module to have some basic drag-and-drop support. I upgraded and everything seemed to work… for a while. I began noticing weird things occurring when I was trying to right and middle click (being a two and three finger click respectively). Specifically, my fingers would sometimes be registered in a click and sometimes not.
The two finger “right” click was easy enough to figure out. If my fingers were too far apart, the two finger click was not registered. It turns out I am what I have decided to call a “finger-spreader”, as my fingers can be quite relaxed across the touchpad when I click. Fair enough, I thought… I just have to train myself to click with my fingers closer together. Then came the three finger click. All three fingers close together did not seem to register as anything. A bit of spreading and a three finger click got registered, but too much spreading and it was down to two fingers. Also, it was not actual distance between fingers that mattered as rotating my hand on the touchpad with my fingers the same distance apart could result in different types of clicks registered.
A bit of looking in the xf86-input-synaptics git shortlog lead me to this commit as a likely candidate for my issues. The commit summary starting with “Guess” and it having a comment labelled “FIXME” were the give-aways… The first thing I noticed was that the calculation of the maximum distance between fingers to register as a multitouch click was done in terms of percentage of touchpad size. That means that the acceptable region where your two fingers need to be for a two finger click is an ellipse, which at least explains why physical distance appeared not to matter.
Attempted fix #1 was to increase the maximum allowed separation between fingers from 30% to 50%. That worked brilliant for two finger clicking, but made three finger clicking even worse, which lead me to another interesting discovery… The number of fingers being used is calculated as the number of pairs of fingers within the maximum separation, plus one. For two fingers, fingers 1 and 2 form one pair, plus one is “two fingers”. However, for three fingers, there are three possible pairs: (1,2), (2,3) and (1,3). This explains the weirdness in three finger clicking; finger pairs (1,2) and (2,3) must be withing the maximum allowed separation while finger pair (1,3) must be outside that. That explains why having fingers too close together did not register as a three finger click (as it was being reported as four fingers – three pairs plus one) and why things became worse when I increased the maximum allowed separation. I filed a bug report upstream and a patch to fix that quickly appeared.
After applying that patch, multifinger clicks all work fine provided your fingers are close enough together. I do not find the required finger closeness natural so I got rid of the finger distance restrictions altogether using this patch. I am not entirely sure what I break removing that, but it appears to be something I do not use as I have not noticed an issues so far. As always, use at your own risk…
Edit: 2012-05-21 – Updated patch for xf86-input-synaptics-1.6.1
I used to run xf86-input-synaptics-clickpad from AUR to get support for ClickPads on my Lenovo x220, but since it’s merged upstream now I decided to switch back to regular xf86-input-synaptics from extra, only to discover that
– scrolling on the right edge of the pad no longer works,
– drag-selecting (e.g. text) with the ClickPad left-button + drag no longer works,
– drag-selecting with the separate left-button (above ClickPad) + drag sometimes has hickups.
So in a way I got bitten by the same upgrade. Haven’t bother to look into any of these issues yet. I thought that the changes that xf86-input-synaptics-clickpad had were pretty much merged as-is upstream, and hence it would be a smooth sailing :/ If you have any tip on any of these regressions I’m idle ears…
I do not use right edge scrolling so have not tested that, but drag-selecting works fine for me.
I also have the problem with drag-selecting on my computer since the last update (just to be sure that we are talking of the same thing, my touchpad does not have any separate button but is itself physically clickable, and since the last update dragging while physically clicking does not work anymore (it was working before))
On my touchpad (MacBook Pro, so no buttons), clicking and dragging with the same finger works as does clicking with the thumb and dragging with a finger. Having that working without having to patch the driver was one of the things I liked about this update.
Indeed, false alarm, I rebooted (against my will) and now it seems to work, both with the same finger and with another finger (before that, it was only working when dragging with the same finger). That’s great 🙂
By the way I came on your blog because I’m running Arch Linux 32-bit with Chrome OS’s kernel (on a Samsung Chromebook) and Chrome OS has been switched from 32-bit to 64-bit at the last update, so I was a little worried about how my Arch Linux would react to this when I would reboot. Then I read your blog post about running a 32-bit userspace with a 64-bit kernel and I was less worried knowing that everything should work fine. And now that something crashed my computer and forced a reboot, I can confirm that everything seems to be working.
So thanks for having unworried me 🙂
Why don’t you use https://github.com/BlueDragonX/xf86-input-mtrack? It’s quite easy to setup many different configurations with this driver, especially on MBP.