Sparky wrote:Always good to have more attention on input lag. Glad to see you have a test setup that measures absolute input lag, rather than just a relative measurement between two mice, which is currently the most popular method for this measurement.
[...]
In the model of switch I tested,Step 3 typically takes about 2ms for a "normal" click, but ranges from about 0.5ms to many tens of milliseconds.
https://www.overclock.net/forum/375-mic ... st25711039
Interesting post, thanks!
Sparky wrote:
If the engineer prioritizes latency, and is using double throw switches, steps 4 and 5 combined should take less than 0.1ms. Using single throw switches you have to use delay based debouncing, but press latency can still be low, only releasing the button really needs a long delay. Unfortunately the delay you need to reliably prevent glitches like double clicking on a single click, or releasing during a drag, is long enough that it would interfere with people spamming clicks intentionally. Unless you use the NC contact for debouncing, in which case you don't need any delays.
Oh, nice - I didn't know of this method. We haven't yet looked into debouncing or any other aspects of mechanical keypresses. Sounds like an interesting topic.
Sparky wrote:
In your testing did you come across any mice that actually used the normally closed switch contact for debouncing?
I don't know. We completely ignored the switches and just looked for their pins on the PCB.
Sparky wrote:
Getting a polling interval faster than 1ms is also possible, but impractical. Either you need a USB driver that polls the input device more frequently than the USB spec calls for, or you need to implement a high speed device, which is expensive and overkill.
You are absolutely right. USB high-speed devices can be polled every 125µs subframe, i.e. at 8000 Hz. In practice, we haven't come across an input device that acts as high-speed device (there are certainly ones somewhere). We settled for 1 ms in our tests because that conforms to the USB standard and can be easily set.
Also, the mousepoll/... USB HID parameters on Linux only allow for setting a minimum of 1 ms - and the Linux EHCI USB code also uses 1 ms as the minimum polling interval.
I guess, for some of the really fast devices, using the higher polling rate could make a difference - but we are talking about less than one millisecond.
Sparky wrote:
As for possible improvements: Maybe a mechanical test fixture that uses an accelerometer for the non-usb trigger. This would let you test devices without opening them, include differences in mechanical actuation time, and give a more accurate test of input devices like keyboards, where each button isn't sampled continuously.
We tried something like this using a force sensor. With clicky buttons one could easily determine when the button snapped through because the force applied to the button would suddenly be reduced. But with mushy buttons (many keyboards, gamepads - everything with rubber dome switches), you won't get reliable results. Therefore we focused on the electrical part first - but might investigate mechanical button latency some time in the future.