diff options
author | Drashna Jaelre <drashna@live.com> | 2019-04-05 12:47:25 -0700 |
---|---|---|
committer | Jack Humbert <jack.humb@gmail.com> | 2019-04-05 15:47:25 -0400 |
commit | 5701b75e3c10728d424ec058d26ef2e354aba0c0 (patch) | |
tree | 979b01e8226d5fb33789bd1c41853c8412bfa669 /docs/custom_quantum_functions.md | |
parent | 4c1760883e2e0ed710348f02bc791786ed0c1b04 (diff) | |
download | qmk_firmware-5701b75e3c10728d424ec058d26ef2e354aba0c0.tar.gz qmk_firmware-5701b75e3c10728d424ec058d26ef2e354aba0c0.zip |
Custom Tapping Term per key (#5009)
* Add customizable tapping terms
* Add Documentation
* Fix function
* Fixes
* It's not a pointer
* Add debugging output
* Update documentation to be at least vaguely accurate
* Use `get_tapping_term(tapping_key.event)` instead
`e` doesn't include column and row information, properly. It registers as 255, regardless of the actual keypress.
However `tapping_key.event` actually gives the correct column and row information. It appears be the correct structure to use.
In fact, it looks like the issue is that `e` is actually the "TICK" structure, as defined in keyboard.h
* Use variable tapping term value rather than define
* Silly drashna - tapping_key.event, not event
* add get_event_keycode() function
* Fix typo
Co-Authored-By: drashna <drashna@live.com>
* Remove post_process_record_quantum since it's the wrong PR
* Update quantum/quantum.c
Co-Authored-By: drashna <drashna@live.com>
* Better handle ifdef statement for permissive hold
Since we can't be sure that tapping term is actually 500
* Update quantum.c comments based on feedback
* Clean up get_tapping_term function
Clean up function so that users don't need to call the event function, and instead only check the keycode
* Add ability to run functionality on and off
* Make ifdef's more compact
Diffstat (limited to 'docs/custom_quantum_functions.md')
-rw-r--r-- | docs/custom_quantum_functions.md | 29 |
1 files changed, 29 insertions, 0 deletions
diff --git a/docs/custom_quantum_functions.md b/docs/custom_quantum_functions.md index 418faf3494..6287b95309 100644 --- a/docs/custom_quantum_functions.md +++ b/docs/custom_quantum_functions.md @@ -323,6 +323,7 @@ uint32_t layer_state_set_user(uint32_t state) { * Keyboard/Revision: `uint32_t layer_state_set_kb(uint32_t state)` * Keymap: `uint32_t layer_state_set_user(uint32_t state)` + The `state` is the bitmask of the active layers, as explained in the [Keymap Overview](keymap.md#keymap-layer-status) @@ -460,3 +461,31 @@ And you're done. The RGB layer indication will only work if you want it to. And * Keymap: `void eeconfig_init_user(void)`, `uint32_t eeconfig_read_user(void)` and `void eeconfig_update_user(uint32_t val)` The `val` is the value of the data that you want to write to EEPROM. And the `eeconfig_read_*` function return a 32 bit (DWORD) value from the EEPROM. + +# Custom Tapping Term + +By default, the tapping term is defined globally, and is not configurable by key. For most users, this is perfectly fine. But in come cases, dual function keys would be greatly improved by different timeouts than `LT` keys, or because some keys may be easier to hold than others. Instead of using custom key codes for each, this allows for per key configurable `TAPPING_TERM`. + +To enable this functionality, you need to add `#define TAPPING_TERM_PER_KEY` to your `config.h`, first. + + +## Example `get_tapping_term` Implementation + +To change the `TAPPING TERM` based on the keycode, you'd want to add something like the following to your `keymap.c` file: + +```c +uint16_t get_tapping_term(uint16_t keycode) { + switch (keycode) { + case SFT_T(KC_SPC): + return TAPPING_TERM + 1250; + case LT(1, KC_GRV): + return 130; + default: + return TAPPING_TERM; + } +} +``` + +### `get_tapping_term` Function Documentation + +Unlike many of the other functions here, there isn't a need (or even reason) to have a quantum or keyboard level function. Only a user level function is useful here, so no need to mark it as such. |