I've been experimenting with alternative protocols to HID. I'm not satisfied with fixed-interval input polling out of sync with vsync; it takes way too many sam

I've been experimenting with alternative protocols to HID. I'm not satisfied with fixed-interval input polling out of sync with vsync; it takes way too many samples to reach the desired latency (and especially jitter!) numbers. As for keyboards, there's no real excuse not to just have a Bigass™ shift register (or a couple) and address every keyswitch with a trace and an interrupt crossbar. There's a limit to how cheap a good-enough keyboard can ultimately be, so a difference of a few cents in BOM and assembly, and slightly more intricate membrane layouts is not worth crying over. The methodology here is broken for non-linear long-travel keyswitches, for which the "point at which the key starts moving" is the wrong point to measure. For example, I'm typing this on buckling-spring keyswitches. The break for these switches is part way down the stroke, this is intentional and does not contribute to "latency", since the intent of depressing the key above the break is not to send the keypress at that moment, but to be ready to cross the break once the previous key has been pressed. This is very similar to how good handgun triggers typically function: a light, firm, and smooth uptake before a break, and hopefully with a reset very near the break. It communicates to the user how close they are to actuating the switch. In the case of linear long-travel switches (i.e. Cherry MX Red style switches), it's harder to decide where to consider the key "pressed", but in the case of non-linear long-travel switches (buckling spring, Cherry MX Blue) it's clear that the break is when the keypress should be registered, not the beginning of the uptake. In the case of non-linear switches, they don't need to bottom out to register keypresses, so they can have exceptionally low latency. With sufficient spring stiffness, and a long enough heel, buckling spring keyswitches should take less time to actuate than scissor-dome switches. Added: Regarding the testing methodology, it seems like you could do better with a combination of a motor, an armature, and a small strain gauge (or a measurement of motor load). The motor will apply consistent force at consistent peak acceleration between tests if you input consistent voltage. For non-linear switches, you can measure the break time as a junction in the applied force across the strain gauge or in the motor load on one of the analog inputs on your logic analyzer; for linear switches, you can measure the start of actuation the same way. Motor load would work just fine, since you're not interested in the exact force exerted, and thus don't need to calibrate for the efficiency of the motor.