[PATCH synaptics] Prevent button mashing on clickpads

[Peter Hutterer]

On Wed, Oct 30, 2013 at 11:39:58PM -0700, Daniel Colascione wrote:
> On 10/30/2013 11:39 PM, Peter Hutterer wrote:
> >On Tue, Oct 29, 2013 at 05:08:25PM -0700, Daniel Colascione wrote:
> >>On 10/29/2013 05:04 PM, Peter Hutterer wrote:
> >>>On Sun, Oct 27, 2013 at 04:24:47PM -0700, Daniel Colascione wrote:
> >>>>The tiny patch below disables the clickpad hardware "button" when
> >>>>syndaemon has asked us to disable tapping.  Without this patch, I
> >>>>frequently find myself accidentally clicking while typing.
> >>>
> >>>isn't this a physical button? if so, it'd be better to just disable the
> >>>touchpad fully instead of just disabling tapping.
> >>
> >>It's a physical button, but it's unlike other physical buttons in
> >>that it takes up the _entire trackpad_. It's a lot easier to trigger
> >>this button than it is to trigger a traditional button, so it really
> >>should be treated as a tap for disablement purposes.
> >
> >what device is this? if anything it takes me more effort on my clickpad to
> >press the whole thing than pressing a button on the old-style clickpad.
> 
> It's a Lenovo X1 Carbon. All I can do is comment on my annoyance
> relative to my hardware.
> 
> >>The idea behind using TOUCHPAD_TAP_OFF instead of TOUCHPAD_OFF is to
> >>allow the user to move the cursor as soon as possible after typing.
> >
> >I have no idea what the idea behind it is, the git history isn't forthcoming
> >here.
> 
> It's the only reasonable explanation I can think of.
> 
> my suspicion is that tapping is a separate entity because accidentally
> >causing a tap/scroll is a problem, moving a bit usually not (especially when
> >palm detection sucks)
> 
> Yes.
> 
> >>By the time the user gets around to actually clicking something, the
> >>type-inhibit delay will have expired and we'll have turned off
> >>TOUCHPAD_TAP_OFF. This way, the user never notices the delay ---
> >>users will take a few hundred ms to click anyway. If we used
> >>TOUCHPAD_OFF instead, you'd either have to shorten the delay or
> >>cause users more annoyance.
> >
> >synaptics history teaches me that you don't get to pick between less or more
> >annoyance, you only get to choose who you're going to annoy...
> 
> So you're arguing that all options are equally annoyance, so we
> shouldn't change anything?

I'm arguing that if we want to change behaviour that's been there for
years we better have a really good reason for it. because whenever you
change some behaviour, you're likely breaking it for someone else.

adding another option is also not really a solution, we have (rough count)
69 option and there is almost no testing on the various combinations.
the driver is almost unmaintainable already, so I'm really hesitant these
days to add or change anything that's not absolutely required because quite
frankly, I don't have the time or energy to deal with the fallout.

Cheers,
   Peter