summaryrefslogtreecommitdiffstats
path: root/keyboards/s60_x/keymaps/jpec/keymap.c
diff options
context:
space:
mode:
authorAndrew Pritchard <awpr@google.com>2017-04-27 00:29:39 +0200
committerAndrew Pritchard <awpr@google.com>2017-04-27 00:29:39 +0200
commitcd30a60d0e4f108403b19ec4c1bc4270b54b8c27 (patch)
treeeacc9a73728bc060c5a71e668a47cfeeee69c430 /keyboards/s60_x/keymaps/jpec/keymap.c
parent7bd4559b4b8f323107de46ebf90d31bfa9880e78 (diff)
downloadqmk_firmware-cd30a60d0e4f108403b19ec4c1bc4270b54b8c27.tar.gz
qmk_firmware-cd30a60d0e4f108403b19ec4c1bc4270b54b8c27.tar.xz
Change to per-key eager debouncing for ErgoDox EZ.
Empirically, waiting for N consecutive identical scans as a debouncing strategy doesn't work very well for the ErgoDox EZ where scans are very slow compared to most keyboards. Instead, debounce the signals by eagerly reporting a change as soon as one scan observes it, but then ignoring further changes from that key for the next N scans. This is implemented by keeping an extra matrix of uint8 countdowns, such that only keys whose countdown is currently zero are eligible to change. When we do observe a change, we bump that key's countdown to DEBOUNCE. During each scan, every nonzero countdown is decremented. With this approach to debouncing, much higher debounce constants are tolerable, because latency does not increase with the constant, and debounce countdowns on one key do not interfere with events on other keys. The only negative effect of increasing the constant is that the minimum duration of a keypress increases. Perhaps I'm just extremely unlucky w.r.t. key switch quality, but I saw occasional bounces even with DEBOUNCE=10; with 15, I've seen none so far. That's around 47ms, which seems like an absolutely insane amount of time for a key to be bouncy, but at least it works.
Diffstat (limited to 'keyboards/s60_x/keymaps/jpec/keymap.c')
0 files changed, 0 insertions, 0 deletions