Inherent click delay found in mice.

Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
stirner
Posts: 74
Joined: 07 Aug 2014, 04:55

Re: Inherent click delay found in mice.

Post by stirner » 29 Dec 2014, 14:18

I didn't imply otherwise - I actually mentioned just that.
There is the possibility of debouncing only after the initial actuation.
Entirely possible that Chief actually meant this type of debounce with "after button release" now that I think about it. But again, my guess why it isn't deployed in any mouse out there but in keyboards is because it messes with quick double-clicking.

blargg
Posts: 66
Joined: 20 Sep 2014, 03:59

Re: Inherent click delay found in mice.

Post by blargg » 29 Dec 2014, 16:35

This part is what threw me off:
stirner wrote:In mice, debounce has to be of the "call state stable after Xms" type as opposed to the "call state unstable for Xms after event" type sometimes found in keyboards.
I interpreted this as the mouse waiting until it gets multiple like reads of the button before reporting to the host, e.g. read 0, wait 10ms, read 1, wait 10ms, read 1, report button down to host. It seems to me that when a button state change is detected, the next ~10ms must be disregarded, because the state might be randomly changing back and forth, so any read will be garbage. Thus, there's no benefit to not immediately reporting button down on the first read (other than allowing a very simplistic method of handling buttons that I've seen suggested for general embedded programming). Maybe your point was that with a keyboard, detecting quick double presses of a key is unimportant, so it can use a longer debounce time and not miss anything important.

stirner
Posts: 74
Joined: 07 Aug 2014, 04:55

Re: Inherent click delay found in mice.

Post by stirner » 29 Dec 2014, 16:55

I see. But yes, what you are describing is exactly what I meant. Registering the initial state change and disregading any further changes (or simply not reporting a key/button event for those) for Xms after that.

From the button latency in mice we know that they don't use this debounce type. One possible reason is because of how common quick double-clicking is. ~15-20ms is typically the debounce time with mice, so we can assume that's an amount they deem necessary for most microswitch designs. Should be enough to click twice.
Mice that have close to zero click latency are also the more popular ones to develop double-clicking issues (where 1 actuation causes 2 reports). So those must be using the standard debounce technique as well.

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: Inherent click delay found in mice.

Post by Sparky » 31 Dec 2014, 02:26

I recently had one of the microswitches in my mouse fail (Omron D2FC-F-7N in CM storm spawn), and got to thinking a bit. These are double throw switches, and my mouse only uses the normally open throw. How big a difference does it make if the other throw is used instead? It should be slightly less latency, due to the way the contact snaps, but I'll have to test it to see how big a difference that makes. I'll also test out how bouncy they are.

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: Inherent click delay found in mice.

Post by Sparky » 31 Dec 2014, 04:06

Ok, after a bit of testing, I get a couple ms lower latency by switching to the open when pressed throw, but you register a click before pushing the switch past it's snap threshold, so you can register a click without actually clicking. That said, you can use the second throw for very reliable debouncing.

Note: I'm not willing to be more precise about exactly how big the difference is without more testing and making sure overhead doesn't interfere with the time measurements. The difference between throws does change based on how quickly you press the button.

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: Inherent click delay found in mice.

Post by flood » 31 Dec 2014, 13:15

how many ms difference did you measure for a normal click?

blargg
Posts: 66
Joined: 20 Sep 2014, 03:59

Re: Inherent click delay found in mice.

Post by blargg » 31 Dec 2014, 14:50

I used to modify my mice to use the normally-closed contacts when the normally-open one started to fail (as that caused the mouse to release in the middle of a drag, very annoying). I made a simple (passive) inverter by changing the switch common to the opposite supply side, and adding a pull-up/down resistor to keep it in the idle state when not pressed. I encountered the issue you mentioned, where even lightly depressing the button registered as a click sometimes. Sometimes it felt like the computer read my mind and clicked before I even did so.

Using both throws is an interesting idea, as it makes switch wear a non-issue, and avoids the lockout time for debounce after each state change. I guess a simple RS flip-flop is all you'd need for such a mod. I've noticed that the cheap mice I use nowadays are just single throw, with only normally-open contacts. I crack open the switches to clean the metal bubble piece that gets oxidized every couple of years, keeping them working great for many years.

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: Inherent click delay found in mice.

Post by Sparky » 31 Dec 2014, 15:15

flood wrote:how many ms difference did you measure for a normal click?
anywhere from about 0.7 to 4 ms. Keep in mind this is just a microswitch stuck on a breadboard, it's not under a mouse button, so it's hard to replicate "normal".

stirner
Posts: 74
Joined: 07 Aug 2014, 04:55

Re: Inherent click delay found in mice.

Post by stirner » 01 Jan 2015, 11:42

Taking a look at this article http://www.ganssle.com/debouncing.htm made me wonder just what type of debounce mice use and why.

Because click latency commonly is changed with firmware flashing, chances are most use software-based rather than hardware-based debounce techniques.
And because click latency is commonly in the 10-20ms range, it's clear that (most) mice don't use the type where debouncing happens only after initially reporting the state change. I mentioned quick double-clicking as a possible reason for that, but I'm not certain that's the main issue. I also think it's unlikely that Logitech is the only brand that figured to utilise low-latency debounce types. It's more likely that they use the same debounce type but simply decrease debounce times because their switches are of higher quality.

Leaves the question why that type of debounce seemingly has to be used in mice. From the article: "All of these algorithms assume a timer or other periodic call that invokes the debouncer. For quick response and relatively low computational overhead I prefer a tick rate of a handful of milliseconds." - you could simply have the microprocessor ask for the switch state at a Xms interval and have a reliable low-latency debounce. The interval time naturally depends on the time window the switch is expected to jump around in. I doubt microswitches jump for 10-20ms though, a periodic call could more likely be in the single-digit milisecond range to work reliably.

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: Inherent click delay found in mice.

Post by flood » 02 Jan 2015, 14:07

blargg wrote: An analog switch with hysteresis (schmitt trigger) would avoid bounce, an optical switch being an instance of this as you say.
was just thinking about something like this yesterday

set the state to clicked when the leaf hits the lower contact, set the state to released when the leaf hits the top contact.

Post Reply