Separate scanning and debouncing #3646
Description
I raised the same thing in TMK, but nothing's really happened since January.
(Issue: tmk/tmk_keyboard#525)
(Pull request: tmk/tmk_keyboard#531)
Reasons for this change:
- Debounce algorithms are wrong, and are per keyboard, so that's a lot of wrong keyboards.
There are two main algorithms (both are wrong)
a) Global timer, that resets when any key changes. When entire keyboard is stable for 5ms, process keys
Disadvantage is if i can spam 5 keys with a 4.999ms gap between each one, processing order is not guaranteed to be same as actual pressing order
b) Poll and wait for x consecutive same inputs for stability. Same problem as above (pressing multiple keys within 5ms of each other), and in addition, x consecutive inputs may or may not be 5ms. - Since debounce is per keyboard, cleaning up the codebase now would be a nightmare
- However, if we separate it out now, and make debouncing optional, we can fix future keyboards.
Flow on effects:
Old workflow - scan_matrix() does both scanning and debouncing
New workflow - scan_matrix(), followed by debounce_matrix(). Old keyboards can just have debounce_matrix() as an empty function, still using scan_matrix() to do scanning followed by debouncing. This ensures 100% compatability
Cons: Doing this abstraction requires 1 extra copy of the entire matrix is stored.
Pros: We can have community shared debounce algorithms. Some that have been discussed multiple times are EAGER algorithms, Per-Key algorithms, and a combination of both. We could also still use the current algorithm. Changing algorithms would be a one line code change or #define.