Add debounce time description (#20333)

This commit is contained in:
Albert Y 2023-04-04 10:15:00 +08:00 committed by GitHub
parent 1fd30b3391
commit f56cf93fa1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 36 additions and 28 deletions

View File

@ -57,70 +57,78 @@ susceptible to noise, you must choose a debounce method that will also mitigate
if the scanning is slow, and you are using a timestamp-based algorithm, you might end up making a debouncing decision based on only two if the scanning is slow, and you are using a timestamp-based algorithm, you might end up making a debouncing decision based on only two
sampled values, which will limit the noise-resistance of the algorithm. sampled values, which will limit the noise-resistance of the algorithm.
* Currently all built-in debounce algorithms support timestamp-based debouncing only. In the future we might * Currently all built-in debounce algorithms support timestamp-based debouncing only. In the future we might
implement cycles-based debouncing, and it will be selectable via a ```config.h``` macro. implement cycles-based debouncing, and it will be selectable via a `config.h` macro.
2) Symmetric vs Asymmetric 2) Symmetric vs Asymmetric
* Symmetric - apply the same debouncing algorithm, to both key-up and key-down events. * Symmetric - apply the same debouncing algorithm, to both key-up and key-down events.
* Recommended naming convention: ```sym_*``` * Recommended naming convention: `sym_*`
* Asymmetric - apply different debouncing algorithms to key-down and key-up events. E.g. Eager key-down, Defer key-up. * Asymmetric - apply different debouncing algorithms to key-down and key-up events. E.g. Eager key-down, Defer key-up.
* Recommended naming convention: ```asym_*``` followed by details of the type of algorithm in use, in order, for key-down and then key-up * Recommended naming convention: `asym_*` followed by details of the type of algorithm in use, in order, for key-down and then key-up
3) Eager vs Defer 3) Eager vs Defer
* Eager - any key change is reported immediately. All further inputs for DEBOUNCE ms are ignored. * Eager - any key change is reported immediately. All further inputs for DEBOUNCE ms are ignored.
* Eager algorithms are not noise-resistant. * Eager algorithms are not noise-resistant.
* Recommended naming conventions: * Recommended naming conventions:
* ```sym_eager_*``` * `sym_eager_*`
* ```asym_eager_*_*```: key-down is using eager algorithm * `asym_eager_*_*`: key-down is using eager algorithm
* ```asym_*_eager_*```: key-up is using eager algorithm * `asym_*_eager_*`: key-up is using eager algorithm
* Defer - wait for no changes for DEBOUNCE ms before reporting change. * Defer - wait for no changes for DEBOUNCE ms before reporting change.
* Defer algorithms are noise-resistant * Defer algorithms are noise-resistant
* Recommended naming conventions: * Recommended naming conventions:
* ```sym_defer_*``` * `sym_defer_*`
* ```asym_defer_*_*```: key-down is using defer algorithm * `asym_defer_*_*`: key-down is using defer algorithm
* ```asym_*_defer_*```: key-up is using defer algorithm * `asym_*_defer_*`: key-up is using defer algorithm
4) Global vs Per-Key vs Per-Row 4) Global vs Per-Key vs Per-Row
* Global - one timer for all keys. Any key change state affects global timer * Global - one timer for all keys. Any key change state affects global timer
* Recommended naming convention: ```*_g``` * Recommended naming convention: `*_g`
* Per-key - one timer per key * Per-key - one timer per key
* Recommended naming convention: ```*_pk``` * Recommended naming convention: `*_pk`
* Per-row - one timer per row * Per-row - one timer per row
* Recommended naming convention: ```*_pr``` * Recommended naming convention: `*_pr`
* Per-key and per-row algorithms consume more resources (in terms of performance, * Per-key and per-row algorithms consume more resources (in terms of performance,
and ram usage), but fast typists might prefer them over global. and ram usage), but fast typists might prefer them over global.
## Supported Debounce Algorithms ## Supported Debounce Algorithms
QMK supports multiple debounce algorithms through its debounce API. QMK supports multiple algorithms through its debounce API.
### Debounce selection ### Debounce Time
Keyboards may select one of the core debounce methods by adding the following line into ```rules.mk```: Default debounce time is 5 milliseconds and it can be changed with the following line in `config.h`:
```
#define DEBOUNCE 10
```
?> Setting `DEBOUNCE` to `0` will disable this feature.
### Debounce Method
Keyboards may select one of the core debounce methods by adding the following line into `rules.mk`:
``` ```
DEBOUNCE_TYPE = <name of algorithm> DEBOUNCE_TYPE = <name of algorithm>
``` ```
Name of algorithm is one of: Name of algorithm is one of:
| Algorithm | Description | | Algorithm | Description |
| ------------------------- | ----------- | | --------------------- | ----------- |
| ```sym_defer_g``` | Debouncing per keyboard. On any state change, a global timer is set. When ```DEBOUNCE``` milliseconds of no changes has occurred, all input changes are pushed. This is the highest performance algorithm with lowest memory usage and is noise-resistant. | | `sym_defer_g` | Debouncing per keyboard. On any state change, a global timer is set. When `DEBOUNCE` milliseconds of no changes has occurred, all input changes are pushed. This is the highest performance algorithm with lowest memory usage and is noise-resistant. |
| ```sym_defer_pr``` | Debouncing per row. On any state change, a per-row timer is set. When ```DEBOUNCE``` milliseconds of no changes have occurred on that row, the entire row is pushed. This can improve responsiveness over `sym_defer_g` while being less susceptible to noise than per-key algorithm. | | `sym_defer_pr` | Debouncing per row. On any state change, a per-row timer is set. When `DEBOUNCE` milliseconds of no changes have occurred on that row, the entire row is pushed. This can improve responsiveness over `sym_defer_g` while being less susceptible to noise than per-key algorithm. |
| ```sym_defer_pk``` | Debouncing per key. On any state change, a per-key timer is set. When ```DEBOUNCE``` milliseconds of no changes have occurred on that key, the key status change is pushed. | | `sym_defer_pk` | Debouncing per key. On any state change, a per-key timer is set. When `DEBOUNCE` milliseconds of no changes have occurred on that key, the key status change is pushed. |
| ```sym_eager_pr``` | Debouncing per row. On any state change, response is immediate, followed by ```DEBOUNCE``` milliseconds of no further input for that row. | | `sym_eager_pr` | Debouncing per row. On any state change, response is immediate, followed by `DEBOUNCE` milliseconds of no further input for that row. |
| ```sym_eager_pk``` | Debouncing per key. On any state change, response is immediate, followed by ```DEBOUNCE``` milliseconds of no further input for that key. | | `sym_eager_pk` | Debouncing per key. On any state change, response is immediate, followed by `DEBOUNCE` milliseconds of no further input for that key. |
| ```asym_eager_defer_pk``` | Debouncing per key. On a key-down state change, response is immediate, followed by ```DEBOUNCE``` milliseconds of no further input for that key. On a key-up state change, a per-key timer is set. When ```DEBOUNCE``` milliseconds of no changes have occurred on that key, the key-up status change is pushed. | | `asym_eager_defer_pk` | Debouncing per key. On a key-down state change, response is immediate, followed by `DEBOUNCE` milliseconds of no further input for that key. On a key-up state change, a per-key timer is set. When `DEBOUNCE` milliseconds of no changes have occurred on that key, the key-up status change is pushed. |
?> ```sym_defer_g``` is the default if ```DEBOUNCE_TYPE``` is undefined ?> `sym_defer_g` is the default if `DEBOUNCE_TYPE` is undefined.
?> ```sym_eager_pr``` is suitable for use in keyboards where refreshing ```NUM_KEYS``` 8-bit counters is computationally expensive or has low scan rate while fingers usually hit one row at a time. This could be appropriate for the ErgoDox models where the matrix is rotated 90°. Hence its "rows" are really columns and each finger only hits a single "row" at a time with normal usage. ?> `sym_eager_pr` is suitable for use in keyboards where refreshing `NUM_KEYS` 8-bit counters is computationally expensive or has low scan rate while fingers usually hit one row at a time. This could be appropriate for the ErgoDox models where the matrix is rotated 90°. Hence its "rows" are really columns and each finger only hits a single "row" at a time with normal usage.
### Implementing your own debouncing code ### Implementing your own debouncing code
You have the option to implement you own debouncing algorithm with the following steps: You have the option to implement you own debouncing algorithm with the following steps:
* Set ```DEBOUNCE_TYPE = custom``` in ```rules.mk```. * Set `DEBOUNCE_TYPE = custom` in `rules.mk`.
* Add ```SRC += debounce.c``` in ```rules.mk``` * Add `SRC += debounce.c` in `rules.mk`
* Implement your own ```debounce.c```. See ```quantum/debounce``` for examples. * Implement your own `debounce.c`. See `quantum/debounce` for examples.
* Debouncing occurs after every raw matrix scan. * Debouncing occurs after every raw matrix scan.
* Use num_rows instead of MATRIX_ROWS to support split keyboards correctly. * Use num_rows instead of MATRIX_ROWS to support split keyboards correctly.
* If your custom algorithm is applicable to other keyboards, please consider making a pull request. * If your custom algorithm is applicable to other keyboards, please consider making a pull request.