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

[Alexander E. Patrakov]

17.06.2014 13:20, Peter Hutterer wrote:
> 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:

Let me reply twice to this then. Once very seriously (this e-mail), and 
once half-seriously (the other one, to be sent a bit later).

> if we detect a jump, hold the current event back

OK for the purpose of discussing the consequences.

Note that, below, you talk about "the next event" and its position, but 
this is meaningless if it is a touch-up. So we have to decide what to do 
when we see a jump immediately followed by a touch-up. I have no serious 
opinion here.

> - if the next event is close to the new position, assume a touch up/down,
>    insert those, send both events with the new position.

This totally makes sense, and involves one non-magic parameter: finger 
width, as I have already noted.

> - [else] if the next event is in line from the original position, assume a move,
>    just send off the events as-is.

This "two jumps in the same direction = move" approach looks logical if 
we can find a way to answer the question "is this event in-line" with a 
sufficiently low number of the magic parameters. I will criticize this 
further in my half-serious e-mail.

And we have to think about the final "else": two jumps that are not 
aligned. I have no serious opinion what to do here, either.

On the other hand, I think that we should try the simplistic "any big 
jump is a finger change" approach first, and treat the "is the next jump 
in line" test as an optimization that can be added later.

-- 
Alexander E. Patrakov