>There is lots of wiggle room too in how you implement your debounce algorithm to optimize latency too.
That doesn't make any sense to me. Debouncing is about preventing inappropriate deactivation, and is unrelated to time to initial activation.
That doesn't make any sense to me. Debouncing is about preventing inappropriate deactivation, and is unrelated to time to initial activation.
I've seen simple BSP debounce example code that affects latency for both press/release. For example you can make sure the IO hasn't changed in X ms before accepting it as settled and reporting the event up. This way would incur latency on both press and release. In fact, the first answer I see on google does this: https://www.beningo.com/7-steps-to-create-a-reusable-debounc...
You could report the event right away when there is an activation, and just not allow a deactivation event to be reported until the debounce time has expired. I suspect this is what you mean by debounce only applying on deactivation, but I'll bet some of the keyboards tested on that list are not doing this.
I've seen implementations where the CPU gets the pulse, waits for debounce interval, check whether the pulse is still happening and only then sends "the button is on" signal, which obviously is terrible for latency.
Proper debounce will send signal immediately then ignore the state for few milliseconds.
> Debouncing is about preventing inappropriate deactivation, and is unrelated to time to initial activation.
It's both. Contacts generate noise on both press and depress.
The debouncing logic is about how we determine when to re-arm the switch for the next transition - i.e. how to reject the "false" reversions to the prior state. So it shouldn't have any impact on the "physical action to key-down event" latency in systems with a reasonable steady state. I guess for cases where "pound on the same key again and again as quickly as possible" are in scope it does?