Rather than debouncing being different for each keyboard, would it make more sense for matrix_scan() to just write out the raw values, and then we call debounce_matrix(raw_values, &final_values) to calculate final values? That way we can write generic debounce algorithms.
We can then use compile defines to choose which debounce algorithm we want. So far looking inside the keyboards folder there are only two algorithms:
whole keyboard debouncing blocking - when tehre is no action for 5ms, writes from current -> final. Sleeps 1ms a whole bunch.
if (debouncing) {
if (--debouncing) {
_delay_ms(1);
} else {
for (uint8_t i = 0; i < MATRIX_ROWS; i++) {
matrix[i] = matrix_debouncing[i];
}
}
}
whole keyboard debouncing, non-blocking.
if (debouncing && timer_elapsed(debouncing_time) > DEBOUNCE) {
for (int i = 0; i < MATRIX_ROWS; i++) {
matrix[i] = matrix_debouncing[i];
}
debouncing = false;
}
Abstracting the debouncing out one level will involve storing an additional copy of the state though.
Currently 2 copies -
raw_matrix is not stored, and only exists as each row is iterated.
debounced_matrix,
final_matrix,
With generic debouncing:
raw_matrix - gets passed to debounce function
debounce_matrix - controlled by debounce implementation
final_matrix - debounce implementation writes to this.
After abstraction we are able to do more complicated debouncing - for example, a timer for each key, or a timer for each row to make debouncing more accurate. We could also do zero debounce on key_press so that we save 5ms of input delay or even have non-symmetric debounce times. At the moment if you press > two keys within 5 milliseconds of each other, they will be both reported pressed at the same time.
I'm happy to start doing the legwork for this change, just want to know what people think.
Rather than debouncing being different for each keyboard, would it make more sense for matrix_scan() to just write out the raw values, and then we call debounce_matrix(raw_values, &final_values) to calculate final values? That way we can write generic debounce algorithms.
We can then use compile defines to choose which debounce algorithm we want. So far looking inside the keyboards folder there are only two algorithms:
Abstracting the debouncing out one level will involve storing an additional copy of the state though. Currently 2 copies -
With generic debouncing:
After abstraction we are able to do more complicated debouncing - for example, a timer for each key, or a timer for each row to make debouncing more accurate. We could also do zero debounce on key_press so that we save 5ms of input delay or even have non-symmetric debounce times. At the moment if you press > two keys within 5 milliseconds of each other, they will be both reported pressed at the same time.
I'm happy to start doing the legwork for this change, just want to know what people think.