Feature request: more responsive debouncing for keypad scanners

[xs5871]

I guess this falls under feature request:

I've been looking into implementing a more responsive debouncing algorithm for
the keypad module. The motivation should be obvious: the current implementation
is a scan rate limiter which effectively implies a random input delay between 0
and interval seconds, which can be undesirable in various applications.

What I have implemented and tested as a minimum impact improvement is an
additional parameter debounce_cycles to the scanner initialisation that allows
scans to skip a number of scan cycles after a state change, i.e. per-key greedy
symmetric debouncing.

KeyMatrix default signature for illustration:

KeyMatrix(
    row_pins=[...],
    col_pins=[...],
    interval=0.02,
    debounce_cycles=0,
)

It doesn't add a significant amount of ROM/RAM requirements compared to the
current implementation aside from the additional QSTR, and setting the default
debounce_cycles=0 makes the interface backwards compatible.
That could be reduced to a single parameter enforcing a scannig rate of let's
say 1ms, but personally I like that the scanning interval is adjustable to the
application and hardware, especially considering that the common use for
keypad is keyboards and controllers and the USB polling interval is 8ms or
more anyway.

Now, before submitting a PR I'd like to hear some opinions on that.

• Would that be considered a worthwhile feature in general?
• Is the additional parameter preferable to a single parameter solution that
  will break backwards compatibility (and potantially waste CPU cycles with
  agressive scanning)?
• Is greedy symmetric debouncing good enough? Making it defered debouncing
  shouldn't affect the complexity and footprint, but further granularity will.

[dhalbert]

What is your use case where the current scheme does not work so well?

[xs5871]

For context: I came across this request / issue as a KMK maintainer.
Any time you want to use keypad without an essentially random input delay, really. The request for "better", i.e. faster, debouncing comes up in the mechanical keyboard scene ever so often, and there are key switches and arcade buttons with significant bounce that could benefit from a more responsive algorithm.
In general the current solution works fine. Once there are strict timing constraints, as in video games, or multiple keys are pressed in short succession and have to be processed in order the rate limit debouncing may not cut it.

[dhalbert]

Could you submit a draft PR with your suggested change, including inline documentation additions and maybe some sample code and explanations.? As long as it's upward compatible, I think this should be OK.

I don't know exactly what you mean by debounce_cycles. Do you mean additional intervals that are skipped after a transition? So that, for instance, does interval=0.02 and debounce_cycles=3 means waiting 0.02*3 seconds after a transition, or do you mean something else? And is this per key?

[xs5871]

You are correct, that is how debounce_cycles worked. I had to tweak the algorithm though, so that doesn't apply anymore. The PR took longer than expected, because the CP repo keeps breaking on my side for some reason.