diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/config_options.md | 2 | ||||
| -rw-r--r-- | docs/keycodes.md | 10 | ||||
| -rw-r--r-- | docs/tap_hold.md | 80 | ||||
| -rw-r--r-- | docs/understanding_qmk.md | 1 |
4 files changed, 92 insertions, 1 deletions
diff --git a/docs/config_options.md b/docs/config_options.md index 9f2453b698..b661b55ee0 100644 --- a/docs/config_options.md +++ b/docs/config_options.md @@ -448,6 +448,8 @@ Use these to enable or disable building certain features. The more you have enab * Disables usb suspend check after keyboard startup. Usually the keyboard waits for the host to wake it up before any tasks are performed. This is useful for split keyboards as one half will not get a wakeup call but must send commands to the master. * `DEFERRED_EXEC_ENABLE` * Enables deferred executor support -- timed delays before callbacks are invoked. See [deferred execution](custom_quantum_functions.md#deferred-execution) for more information. +* `DYNAMIC_TAPPING_TERM_ENABLE` + * Allows to configure the global tapping term on the fly. ## USB Endpoint Limitations diff --git a/docs/keycodes.md b/docs/keycodes.md index 926d4fdcef..ba06e1b8b6 100644 --- a/docs/keycodes.md +++ b/docs/keycodes.md @@ -586,6 +586,16 @@ See also: [Mod-Tap](mod_tap.md) |`MEH_T(kc)` | |Left Control, Shift and Alt when held, `kc` when tapped | |`HYPR_T(kc)` |`ALL_T(kc)` |Left Control, Shift, Alt and GUI when held, `kc` when tapped - more info [here](https://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/)| +## Tapping Term Keys :id=tapping-term-keys + +See also: [Dynamic Tapping Term](tap_hold#dynamic-tapping-term) + +| Key | Description | +|-------------|------------------------------------------------------------------------------------------------------------------------| +| `DT_PRNT` | "Dynamic Tapping Term Print": Types the current tapping term, in milliseconds | +| `DT_UP` | "Dynamic Tapping Term Up": Increases the current tapping term by `DYNAMIC_TAPPING_TERM_INCREMENT`ms (5ms by default) | +| `DT_DOWN` | "Dynamic Tapping Term Down": Decreases the current tapping term by `DYNAMIC_TAPPING_TERM_INCREMENT`ms (5ms by default) | + ## RGB Lighting :id=rgb-lighting See also: [RGB Lighting](feature_rgblight.md) diff --git a/docs/tap_hold.md b/docs/tap_hold.md index a343d0bc3e..d206c10cc5 100644 --- a/docs/tap_hold.md +++ b/docs/tap_hold.md @@ -6,7 +6,9 @@ These options let you modify the behavior of the Tap-Hold keys. ## Tapping Term -The crux of all of the following features is the tapping term setting. This determines what is a tap and what is a hold. And the exact timing for this to feel natural can vary from keyboard to keyboard, from switch to switch, and from key to key. +The crux of all of the following features is the tapping term setting. This determines what is a tap and what is a hold. The exact timing for this to feel natural can vary from keyboard to keyboard, from switch to switch, and from key to key. + +?> `DYNAMIC_TAPPING_TERM_ENABLE` enables three special keys that can help you quickly find a comfortable tapping term for you. See "Dynamic Tapping Term" for more details. You can set the global time for this by adding the following setting to your `config.h`: @@ -36,6 +38,82 @@ uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record) { } ``` +### Dynamic Tapping Term :id=dynamic-tapping-term + +`DYNAMIC_TAPPING_TERM_ENABLE` is a feature you can enable in `rules.mk` that lets you use three special keys in your keymap to configure the tapping term on the fly. + +| Key | Description | +|-------------|------------------------------------------------------------------------------------------------------------------------| +| `DT_PRNT` | "Dynamic Tapping Term Print": Types the current tapping term, in milliseconds | +| `DT_UP` | "Dynamic Tapping Term Up": Increases the current tapping term by `DYNAMIC_TAPPING_TERM_INCREMENT`ms (5ms by default) | +| `DT_DOWN` | "Dynamic Tapping Term Down": Decreases the current tapping term by `DYNAMIC_TAPPING_TERM_INCREMENT`ms (5ms by default) | + +Set the tapping term as usual with `#define TAPPING_TERM <value>` in `config.h` and add `DYNAMIC_TAPPING_TERM_ENABLE = yes` in `rules.mk`. Then, place the above three keys somewhere in your keymap and flash the new firmware onto your board. + +Now, you can try using your dual-role keys, such as layer-taps and mod-taps, and use `DT_DOWN` and `DT_UP` to adjust the tapping term immediately. If you find that you frequently trigger the modifier of your mod-tap(s) by accident for example, that's a sign that your tapping term may be too low so tap `DT_UP` a few times to increase the tapping term until that no longer happens. On the flip side, if you get superfluous characters when you actually intended to momentarily activate a layer, tap `DT_DOWN` to lower the tapping term. Do note that these keys affect the *global* tapping term, you cannot change the tapping term of a specific key on the fly. + +Once you're satisfied with the current tapping term value, open `config.h` and replace whatever value you first wrote for the tapping term by the output of the `DT_PRNT` key. + +It's important to update `TAPPING_TERM` with the new value because the adjustments made using `DT_UP` and `DT_DOWN` are not persistent. + +The value by which the tapping term increases or decreases when you tap `DT_UP` and `DT_DOWN` can be configured in `config.h` with `#define DYNAMIC_TAPPING_TERM_INCREMENT <new value>`. Note that the tapping term is *not* modified when holding down the tap term keys so if you need to, for example, decrease the current tapping term by 50ms, you cannot just press down and hold `DT_DOWN`; you will have to tap it 10 times in a row with the default increment of 5ms. + +If you need more flexibility, nothing prevents you from defining your own custom keys to dynamically change the tapping term. + +```c +enum custom_dynamic_tapping_term_keys = { + DT_UP_50 = SAFE_RANGE, + DT_DOWN_50, + DT_UP_X2, + DT_DOWN_X2, +} + +bool process_record_user(uint16_t keycode, keyrecord_t *record) { + switch (keycode) { + case DT_UP_50: + if (record->event.pressed) { + g_tapping_term += 50; + } + break; + case DT_DOWN_50: + if (record->event.pressed) { + g_tapping_term -= 50; + } + break; + case DT_UP_X2: + if (record->event.pressed) { + g_tapping_term *= 2; + } + break; + case DT_DOWN_X2: + if (record->event.pressed) { + g_tapping_term /= 2; + } + break; + } + return true; +}; +``` + +In order for this feature to be effective if you use per-key tapping terms, you need to make a few changes to the syntax of the `get_tapping_term` function. All you need to do is replace every occurrence of `TAPPING_TERM` in the `get_tapping_term` function by lowercase `g_tapping_term`. If you don't do that, you will still see the value typed by `DT_PRNT` go up and down as you configure the tapping term on the fly but you won't feel those changes as they don't get applied. If you can go as low as 10ms and still easily trigger the tap function of a dual-role key, that's a sign that you forgot to make the necessary changes to your `get_tapping_term` function. + +For instance, here's how the example `get_tapping_term` shown earlier should look like after the transformation: + +```c +uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record) { + switch (keycode) { + case SFT_T(KC_SPC): + return g_tapping_term + 1250; + case LT(1, KC_GRV): + return 130; + default: + return g_tapping_term; + } +} +``` + +The reason being that `TAPPING_TERM` is a macro that expands to a constant integer and thus cannot be changed at runtime whereas `g_tapping_term` is a variable whose value can be changed at runtime. If you want, you can temporarily enable `DYNAMIC_TAPPING_TERM_ENABLE` to find a suitable tapping term value and then disable that feature and revert back to using the classic syntax for per-key tapping term settings. + ## Tap-Or-Hold Decision Modes The code which decides between the tap and hold actions of dual-role keys supports three different modes, in increasing order of preference for the hold action: diff --git a/docs/understanding_qmk.md b/docs/understanding_qmk.md index e0c2ab7dc3..016e3d9fd2 100644 --- a/docs/understanding_qmk.md +++ b/docs/understanding_qmk.md @@ -157,6 +157,7 @@ The `process_record()` function itself is deceptively simple, but hidden within * [`bool process_combo(uint16_t keycode, keyrecord_t *record)`](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/process_keycode/process_combo.c#L115) * [`bool process_printer(uint16_t keycode, keyrecord_t *record)`](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/process_keycode/process_printer.c#L77) * [`bool process_auto_shift(uint16_t keycode, keyrecord_t *record)`](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/process_keycode/process_auto_shift.c#L94) + * `bool process_dynamic_tapping_term(uint16_t keycode, keyrecord_t *record)` * [`bool process_terminal(uint16_t keycode, keyrecord_t *record)`](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/process_keycode/process_terminal.c#L264) * [Identify and process Quantum-specific keycodes](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/quantum.c#L291) |