[PATCH synaptics] Add movement constraints to clickpads to prevent cursor jumps

[Alexander E. Patrakov]

16.06.2014 16:37, Peter Hutterer wrote:
> On 15/06/2014 03:48 , Alexander E. Patrakov wrote:
>> 1. I decide to place the pointer somewhere and left-click.
>> 2. I place the right index finger on the touchpad.
>> 3. I move the pointer approximately near the desired position, which
>> often happens to be near the center of the touchpad.
>> 4. I do two things simultaneously:
>> 4a. I direct my left index finger to the left virtual button, with the
>> intention to click.
>> 4b. I finish the right index finger movement, with the intention to
>> bring the pointer exactly to the correct position and then to remove the
>> finger.
>> 5. The following two events happen in unpredictable order, because I
>> don't really care about the order:
>> 5a. I remove the right-hand index finger from the touchpad.
>> 5b. I place the left-hand index finger on the touchpad in the left
>> virtual-button area.
>> 6. I click using the left index finger.
>>
>> If events 5a and 5b are separated by less than, say, 20 ms, the touchpad
>> misreports them: it says "the finger moved from the center to the
>> bottom-left corner" (i.e. reuses the tracking ID), instead of "one touch
>> disappeared in the center, and one appeared in the corner".
>
> the polling rate is 80Hz, which makes it 12.5 ms, so your analysis looks
> pretty spot-on. The problem is: I'm not a big fan of having some magic
> threshold in the driver that applies to everything. I was hoping that we
> can look at the timestamps of the events and the history of previous
> events and detect when there is such a jump going on.
>
> I don't have direct solution, so this is just thinking aloud: the event
> sequence you're likely to get is a number of events grouped together,
> then an event outside of that group, followed by a number of events
> closely grouped together. If we can reliably make that detection we
> should be able to insert the required touch up/down with a bit of delay
> before replaying the events correctly.
>
> Again, this isn't a real solution yet, but maybe it helps with an idea
> (or at least an approach) to tackle this.

I think that you found magic where there is none. The threshold has a 
very simple physical meaning: finger width. If the touch point moved by 
more than that since the last report, we cannot say whether it is the 
same finger or not. So let's just pretend that the finger is not there 
in that case.

And why do you suggest to add a bit of delay?

My gut feeling is that the more complex approach that you suggest (with 
looking at the "typical" distance between reports in order to group 
them) would yield at least two magic parameters. But I may be wrong.

P.S. mtdev's touch-matching algorithm has no distance cutoff and thus 
also contributes to this bug in cases where it is used.

P.P.S. While you are at it, could you please also look (yes, only look, 
no other action or response needed) at 
https://bugs.freedesktop.org/show_bug.cgi?id=76760 ? It is also a 
timing/sequence problem in the event reports, so is conceptually 
somewhat related, and one could possibly help you thinking about the other.

-- 
Alexander E. Patrakov