How to test Gaming Mice Click Latency and Keyboard Keypress Latency with OSLTT

Something I know I’ve been missing from my peripheral reviews is the ability to test the click latency, so having the Open Source Latency Testing Tool on hand is pretty handy. For those that have one, here are the (currently) three ways you can test click or keypress latency with mice and keyboards. First up is the easiest, but least accurate method, which is using the included microphone to listen out for the clicks. How you do it is pretty simple, just place the microphone close to the switch you’re going to hit – whether that be a mouse or keyboard, just have the mic right next to what you’re going to press. Make sure you select either the keyboard or mouse option in the software, then start the test. Get clicking – loudly – and leave a second between presses to make sure they register. Once you’ve gathered enough samples, you can end the test and view the results. 

As for why this is the least accurate method, basically the click sound that the board is listening for only happens once the shell part of the button bottoms out, so especially for high polling rate devices like this Viper 8K Hertz where the click event is sent out in a quarter of a millisecond, the sound likely hasn’t even happened yet, let alone the board recognising it and triggering the timer. For 1000 hertz peripherals, the microphone mode is perfectly fine, but if you’re testing anything with a higher polling rate, or you just want the utmost in accuracy, you’ll need to use the two pin input. 

This input method lets you solder directly to the switch itself and capture the electrical signal that the mouse is registering. You’ll need to take the mouse apart for this, and you’ll need a soldering iron and a multimeter, and you’ll need to check which pins you’ll be soldering to. For most of the mice I’ve tested, the central of the three pins is the switched pin, and the other two are both connected to ground – although some mice like this Glorious Model O Pro don’t have the rear pin soldered, only the front pin is connected to ground. If your unit shipped before the 22nd of November last year, you’ll need to solder a 1M Ohm resistor in-line with the signal pin – like this. In later units I fixed this by changing the internal resistor (and you can too if you’d rather, it’s an 0805 package SMD resistor on R7). Once you’ve got that soldered, you can then start the test the same way and get clicking. This should be considerably more accurate, albeit quite a pain to actually test.

So, I’ve got one more option for you. At the moment this is a bit of a bodge, but it’s kind of the best of both worlds. It’s something that Arek showed me while discussing different test methods on GitHub, and in short you’ll need some aluminium tape and a crocodile clip. I’m using some tinfoil here with a lead soldered to it, and you’ll also need an external power source, in my case I’m just using a raspberry pi. Connect the foil to the 3.3V pin on the pi, and attach the foil to the mouse button. Then with the 2 pin ground wire connected to ground on the pi, use the signal wire to tap the foil, clicking the mouse button. This gives you the accuracy of the 2 pin input, while not requiring you to rip apart every peripheral you’re testing. In a future version of the tool I’m planning on making this a more “official” test mode, but for now this does work. It is worth noting that it effectively reverses the inaccuracy of the sound mode though, as the board will detect the click before the mouse will, as the mouse switch has some amount of pre-travel that is counted as part of the click time here. I’d argue that this is the most real-world measurement though, as it’s basically measuring from the instant you start pushing the button to when that click is registered in Windows. 

I should also explain how the test works from a software perspective. As of version 0.9 of the desktop software, I now use a mouse and keyboard hook to detect the mouse or key down events. I specifically use the mouse down or key down events as that’s the first event reported. The mouse hook in particular is also considerably more reliable than the event tracking in WinForms, so you should see a fair bit better accuracy on that front. 

If you have any suggestions for other ways we can test peripherals, please do let me know in the comments or over on our Discord – I’d love to learn more and improve the tool for everyone!