To me the question is how do you use that method to measure keyboard responsiveness? On the camera, you can't quite tell when the key was "supposed" to trigger. I've done these measurements by having a keypress toggle an LED on the keyboard (in firmware), but that glosses over the matrix scan (and potentially debouncing if you implement that wrong). All in all, I've never been fully satisfied there. Maybe you need a one-key keyboard that triggers the LED from an interrupt, and then handles the keypress normally. (Only one key, so no matrix. Triggers on the first edge, so no debounce latency.)
NVIDIA published LDAT[1] for click-to-photon latency measurements a while ago. The 'Intended' purpose was to measure input latency for gaming but it could probably be reused for measuring responsivity. This would implicitly also measure the hardware but that shouldn't matter when a constant hardware/driver combo is used.
AFAIK you'd have to have a pretty bad keyboard for it to have a significant role in latency. I guess specialized hardware (based on a microcontroller with built-in USB host support) wouldn't be too hard to construct if you really needed to know.
For the camera measurement, I would just press the key as fast as possible and pick about 3/4 of the way down as the trigger point.
So if you check the appendix section, they say they're measuring latency not when the keyswitch makes contact, but when the finger first begins pressing on the key. So they're taking key travel time into account, and that ends up being the majority of the "latency".
It's a fair point for the gaming argument they make, if you want to jump 30ms quicker you'll need shorter keys. But it's not really correct to say the keyboard is adding so much latency when it's actually the user.
> So if you check the appendix section, they say they're measuring latency not when the keyswitch makes contact, but when the finger first begins pressing on the key. So they're taking key travel time into account, and that ends up being the majority of the "latency".
I can confirm the LED is not controlled by only keyboard firmware.
I very often use num lock and caps lock responsiveness to check if my PC has hard-locked, and I just recently suffered hard locks while testing S3 on Linux on a new PC. So I am very sure at this point :)
I only really suggested that because any OS can detect the presence of the CAPS LOCK key (see 'CAPS LOCK is on' during Windows login) and it would make a potentially good marker.