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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
