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?
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.
I vote for removing that 30 delta check 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.
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
