On Mon, Jul 4, 2011 at 9:35 PM, Peter Hutterer <[email protected]> wrote: > On Sat, Jul 02, 2011 at 08:03:34PM -0500, [email protected] wrote: >> From: Chris Bagwell <[email protected]> >> >> There are two initial LAG times used in current code: >> >> 1) GESTURE_LAG_MODE to wait to 1 or 2 finger detection. >> 2) A lag once 2 fingers are detected before deciding >> what 2 finger gesture is occuring. >> >> During #1, wcmGestureMode was set to a non-zero value but >> during #2 its value was zero. This caused cursor to move >> around during #2 period when I don't think this was intention. > > this should be addressed by the enum I mentioned in the other email, but > "yes" in spirit. > >> Also, waiting 2 times wcmTapTime felt much to long to me >> before 2 finger gestures kicked in. Shorted to just wcmTapTime. > > why do we re-use a time for a separate feature? why not just add a specific > time for this?
I suspect from original patch viewpoint, there is no reason other than it would be extra effort. TBH, I was happy that original feature didn't expose to much because then I didn't have to vet the feature as closely. Ideally, 2 finger gestures should not be based on time window since touching. It should at least be based on time window since motion is detected with 2 fingers. I think its pretty common that user puts two fingers on screen/tablet and sits there to stabilize their own hands... then they initiate gesture movement. Next, I'm not sure we really need a time based window at all. The goal is to detect 2 fingers moving parallel to and in same direction versus 2 fingers moving away or towards each other. If we want to send a scroll button event every X units moved then I'd wait until X units movement detected and then see if fingers are moving parallel and same direction to each other and also latch into scroll gesture mode. Anyways, I guess my point is I'd rather explore that option before exposing a new time based property to user. Let me split the wcmTapTime out of patch so we can investigate best way forward without holding up the movement-on-touchscreen issue. Chris > > Cheers, > Peter > >> Before this patch, if you attempt a 2 finger scroll inside a >> drawing app you would get about 2 seconds worth of 1 finger >> drawing. After this patch, you get either no drawing (just >> scrolling) or only a single dot drawn and the scrolling kicks >> in much faster. >> >> Signed-off-by: Chris Bagwell <[email protected]> >> --- >> src/wcmTouchFilter.c | 6 +++--- >> 1 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/src/wcmTouchFilter.c b/src/wcmTouchFilter.c >> index 9e0ee21..eb6562a 100644 >> --- a/src/wcmTouchFilter.c >> +++ b/src/wcmTouchFilter.c >> @@ -245,7 +245,7 @@ void wcmGestureFilter(WacomDevicePtr priv, int channel) >> >> /* second finger in prox. wait for gesture event if first finger >> * was in in prox */ >> - if (ds[1].proximity && !common->wcmGestureMode && dsLast[0].proximity) >> + if (ds[1].proximity && (!common->wcmGestureMode || >> common->wcmGestureMode == GESTURE_LAG_MODE) && dsLast[0].proximity) >> { >> common->wcmGestureMode = GESTURE_LAG_MODE; >> } >> @@ -320,9 +320,9 @@ void wcmGestureFilter(WacomDevicePtr priv, int channel) >> wcmFingerScroll(priv); >> >> /* process complex two finger gestures */ >> - else if ((2*common->wcmGestureParameters.wcmTapTime < >> + else if ((common->wcmGestureParameters.wcmTapTime <= >> (GetTimeInMillis() - ds[0].sample)) && >> - (2*common->wcmGestureParameters.wcmTapTime < >> + (common->wcmGestureParameters.wcmTapTime <= >> (GetTimeInMillis() - ds[1].sample)) >> && ds[0].proximity && ds[1].proximity) >> { >> -- >> 1.7.5.4 > ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
