[PATCH evdev] add button debouncing

[Peter Hutterer]

On Thu, Aug 23, 2012 at 09:14:37AM -0400, Matt Whitlock wrote:
> (Sorry.  Sent from the wrong account.  Resending...)
> 
> On Thursday, 23 August 2012, at 10:58 am, Daniel Stone wrote:
> > On 23 August 2012 08:40, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > > On Mon, Aug 13, 2012 at 05:47:12PM -0400, Matt Whitlock wrote:
> > >> This patch adds one configuration option, "DebounceDelay", and one XInput property, "Evdev Debounce Delay". They refer to the amount of time to wait after receiving a mouse button release event from the kernel before posting the event to the X server. If a mouse button pressed event is received before the delay expires, then the release/press pair is forgotten. This allows to deal with mice whose button switches are worn out or dirty. Each mouse button is debounced independently.
> >
> > > Just reading the description, I think this is the wrong way round. Why not let the first event through unconditionally and then discard the second one if it arrives within the time frame. This wouldn't require a timer, instead you could note the time the last event arrived and then act on that.
> >
> > Huh? The problem is when you have a press-pause-release pattern which is actually sent as press-release-press-release-press-release.  So, you want to suppress the inner release/press.
> 
> Indeed, that is the problem this is trying to solve.  

right, sorry. it was getting late and I mis-read it.

> My particular mouse exhibits two symptoms that are worked around by this patch:
> 
> (1) Sometimes a single click is interpreted as a double click.  This
> causes all sorts of nasty errant behavior like maximizing/restoring windows
> when I only meant to click their titlebars for focus, launching files when I
> only meant to select them, selecting whole words when I only meant to
> position the caret, etc.
> 
> (2) Sometimes a drag gets released even though I'm holding the button the
> whole time.  This is particularly annoying when it happens also to produce a
> "click" event after the release, as that can cause unexpected widgets to
> receive clicks when I'm dragging an object or window around on the screen.
> Also, it's hard to select a large block of text when my drag stops and
> restarts in the middle of the mouse motion.
> 
> This patch waits for a little bit of time after the button is released
> before accepting that the button was actually released.  If the button gets
> pressed again before the timeout expires, both the release and the re-press
> get swallowed.  If the button does not get pressed again before the timeout
> expires, then the release is sent along to the server.  I know of no way to
> implement this without the use of a timer.  

correct, the timer is the right way for this approach.

> > > Having said that, I'm really hesitant on this feature. The reason you
> > > stated is "mice whose button switches are worn out or dirty". Is the cost of
> > > replacing (or cleaning) said device not a lot less than writing the code and
> > > maintaining it? How many devices are actually affected by this?
> 
> I have an expensive wireless laser mouse.  The battery is still in great
> condition, but the buttons are wearing out due to heavy use.  Why should I
> buy a new mouse when I can easily correct for the hardware in software?  If
> you don't want to maintain my addition to xf86-input-evdev, that's
> understandable.

you can easily correct for it in software, but looking at a long-term
picture there's quite a big cost involved. I'm already the bottleneck on
most drivers. stuff like this is the main reason why I've been working on
automating tests so we can at least ensure that stuff is tested and we're
notified when it breaks. Some features we provide we don't know for months
when they break, and I'm worried this may be one of these (e.g. if you buy a
new mouse, the feature stays around without a user).

so for now I'll have to put this on backburner until the test suite is
sorted out enough that we trust it, then we can reconsider. sorry.

Cheers,
   Peter