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

[Peter Hutterer]

On Tue, Jun 17, 2014 at 12:35:53AM +0600, Alexander E. Patrakov wrote:
> 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.

again, this hasn't gone past the "maybe this is how it could work" stage,
and I'm just grasping for straws that we can find something reliable here:

if we detect a jump, hold the current event back
- if the next event is close to the new position, assume a touch up/down,
  insert those, send both events with the new position.
- if the next event is in line from the original position, assume a move,
  just send off the events as-is.

> 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.

I think this one is more the human inability to time the release/press
events correctly at all times than the polling freq. But as a solution to
that I certainly like the idea you suggested.

Cheers,
   Peter