[PATCH synaptics 2/2] Add a delay between the second button down-up event of double taps

[Peter Hutterer]

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