(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 <[email protected]> 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. 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. > > 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. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
