On Thu, Aug 5, 2010 at 8:51 AM, Chris Bagwell <[email protected]> wrote: > On Thu, Aug 5, 2010 at 3:28 AM, Ping Cheng <[email protected]> wrote: >> 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. > > Hmmm, hard to decide if original author won't be able to see what > solves their original issues. > > More below. > >> >> 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? > > Well, I'd like to understand what the check was solving in the first > place to be able to answer that accurately. > > I suspect it was discarding packets that made things jump larger than > WACOM_INLINE_DISTANCE (40) that easily occur when going out of same > X/Y plane. In those cases, the jump would have confused gesture logic > and aborted gesture.
The check was not for gestures. It was just to discard "invalid" events, i.e. jumps. Without correct (x,y) for both fingers, we can not do anything reliable. The jump isn't only from the kernel. It may have some other sources, such as the device itself. We can have many solutions to get rid of the jumps. But only testing can tell us which solution is better. You have a Bamboo, right? You can test your ideas and we'll use your solution. I don't have time for this in the next few months. So, we'll count on you :). The only preference I have is to make it simple. Thanl you, Chris. Ping > If my suspicion is right then increasing from 30 to 300 is same as > removing code because the value would need to always be less then > WACOM_INLINE_DISTANCE to be useful. > >> >>> 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? > > I'd like to keep gestures working as much as possible as well. I'm a > 2-finger scrolling kinda a guy. I think my suggestion still allows > that, it just requires end user to follow the gesture guidelines I > just posted on linuxwacom-discuss. > > Chris > ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
