summaryrefslogtreecommitdiffstats
path: root/drivers
diff options
context:
space:
mode:
authorBob <rsheldiii@gmail.com>2019-04-08 23:07:15 +0200
committerDrashna Jaelre <drashna@live.com>2019-04-08 23:07:15 +0200
commitbc536b9b6d98e5428a28f6e6ba69675bd77b79cc (patch)
tree1a22225476402e824957f77bd801d371a2622ed5 /drivers
parentf8d365a47847f8e49fde5096aa065dbee08cf728 (diff)
downloadqmk_firmware-bc536b9b6d98e5428a28f6e6ba69675bd77b79cc.tar.gz
qmk_firmware-bc536b9b6d98e5428a28f6e6ba69675bd77b79cc.tar.xz
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions