Hi Chris, I don't have a bamboo to test with for the next month or so. It is hard for me to make proper comments without trying the ideas on a tablet. So, I'll just comment on the part that is appropriate at this moment.
Thank you for your in-depth discussion of the issue. Ping On Wed, Aug 4, 2010 at 10:18 PM, Chris Bagwell <[email protected]> wrote: > As you probably saw on linuxwacom-discuss, there are several users > reporting erratic behavior on bamboo touch pad and seems to be caused > by work-around logic for lost kernel events in multi-touch case. > > 1054 if (!(ds.x * ds.y) || (pLast->proximity && > 1055 (abs(ds.x - pLast->x) > BAMBOO_TOUCH_JUMPED || > 1056 abs(ds.y - pLast->y) > BAMBOO_TOUCH_JUMPED))) > 1057 { > 1058 /* ignore the data */ > 1059 goto ret; > 1060 } > > Below are some quick use cases I wrote to see what "invalid" values > xf86-input-wacom can receive because of known kernel side filtering > for multitouch case. The worst case invalid values come when user > places initial fingers down at same X or Y plane. If users are moving > 1 finger onto same plane as another, they will get a smaller size > burst once it leaves same plane. > > I think current codes checking for !(ds.x * ds.y) is to detect first > large jump on initial proximity and the delta of 30 is for second > smaller type burst when going out of plane? You are right. > The value of 30 seems is to low since users can "normally" move their > finger that fast and only way to get out of work around is to lift > finger. You told a few users to test 300 and they provided positive feedbacks, right? > I vote for removing that 30 delta check Then why cann't we just change 30 to 300 or something so users can still use 2FGT if they want? > but leaving the check for X/Y > == 0 and just deal with the small burst which confuses gesture logic > until kernel side issues can be resolved in an acceptable manner. I > think priority one should be 1 finger operations of touch pad. Making 1FGT a higher priority is a good approach (maybe we can set 2FGT off by default?). However, if we could make the 2FGT feature in a relatively usable condition for those who are eager to get their fingers "dirty", it would not hurt us anything, would it? Ping > What do you think? > > Assumptions: > > 1) 2 fingers can not be at exact same X/Y coordinates. One of two > will be difference always. > 2) Kernel driver always had set x/y/pressure to 0 when going out of > proximity for last finger but may or may not have been sent based on > filtering. Mostly, I'm ignoring out-of-proximity filter issues for > now although is probably not problem free. > 3) Even when only 1 finger moves, kernel attempts to send 2 fingers > data always (it does not if(no change) filtering on its own). > > * Put two fingers on same X plane with no movement in between. Same > example applies to 2 fingers on same Y plane. > > Finger 1 in proximity and sends x/y of 100/50 - xf86 initializes x/y > to 0 and then fills in x/y as 100/50. > Finger 2 in proximity and sends x/y of 100/80 - xf86 initializes x/y > to 0 and then fills in y as 80 and reuses x of 0. Kernel filtered out > x value send. > Finger 2 moves to 100/90 - xf86 gets 100/50 for 1st finger again > because last sent values where 110/80 which confuses filtering. Then > kernel sends only y value of 90 and reuses previous 100 for x value. > > * Put two fingers down at different X plane but move 1st finger into > same X plane (for example, during 2 finger swipe if users adjust > fingers a little bit). Example applies to same Y plane as well. > > Finger 1 in proximity and sends x/y of 100/50 - xf86 initializes x/y > to 0 and then fills in x/y as 100/50. > Finger 2 in proximity and sends x/y of 110/80 - xf86 initializes x/y > to 0 and then fills in x/y as 110/80. > Finger 1 moves to 110/50 - xf86 only gets y value of 50 and reuses > previous 100 for x value. Kernel resends 2nd finger y value of 80 and > xf86 reuses 110 x value. > Finger 1 moves to 120/50 - xf86 gets x/y values of 120/50. Kernel > resends 2nd finger x/y value of 110/80. *** I think this larger jump > is what current delta value is meant to catch? *** > > * Put two fingers down at different X plane but move 2nd finger into > same X plane (for example, during 2 finger swipe if users adjust > fingers a little bit). Example applies to same Y plane as well. > > Finger 1 in proximity and sends x/y of 100/50 - xf86 initializes x/y > to 0 and then fills in x/y as 100/50. > Finger 2 in proximity and sends x/y of 110/80 - xf86 initializes x/y > to 0 and then fills in x/y as 110/80. > Finger 2 moves to 100/80 - xf86 gets 100/50 for 1st finger again > because last sent values where 110/80 which confuses filtering. Then > kernel sends only y value of 80 and reuses previous 110 for x value. > Finger 2 moves to 90/80 - xf86 gets x/y values of 100/50 for first > finger from kernel resend. xf86 gets x/y value of 90/80 for 2nd > finger. *** I think this larger jump is what current delta value is > meant to catch? *** > > Chris > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Linuxwacom-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel > ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
