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