sorry about the delay, busy here. On Fri, Jan 16, 2015 at 02:09:38PM +0100, Gabriele Mazzotta wrote: > On Friday 16 January 2015 13:24:31 Peter Hutterer wrote: > > On Thu, Jan 15, 2015 at 10:04:17PM +0100, Gabriele Mazzotta wrote: > > > Some applications ignore the second tap of double taps because of > the > > > lack of a delay between the button down and button up events. > > > > > > Prevent this by replacing the transition from TS_2B to TS_START with > a > > > transition from TS_2B to TS_SINGLETAP that emits only a button down > > > event. The button up event will be emitted when transitioning from > > > TS_SINGLETAP to TS_START. > > > > > > In addition, decrease the default value of MaxDoubleTapTime from 180 > ms > > > to 100 ms in order to make double taps faster. > > > > Hmm, the problem here is now that MaxDoubleTapTime is now the sum of > > ClickTime and MaxDoubleTapTime. That's ok if we hadn't exposed those > as > > toggles but will break user's custom configurations. Even with your > change > > we go from 180 to 200, anyone who has this option set goes to value + > > ClickTime. > > > > Easy way around this would be to add clickTime to maxDoubleTapTime's > > default, check the option, then subtract it again after to leave the > double > > tap timeout as the difference between the two. > > > > pars->click_time = xf86SetIntOption(opts, "ClickTime", 100); > > pars->tap_time_2 = xf86SetIntOption(opts, > > "MaxDoubleTapTime", > > pars->clicktime + 80); > > pars->tap_time_2 -= pars->clicktime; > > > > That should work, no? > > I was worried about the same thing, but tests showed that the addition > ClickTime doesn't change things that much. > I have also thought about doing something similar to what you suggest, > but I didn't like the fact that by doing so the meaning of property > changes in a non-obvious way. > > My tests showed that the second down->up transition of double taps > doesn't determine how fast clicks are. The same applies to the only > down->up transition of single taps. As long as ClickTime is within a > reasonable range, it has no tangible effect. > > In case of double taps what really matters is how fast the second button > up->down transition is (the first one depends on how fast you tap), > which is what MaxDoubleTapTime determines.
are you sure? applications tend to react to button releases, so with your patch the second release for a doubletap is now on MaxDoubleTapTime + ClickTime, i.e. 100 ms later than before (by default). That would be noticable. You reduced by 80ms in your patch, so a doubletap with timeout would trigger the effect in the application 20ms later than before - which probably feels the same. > In case of single taps what really matters is MaxTapTime. > > For some reason I think the delay is more obvious for double taps and > in any case lower values of MaxTapTime makes Tap-and-Drag gestures > impossible, so it shouldn't be changed. This is why I decided to lower > the default value of MaxDoubleTapTime. My error was to include the > change here as if it was required. yeah, I'm pretty sure what you're seeing is the addition of the two timeouts. Have you tried the approach I suggested above? does it make the delay go away? Cheers, Peter _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
