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