From c952458c780baf425d3717e29f8004486b5637e8 Mon Sep 17 00:00:00 2001 From: Joel Challis Date: Wed, 30 Nov 2022 04:27:21 +0000 Subject: DD bootmagic config (#19201) * DD bootmagic config * Also enable * docs --- docs/reference_info_json.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'docs') diff --git a/docs/reference_info_json.md b/docs/reference_info_json.md index d5469c835a..2da67668c0 100644 --- a/docs/reference_info_json.md +++ b/docs/reference_info_json.md @@ -333,3 +333,24 @@ Example: } } ``` + +## Bootmagic + +This section configures [Bootmagic Lite](feature_bootmagic.md) support. + +The following options can be configured: + +|Key |Description | +|---------|-----------------------------------------------------------------------------| +|`matrix` | A two item list describing the row and column location for the trigger key. | + +Example: + +```json +{ + "bootmagic": { + "enabled": true, + "matrix": [0, 0] + }, +} +``` \ No newline at end of file -- cgit v1.2.3 From 32dabd5320b2914bb5631bd6f95b8cd7ca4419e7 Mon Sep 17 00:00:00 2001 From: Joel Challis Date: Sat, 3 Dec 2022 12:04:06 +0000 Subject: Align new-keymap with new-keyboard (#19229) --- docs/newbs_building_firmware.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/newbs_building_firmware.md b/docs/newbs_building_firmware.md index 6163c6b02e..de9217e9f0 100644 --- a/docs/newbs_building_firmware.md +++ b/docs/newbs_building_firmware.md @@ -28,7 +28,7 @@ If you did not configure your environment, or you have multiple keyboards, you c Look at the output from that command, you should see something like this: - Ψ keymap directory created in: /home/me/qmk_firmware/keyboards/clueboard/66/rev3/keymaps/ + Ψ Created a new keymap called in: /home/me/qmk_firmware/keyboards/clueboard/66/rev3/keymaps/. This is the location of your new `keymap.c` file. -- cgit v1.2.3 From 53423f0369af2c0b07a9f85812fcea335270c060 Mon Sep 17 00:00:00 2001 From: ForsakenRei <23041178+ForsakenRei@users.noreply.github.com> Date: Thu, 8 Dec 2022 11:03:33 -0500 Subject: KC_GESC -> QK_GESC for cn and ja Docs (#19024) --- docs/ja/feature_grave_esc.md | 4 ++-- docs/zh-cn/feature_grave_esc.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) (limited to 'docs') diff --git a/docs/ja/feature_grave_esc.md b/docs/ja/feature_grave_esc.md index 8c6680d74d..746e9e5d14 100644 --- a/docs/ja/feature_grave_esc.md +++ b/docs/ja/feature_grave_esc.md @@ -9,7 +9,7 @@ ## 使用法 -キーマップ内の `KC_GRAVE` キー (通常は`1` キーの左)を `KC_GESC` に置き換えます。ほとんどの場合、このキーは押された時に `KC_ESC` を出力します。ただし、Shift あるいは GUI を押したままにすると、代わりに `KC_GRV` を出力します。 +キーマップ内の `KC_GRAVE` キー (通常は`1` キーの左)を `QK_GESC` に置き換えます。ほとんどの場合、このキーは押された時に `KC_ESC` を出力します。ただし、Shift あるいは GUI を押したままにすると、代わりに `KC_GRV` を出力します。 ## OS に見えるもの @@ -19,7 +19,7 @@ | キー | エイリアス | 説明 | |---------|-----------|------------------------------------------------------------------| -| `KC_GESC` | `GRAVE_ESC` | 押された場合に Escape。Shift あるいは GUI が押されたままの場合は ` | +| `QK_GESC` | `GRAVE_ESC` | 押された場合に Escape。Shift あるいは GUI が押されたままの場合は ` | ### 注意事項 diff --git a/docs/zh-cn/feature_grave_esc.md b/docs/zh-cn/feature_grave_esc.md index f57dabeaff..1795a508ef 100644 --- a/docs/zh-cn/feature_grave_esc.md +++ b/docs/zh-cn/feature_grave_esc.md @@ -11,7 +11,7 @@ ## 使用方法 -在配列中使用 `KC_GESC` 替换 `KC_GRAVE` （一般都在`1`键左边）。默认点击会输出 `KC_ESC`，按下Shift或GUI键时，点击会输出 `KC_GRV` +在配列中使用 `QK_GESC` 替换 `KC_GRAVE` （一般都在`1`键左边）。默认点击会输出 `KC_ESC`，按下Shift或GUI键时，点击会输出 `KC_GRV` ## 操作系统视角 @@ -21,7 +21,7 @@ |键 |别名 |描述 | |---------|-----------|------------------------------------------------------------------| -|`KC_GESC`|`GRAVE_ESC`|单击输出Escape, 按住Shift或GUI时输出` | +|`QK_GESC`|`GRAVE_ESC`|单击输出Escape, 按住Shift或GUI时输出` | ### 须留意 -- cgit v1.2.3 From f2a8a13dbad220cfb0dfbd72a90492a15a2e58bb Mon Sep 17 00:00:00 2001 From: dexter93 Date: Thu, 8 Dec 2022 18:09:01 +0200 Subject: Core: Support inverted scan logic for optical switches (#19053) --- docs/porting_your_keyboard_to_qmk.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'docs') diff --git a/docs/porting_your_keyboard_to_qmk.md b/docs/porting_your_keyboard_to_qmk.md index 484d079ea6..05054e25c7 100644 --- a/docs/porting_your_keyboard_to_qmk.md +++ b/docs/porting_your_keyboard_to_qmk.md @@ -94,6 +94,18 @@ The next section of the `info` file deals with your keyboard's matrix. The first The size of the `matrix_pins.cols` and `matrix_pins.rows` arrays infer the size of the matrix (previously `MATRIX_ROWS` and `MATRIX_COLS`). +## Configuration Options + +To invert the keypress logic, configure `input_pressed_state`: + +```json + "matrix_pins": { + "input_pressed_state": 1, +}, +``` + +This configures state of the GPIO pins when the key is pressed - `1` for high, `0` for low. Default value is `0`. + Finally, you can specify the direction your diodes point. This can be `COL2ROW` or `ROW2COL`. ```json -- cgit v1.2.3 From 85ee55ff3becd29e1590376c3462c6a99c976fa0 Mon Sep 17 00:00:00 2001 From: Ruslan Sayfutdinov Date: Thu, 8 Dec 2022 16:45:30 +0000 Subject: Detect host OS based on USB fingerprint (#18463) Co-authored-by: Drashna Jaelre Co-authored-by: Nick Brassel --- docs/_summary.md | 1 + docs/feature_os_detection.md | 77 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 78 insertions(+) create mode 100644 docs/feature_os_detection.md (limited to 'docs') diff --git a/docs/_summary.md b/docs/_summary.md index 738c24ee42..d388d08391 100644 --- a/docs/_summary.md +++ b/docs/_summary.md @@ -85,6 +85,7 @@ * [Key Overrides](feature_key_overrides.md) * [Layers](feature_layers.md) * [One Shot Keys](one_shot_keys.md) + * [OS Detection](feature_os_detection.md) * [Raw HID](feature_rawhid.md) * [Secure](feature_secure.md) * [Send String](feature_send_string.md) diff --git a/docs/feature_os_detection.md b/docs/feature_os_detection.md new file mode 100644 index 0000000000..f32e419807 --- /dev/null +++ b/docs/feature_os_detection.md @@ -0,0 +1,77 @@ +# OS Detection + +This feature makes a best guess at the host OS based on OS specific behavior during USB setup. It may not always get the correct OS, and shouldn't be relied on as for critical functionality. + +Using it you can have OS specific key mappings or combos which work differently on different devices. + +It is available for keyboards which use ChibiOS, LUFA and V-USB. + +## Usage + +In your `rules.mk` add: + +```make +OS_DETECTION_ENABLE = yes +``` + +Include `"os_detection.h"` in your `keymap.c`. +It declares `os_variant_t detected_host_os(void);` which you can call to get detected OS. + +It returns one of the following values: + +```c +enum { + OS_UNSURE, + OS_LINUX, + OS_WINDOWS, + OS_MACOS, + OS_IOS, +} os_variant_t; +``` + +?> Note that it takes some time after firmware is booted to detect the OS. +This time is quite short, probably hundreds of milliseconds, but this data may be not ready in keyboard and layout setup functions which run very early during firmware startup. + +## Debug + +If OS is guessed incorrectly, you may want to collect data about USB setup packets to refine the detection logic. + +To do so in your `rules.mk` add: + +```make +OS_DETECTION_DEBUG_ENABLE = yes +CONSOLE_ENABLE = yes +``` + +And also include `"os_detection.h"` in your `keymap.c`. + +Then you can define custom keycodes to store data about USB setup packets in EEPROM (persistent memory) and to print it later on host where you can run `qmk console`: + +```c +enum custom_keycodes { + STORE_SETUPS = SAFE_RANGE, + PRINT_SETUPS, +}; + +bool process_record_user(uint16_t keycode, keyrecord_t *record) { + switch (keycode) { + case STORE_SETUPS: + if (record->event.pressed) { + store_setups_in_eeprom(); + } + return false; + case PRINT_SETUPS: + if (record->event.pressed) { + print_stored_setups(); + } + return false; + } +} +``` + +Then please open an issue on Github with this information and tell what OS was not detected correctly and if you have any intermediate devices between keyboard and your computer. + + +## Credits + +Original idea is coming from [FingerprintUSBHost](https://github.com/keyboardio/FingerprintUSBHost) project. -- cgit v1.2.3 From 6133b08e73813c19bca8934a44c41c7c2d297a71 Mon Sep 17 00:00:00 2001 From: Joel Challis Date: Thu, 8 Dec 2022 20:41:38 +0000 Subject: Rework input_pressed_state docs (#19267) * Revert changes to porting * Update reference_info_json.md --- docs/porting_your_keyboard_to_qmk.md | 12 ------------ docs/reference_info_json.md | 16 +++++++++++++++- 2 files changed, 15 insertions(+), 13 deletions(-) (limited to 'docs') diff --git a/docs/porting_your_keyboard_to_qmk.md b/docs/porting_your_keyboard_to_qmk.md index 05054e25c7..484d079ea6 100644 --- a/docs/porting_your_keyboard_to_qmk.md +++ b/docs/porting_your_keyboard_to_qmk.md @@ -94,18 +94,6 @@ The next section of the `info` file deals with your keyboard's matrix. The first The size of the `matrix_pins.cols` and `matrix_pins.rows` arrays infer the size of the matrix (previously `MATRIX_ROWS` and `MATRIX_COLS`). -## Configuration Options - -To invert the keypress logic, configure `input_pressed_state`: - -```json - "matrix_pins": { - "input_pressed_state": 1, -}, -``` - -This configures state of the GPIO pins when the key is pressed - `1` for high, `0` for low. Default value is `0`. - Finally, you can specify the direction your diodes point. This can be `COL2ROW` or `ROW2COL`. ```json diff --git a/docs/reference_info_json.md b/docs/reference_info_json.md index 2da67668c0..354863f507 100644 --- a/docs/reference_info_json.md +++ b/docs/reference_info_json.md @@ -113,6 +113,20 @@ Example: } ``` +### Additional Options + +* `input_pressed_state` + * This configures state of the GPIO pins when the key is pressed - `1` for high, `0` for low + * Default: `0` + +Example: + +```json + "matrix_pins": { + "input_pressed_state": 1, +}, +``` + ## Non-RGB LED Lighting This section controls basic 2-pin LEDs, which typically pass through keyswitches and are soldered into the PCB, or are placed in PCB sockets. @@ -353,4 +367,4 @@ Example: "matrix": [0, 0] }, } -``` \ No newline at end of file +``` -- cgit v1.2.3 From d9cba6e978b60d67b00b5f868cf321d2d48e5fc9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pablo=20Mart=C3=ADnez?= <58857054+elpekenin@users.noreply.github.com> Date: Sat, 10 Dec 2022 03:18:40 +0100 Subject: Add `*_RIGHT` configuration for PMW33XX driver (#19243) --- docs/feature_pointing_device.md | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) (limited to 'docs') diff --git a/docs/feature_pointing_device.md b/docs/feature_pointing_device.md index be984dd5a5..ecb7ee42cb 100644 --- a/docs/feature_pointing_device.md +++ b/docs/feature_pointing_device.md @@ -22,11 +22,11 @@ POINTING_DEVICE_DRIVER = adns5050 The ADNS 5050 sensor uses a serial type protocol for communication, and requires an additional light source. -| Setting | Description | Default | -| ------------------- | ------------------------------------------------------------------- | -------------------------- | -| `ADNS5050_SCLK_PIN` | (Required) The pin connected to the clock pin of the sensor. | `POINTING_DEVICE_SCLK_PIN` | -| `ADNS5050_SDIO_PIN` | (Required) The pin connected to the data pin of the sensor. | `POINTING_DEVICE_SDIO_PIN` | -| `ADNS5050_CS_PIN` | (Required) The pin connected to the cable select pin of the sensor. | `POINTING_DEVICE_CS_PIN` | +| Setting | Description | Default | +| ------------------- | ------------------------------------------------------------------ | -------------------------- | +| `ADNS5050_SCLK_PIN` | (Required) The pin connected to the clock pin of the sensor. | `POINTING_DEVICE_SCLK_PIN` | +| `ADNS5050_SDIO_PIN` | (Required) The pin connected to the data pin of the sensor. | `POINTING_DEVICE_SDIO_PIN` | +| `ADNS5050_CS_PIN` | (Required) The pin connected to the Chip Select pin of the sensor. | `POINTING_DEVICE_CS_PIN` | @@ -48,7 +48,7 @@ The ADNS 9800 is an SPI driven optical sensor, that uses laser output for surfac | `ADNS9800_SPI_LSBFIRST` | (Optional) Sets the Least/Most Significant Byte First setting for SPI. | `false` | | `ADNS9800_SPI_MODE` | (Optional) Sets the SPI Mode for the sensor. | `3` | | `ADNS9800_SPI_DIVISOR` | (Optional) Sets the SPI Divisor used for SPI communication. | _varies_ | -| `ADNS9800_CS_PIN` | (Required) Sets the Cable Select pin connected to the sensor. | `POINTING_DEVICE_CS_PIN` | +| `ADNS9800_CS_PIN` | (Required) Sets the Chip Select pin connected to the sensor. | `POINTING_DEVICE_CS_PIN` | The CPI range is 800-8200, in increments of 200. Defaults to 1800 CPI. @@ -124,7 +124,7 @@ Default attenuation is set to 4X, although if you are using a thicker overlay (s | `CIRQUE_PINNACLE_SPI_LSBFIRST` | (Optional) Sets the Least/Most Significant Byte First setting for SPI. | `false` | | `CIRQUE_PINNACLE_SPI_MODE` | (Optional) Sets the SPI Mode for the sensor. | `1` | | `CIRQUE_PINNACLE_SPI_DIVISOR` | (Optional) Sets the SPI Divisor used for SPI communication. | _varies_ | -| `CIRQUE_PINNACLE_SPI_CS_PIN` | (Required) Sets the Cable Select pin connected to the sensor. | `POINTING_DEVICE_CS_PIN` | +| `CIRQUE_PINNACLE_SPI_CS_PIN` | (Required) Sets the Chip Select pin connected to the sensor. | `POINTING_DEVICE_CS_PIN` | Default Scaling is 1024. Actual CPI depends on trackpad diameter. @@ -218,11 +218,14 @@ POINTING_DEVICE_DRIVER = pmw3389 The CPI range is 50-16000, in increments of 50. Defaults to 2000 CPI. Both PMW 3360 and PMW 3389 are SPI driven optical sensors, that use a built in IR LED for surface tracking. +If you have different CS wiring on each half you can use `PMW33XX_CS_PIN_RIGHT` or `PMW33XX_CS_PINS_RIGHT` in combination with `PMW33XX_CS_PIN` or `PMW33XX_CS_PINS` to configure both sides independently. If `_RIGHT` values aren't provided, they default to be the same as the left ones. | Setting | Description | Default | | ---------------------------- | ------------------------------------------------------------------------------------------- | ------------------------ | -| `PMW33XX_CS_PIN` | (Required) Sets the Cable Select pin connected to the sensor. | `POINTING_DEVICE_CS_PIN` | -| `PMW33XX_CS_PINS` | (Alternative) Sets the Cable Select pins connected to multiple sensors. | _not defined_ | +| `PMW33XX_CS_PIN` | (Required) Sets the Chip Select pin connected to the sensor. | `POINTING_DEVICE_CS_PIN` | +| `PMW33XX_CS_PINS` | (Alternative) Sets the Chip Select pins connected to multiple sensors. | `{PMW33XX_CS_PIN}` | +| `PMW33XX_CS_PIN_RIGHT` | (Optional) Sets the Chip Select pin connected to the sensor on the right half. | `PMW33XX_CS_PIN` | +| `PMW33XX_CS_PINS_RIGHT` | (Optional) Sets the Chip Select pins connected to multiple sensors on the right half. | `{PMW33XX_CS_PIN_RIGHT}` | | `PMW33XX_CPI` | (Optional) Sets counts per inch sensitivity of the sensor. | _varies_ | | `PMW33XX_CLOCK_SPEED` | (Optional) Sets the clock speed that the sensor runs at. | `2000000` | | `PMW33XX_SPI_DIVISOR` | (Optional) Sets the SPI Divisor used for SPI communication. | _varies_ | -- cgit v1.2.3 From 9dc3f791965e4c54bc969dcc2f2c7597f59e2262 Mon Sep 17 00:00:00 2001 From: Stefan Kerkmann Date: Sun, 11 Dec 2022 14:04:29 +0100 Subject: [RP2040] update i2c drivers to reflect peripheral number (#19277) --- docs/platformdev_rp2040.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'docs') diff --git a/docs/platformdev_rp2040.md b/docs/platformdev_rp2040.md index 3a6f1a1683..11a93edd89 100644 --- a/docs/platformdev_rp2040.md +++ b/docs/platformdev_rp2040.md @@ -38,8 +38,8 @@ QMK RP2040 support builds upon ChibiOS and thus follows their convention for act | RP2040 Peripheral | `mcuconf.h` values | `I2C_DRIVER` | | ----------------- | ------------------ | ------------ | -| `I2C0` | `RP_I2C_USE_I2C0` | `I2CD1` | -| `I2C1` | `RP_I2C_USE_I2C1` | `I2CD2` | +| `I2C0` | `RP_I2C_USE_I2C0` | `I2CD0` | +| `I2C1` | `RP_I2C_USE_I2C1` | `I2CD1` | To configure the I2C driver please read the [ChibiOS/ARM](i2c_driver.md#arm-configuration) section. @@ -74,7 +74,7 @@ This is the default board that is chosen, unless any other RP2040 board is selec | Driver configuration define | Value | | -------------------------------------------------------------------------- | ------------------------------------ | | **I2C driver** | | -| `I2C_DRIVER` | `I2CD2` | +| `I2C_DRIVER` | `I2CD1` | | `I2C1_SDA_PIN` | `GP2` | | `I2C1_SCL_PIN` | `GP3` | | **SPI driver** | | -- cgit v1.2.3 From cbabc8dbe6a8476d3082e8bc649d330f87e7b904 Mon Sep 17 00:00:00 2001 From: Albert Y <76888457+filterpaper@users.noreply.github.com> Date: Mon, 12 Dec 2022 23:52:22 +0800 Subject: [Core] Replace Tapping Force Hold feature with Quick Tap Term (#17007) * Replace Tapping Force Hold feature with Quick Tap Term * Replace keyboard level TAPPING_FORCE_HOLD with QUICK_TAP_TERM 0 * Deprecate force hold in info_config.json * Before and after quick tap term unit tests * Quick tap unit tests iteration * Keymap config.h correction * Remove TAPPING_FORCE_HOLD_PER_KEY macros that were missed * Add two more test cases for quick tap * Replace TAPPING_FORCE_HOLD with QUICK_TAP_TERM in configs #2 * Replace TAPPING_FORCE_HOLD_PER_KEY with QUICK_TAP_TERM_PER_KEY in configs #2 * Add function declaration for get_quick_tap_term Co-authored-by: Stefan Kerkmann --- docs/config_options.md | 13 +++++++------ docs/tap_hold.md | 31 ++++++++++++++++--------------- 2 files changed, 23 insertions(+), 21 deletions(-) (limited to 'docs') diff --git a/docs/config_options.md b/docs/config_options.md index 6b1f83214c..edaa739201 100644 --- a/docs/config_options.md +++ b/docs/config_options.md @@ -171,12 +171,13 @@ If you define these options you will enable the associated feature, which may in * See [Ignore Mod Tap Interrupt](tap_hold.md#ignore-mod-tap-interrupt) for details * `#define IGNORE_MOD_TAP_INTERRUPT_PER_KEY` * enables handling for per key `IGNORE_MOD_TAP_INTERRUPT` settings -* `#define TAPPING_FORCE_HOLD` - * makes it possible to use a dual role key as modifier shortly after having been tapped - * See [Tapping Force Hold](tap_hold.md#tapping-force-hold) - * Breaks any Tap Toggle functionality (`TT` or the One Shot Tap Toggle) -* `#define TAPPING_FORCE_HOLD_PER_KEY` - * enables handling for per key `TAPPING_FORCE_HOLD` settings +* `#define QUICK_TAP_TERM 100` + * tap-then-hold timing to use a dual role key to repeat keycode + * See [Quick Tap Term](tap_hold.md#quick-tap-term) + * Changes the timing of Tap Toggle functionality (`TT` or the One Shot Tap Toggle) + * Defaults to `TAPPING_TERM` if not defined +* `#define QUICK_TAP_TERM_PER_KEY` + * enables handling for per key `QUICK_TAP_TERM` settings * `#define LEADER_TIMEOUT 300` * how long before the leader key times out * If you're having issues finishing the sequence before it times out, you may need to increase the timeout setting. Or you may want to enable the `LEADER_PER_KEY_TIMING` option, which resets the timeout after each key is tapped. diff --git a/docs/tap_hold.md b/docs/tap_hold.md index 8914b730b3..fa6c6abc14 100644 --- a/docs/tap_hold.md +++ b/docs/tap_hold.md @@ -375,49 +375,50 @@ bool get_ignore_mod_tap_interrupt(uint16_t keycode, keyrecord_t *record) { } ``` -## Tapping Force Hold +## Quick Tap Term -To enable `tapping force hold`, add the following to your `config.h`: +When the user holds a key after tapping it, the tapping function is repeated by default, rather than activating the hold function. This allows keeping the ability to auto-repeat the tapping function of a dual-role key. `QUICK_TAP_TERM` enables fine tuning of that ability. If set to `0`, it will remove the auto-repeat ability and activate the hold function instead. + +`QUICK_TAP_TERM` is set to `TAPPING_TERM` by default, which is the maximum allowed value for `QUICK_TAP_TERM`. To override its value (in milliseconds) add the following to your `config.h`: ```c -#define TAPPING_FORCE_HOLD +#define QUICK_TAP_TERM 120 ``` -When the user holds a key after tapping it, the tapping function is repeated by default, rather than activating the hold function. This allows keeping the ability to auto-repeat the tapping function of a dual-role key. `TAPPING_FORCE_HOLD` removes that ability to let the user activate the hold function instead, in the case of holding the dual-role key after having tapped it. - Example: - `SFT_T(KC_A)` Down - `SFT_T(KC_A)` Up - `SFT_T(KC_A)` Down -- wait until the tapping term expires... -- `SFT_T(KC_A)` Up +- (wait until tapping term expires...) -With default settings, `a` will be sent on the first release, then `a` will be sent on the second press allowing the computer to trigger its auto-repeat function. +With default settings, `a` will be sent on the first release, then `a` will be sent on the second press allowing the computer to trigger its auto repeat function until the key is released. -With `TAPPING_FORCE_HOLD`, the second press will be interpreted as a Shift, allowing to use it as a modifier shortly after having used it as a tap. +With `QUICK_TAP_TERM` configured, the timing between `SFT_T(KC_A)` up and `SFT_T(KC_A)` down must be within `QUICK_TAP_TERM` to trigger auto repeat. Otherwise the second press will be sent as a Shift. If `QUICK_TAP_TERM` is set to `0`, the second press will always be sent as a Shift, effectively disabling auto-repeat. -!> `TAPPING_FORCE_HOLD` will break anything that uses tapping toggles (Such as the `TT` layer keycode, and the One Shot Tap Toggle). +!> `QUICK_TAP_TERM` timing will also impact anything that uses tapping toggles (Such as the `TT` layer keycode, and the One Shot Tap Toggle). For more granular control of this feature, you can add the following to your `config.h`: ```c -#define TAPPING_FORCE_HOLD_PER_KEY +#define QUICK_TAP_TERM_PER_KEY ``` You can then add the following function to your keymap: ```c -bool get_tapping_force_hold(uint16_t keycode, keyrecord_t *record) { +uint16_t get_quick_tap_term(uint16_t keycode, keyrecord_t *record) { switch (keycode) { - case LT(1, KC_BSPC): - return true; + case SFT_T(KC_SPC): + return QUICK_TAP_TERM - 20; default: - return false; + return QUICK_TAP_TERM; } } ``` +?> If `QUICK_TAP_TERM` is set higher than `TAPPING_TERM`, it will default to `TAPPING_TERM`. + ## Retro Tapping To enable `retro tapping`, add the following to your `config.h`: -- cgit v1.2.3 From 102f22f7e99d87989cd95e10370863c3f96ba7e2 Mon Sep 17 00:00:00 2001 From: jpe230 Date: Mon, 12 Dec 2022 14:51:14 -0600 Subject: [Core] Quantum Painter - LVGL Integration (#18499) Co-authored-by: Nick Brassel --- docs/_summary.md | 1 + docs/quantum_painter_lvgl.md | 55 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+) create mode 100644 docs/quantum_painter_lvgl.md (limited to 'docs') diff --git a/docs/_summary.md b/docs/_summary.md index d388d08391..d2d4bb9b32 100644 --- a/docs/_summary.md +++ b/docs/_summary.md @@ -100,6 +100,7 @@ * Hardware Features * Displays * [Quantum Painter](quantum_painter.md) + * [Quantum Painter LVGL Integration](quantum_painter_lvgl.md) * [HD44780 LCD Driver](feature_hd44780.md) * [ST7565 LCD Driver](feature_st7565.md) * [OLED Driver](feature_oled_driver.md) diff --git a/docs/quantum_painter_lvgl.md b/docs/quantum_painter_lvgl.md new file mode 100644 index 0000000000..3edb37fbce --- /dev/null +++ b/docs/quantum_painter_lvgl.md @@ -0,0 +1,55 @@ +# Quantum Painter LVGL Integration :id=lvgl + +LVGL (Light and Versatile Graphics Library) is an open-source graphics library providing everything you need to create an embedded GUI for your board with easy-to-use graphical elements. + +LVGL integrates with [Quantum Painter's](quantum_painter.md) API and drivers to render to the display, the hardware supported by Quantum Painter is also supported by LVGL. + +?> Keep in mind that enabling the LVGL integration has a big impact in firmware size, it is recommeded to use a supported MCU with >256 kB of flash space. + +To learn more about LVGL and how to use it please take a look at their [official documentation](https://docs.lvgl.io/8.2/intro/) + +## Enabling LVGL :id=lvgl-enabling +To enable LVGL to be built into your firmware, add the following to `rules.mk`: + +```make +QUANTUM_PAINTER_ENABLE = yes +QUANTUM_PAINTER_DRIVERS = ...... +QUANTUM_PAINTER_LVGL_INTEGRATION = yes +``` +To configure the Quantum Painter Display Drivers please read the [Quantum Painter Display Drivers](quantum_painter.md#quantum-painter-drivers) section. + +## Quantum Painter LVGL API :id=lvgl-api + +### Quantum Painter LVGL Attach :id=lvgl-api-init + +```c +bool qp_lvgl_attach(painter_device_t device); +``` + +The `qp_lvgl_attach` function is used to set up LVGL with the supplied display, and requires an already configured display. + +```c +static painter_device_t display; +void keyboard_post_init_kb(void) { + display = qp_make_.......; // Create the display + qp_init(display, QP_ROTATION_0); // Initialise the display + + if (qp_lvgl_attach(display)) { // Attach LVGL to the display + ...Your code to draw // Run LVGL specific code to draw + } +} +``` +To init. the display please read the [Display Initialisation](quantum_painter.md#quantum-painter-api-init) section. + +!> Attaching LVGL to a display means LVGL subsequently "owns" the display. Using standard Quantum Painter drawing operations with the display after LVGL attachment will likely result in display artifacts. +### Quantum Painter LVGL Detach :id=lvgl-api-init + +```c +void qp_lvgl_detach() +``` + +The `qp_lvgl_detach` function stops the internal LVGL ticks and releases resources related to it. + +## Enabling/Disabling LVGL features :id=lvgl-configuring + +You can overwrite LVGL specific features in your `lv_conf.h` file. -- cgit v1.2.3 From 515dd18c2801663bbac0e59f683c2a93e4bd9b1a Mon Sep 17 00:00:00 2001 From: precondition <57645186+precondition@users.noreply.github.com> Date: Tue, 13 Dec 2022 12:20:07 +0100 Subject: Remove IGNORE_MOD_TAP_INTERRUPT_PER_KEY in favour of HOLD_ON_OTHER_KEY_PRESS_PER_KEY (#15741) --- docs/ChangeLog/20230226/PR15741.md | 43 ++++++++++++++++++ docs/config_options.md | 7 ++- docs/feature_auto_shift.md | 11 +---- docs/ja/config_options.md | 2 - docs/ja/tap_hold.md | 19 -------- docs/tap_hold.md | 93 +++++++++++++++++++++++++++++++++----- 6 files changed, 131 insertions(+), 44 deletions(-) create mode 100644 docs/ChangeLog/20230226/PR15741.md (limited to 'docs') diff --git a/docs/ChangeLog/20230226/PR15741.md b/docs/ChangeLog/20230226/PR15741.md new file mode 100644 index 0000000000..385816d65b --- /dev/null +++ b/docs/ChangeLog/20230226/PR15741.md @@ -0,0 +1,43 @@ +`IGNORE_MOD_TAP_INTERRUPT_PER_KEY` has been removed and `IGNORE_MOD_TAP_INTERRUPT` deprecated as a stepping stone towards making `IGNORE_MOD_TAP_INTERRUPT` the new default behavior for mod-taps in the future. + +In place of the now removed `IGNORE_MOD_TAP_INTERRUPT_PER_KEY`, one must use the pre-existing `HOLD_ON_OTHER_KEY_PRESS` option. + +In most cases, updating `get_ignore_mod_tap_interrupt` to `get_hold_on_other_key_press` is simply a matter of renaming the function and swapping every `true` by `false` and vice versa. The one subtlety you may need to look out for is that the `get_ignore_mod_tap_interrupt` was only ever called with mod-taps passed in as the `keycode` argument, while the `keycode` argument of `get_hold_on_other_key_press` can be any dual-role key. This includes not only mod-taps, but also layer-taps, one shot keys, `TT(layer)` and more. This has an impact on the effect of the `default` case in a typical per-key configuration making use of a `switch(keycode)` statement. + +To illustrate, let's take the example of a configuration where we'd want all mod-taps to activate the modifier if another key is pressed while held with the exception of `LCTL_T(KC_A)`, which should ignore keys pressed while it is held and activate the modifier only if it has been held for longer than the tapping term. In addition, we would like to keep the default "ignore-interrupt" behavior of layer taps. + +An old way to do this would be via the following code: + +```c +bool get_ignore_mod_tap_interrupt(uint16_t keycode, keyrecord_t *record) { + switch(keycode) { + case LCTL_T(KC_A): + return true; + default: + return false; + } +} +``` + +The correct way to update this code without accidentally changing how the layer-taps work would be the following: + +```c +bool get_hold_on_other_key_press(uint16_t keycode, keyrecord_t *record) { + switch(keycode) { + // Capture all mod-tap keycodes. + case QK_MOD_TAP ... QK_MOD_TAP_MAX: + if (keycode == LCTL_T(KC_A)) { + // Disable HOLD_ON_OTHER_KEY_PRESS for LCTL_T(KC_A) + // aka enable IGNORE_MOD_TAP_INTERRUPT for LCTL_T(KC_A). + return false; + } else { + // Enable HOLD_ON_OTHER_KEY_PRESS for every other mod-tap keycode. + return true; + } + default: + return false; + } +} +``` + +For more information, you are invited to read the sections on [IGNORE_MOD_TAP_INTERRUPT](tap_hold.md#ignore-mod-tap-interrupt) and [HOLD_ON_OTHER_KEY_PRESS](tap_hold.md#hold-on-other-key-press) in the page on [Tap-Hold configuration options](tap_hold.md). diff --git a/docs/config_options.md b/docs/config_options.md index edaa739201..7a91160bcd 100644 --- a/docs/config_options.md +++ b/docs/config_options.md @@ -169,8 +169,6 @@ If you define these options you will enable the associated feature, which may in * `#define IGNORE_MOD_TAP_INTERRUPT` * makes it possible to do rolling combos (zx) with keys that convert to other keys on hold, by enforcing the `TAPPING_TERM` for both keys. * See [Ignore Mod Tap Interrupt](tap_hold.md#ignore-mod-tap-interrupt) for details -* `#define IGNORE_MOD_TAP_INTERRUPT_PER_KEY` - * enables handling for per key `IGNORE_MOD_TAP_INTERRUPT` settings * `#define QUICK_TAP_TERM 100` * tap-then-hold timing to use a dual role key to repeat keycode * See [Quick Tap Term](tap_hold.md#quick-tap-term) @@ -178,6 +176,11 @@ If you define these options you will enable the associated feature, which may in * Defaults to `TAPPING_TERM` if not defined * `#define QUICK_TAP_TERM_PER_KEY` * enables handling for per key `QUICK_TAP_TERM` settings +* `#define HOLD_ON_OTHER_KEY_PRESS` + * selects the hold action of a dual-role key as soon as the tap of the dual-role key is interrupted by the press of another key. + * See "[hold on other key press](tap_hold.md#hold-on-other-key-press)" for details +* `#define HOLD_ON_OTHER_KEY_PRESS_PER_KEY` + * enables handling for per key `HOLD_ON_OTHER_KEY_PRESS` settings * `#define LEADER_TIMEOUT 300` * how long before the leader key times out * If you're having issues finishing the sequence before it times out, you may need to increase the timeout setting. Or you may want to enable the `LEADER_PER_KEY_TIMING` option, which resets the timeout after each key is tapped. diff --git a/docs/feature_auto_shift.md b/docs/feature_auto_shift.md index d3437a9c60..1719807e26 100644 --- a/docs/feature_auto_shift.md +++ b/docs/feature_auto_shift.md @@ -281,16 +281,7 @@ Tap Hold Configurations work a little differently when using Retro Shift. Referencing `TAPPING_TERM` makes little sense, as holding longer would result in shifting one of the keys. -`IGNORE_MOD_TAP_INTERRUPT` changes *only* rolling from a mod tap (releasing it -first), sending both keys instead of the modifier on the second. Its effects on -nested presses are ignored. - -As nested taps were changed to act as though `PERMISSIVE_HOLD` is set unless only -`IGNORE_MOD_TAP_INTERRUPT` is (outside of Retro Shift), and Retro Shift ignores -`IGNORE_MOD_TAP_INTERRUPT`, `PERMISSIVE_HOLD` has no effect on Mod Taps. - -Nested taps will *always* act as though the `TAPPING_TERM` was exceeded for both -Mod and Layer Tap keys. +`RETRO_SHIFT` enables [`PERMISSIVE_HOLD`-like behaviour](tap_hold.md#permissive-hold) (even if not explicitly enabled) on all mod-taps for which `RETRO_SHIFT` applies. ## Using Auto Shift Setup diff --git a/docs/ja/config_options.md b/docs/ja/config_options.md index c95753bd5d..6135721a42 100644 --- a/docs/ja/config_options.md +++ b/docs/ja/config_options.md @@ -162,8 +162,6 @@ QMK での全ての利用可能な設定にはデフォルトがあります。 * `#define IGNORE_MOD_TAP_INTERRUPT` * 両方のキーに `TAPPING_TERM` を適用することで、ホールド時に他のキーに変換するキーを使ってローリングコンボ (zx) をすることができるようにします * 詳細は [Ignore Mod Tap Interrupt](ja/tap_hold.md#ignore-mod-tap-interrupt) を見てください -* `#define IGNORE_MOD_TAP_INTERRUPT_PER_KEY` - * キーごとの `IGNORE_MOD_TAP_INTERRUPT` 設定の処理を有効にします * `#define TAPPING_FORCE_HOLD` * タップされた直後に、デュアルロールキーを修飾子として使用できるようにします * [Tapping Force Hold](ja/tap_hold.md#tapping-force-hold)を見てください diff --git a/docs/ja/tap_hold.md b/docs/ja/tap_hold.md index 07242821a9..ac64fe6ce3 100644 --- a/docs/ja/tap_hold.md +++ b/docs/ja/tap_hold.md @@ -110,25 +110,6 @@ bool get_permissive_hold(uint16_t keycode, keyrecord_t *record) { ?> `許容ホールド`を有効にすると、これは両方がどのように動作するかを変更します。通常のキーには、最初のキーが最初に放された場合、あるいは両方のキーが `TAPPING_TERM` より長くホールドされた場合に、修飾キーが追加されます。 -この機能をより細かく制御するために、以下を `config.h` に追加することができます: - -```c -#define IGNORE_MOD_TAP_INTERRUPT_PER_KEY -``` - -そして、以下の関数をキーマップに追加します: - -```c -bool get_ignore_mod_tap_interrupt(uint16_t keycode, keyrecord_t *record) { - switch (keycode) { - case SFT_T(KC_SPC): - return true; - default: - return false; - } -} -``` - ## タッピング強制ホールド `タッピング強制ホールド` を有効にするには、以下を `config.h` に追加します: diff --git a/docs/tap_hold.md b/docs/tap_hold.md index fa6c6abc14..348e2655eb 100644 --- a/docs/tap_hold.md +++ b/docs/tap_hold.md @@ -118,7 +118,7 @@ The reason is that `TAPPING_TERM` is a macro that expands to a constant integer 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: -1. The default mode selects the hold action only if the dual-role key is held down longer than the tapping term. In this mode pressing other keys while the dual-role key is held down does not influence the tap-or-hold decision. +1. The default mode selects the hold action only if the dual-role key is held down longer than the tapping term. In this mode pressing other keys while the dual-role key is held down does not influence the tap-or-hold decision. In other words, this mode ignores interrupts. 2. The “permissive hold” mode, in addition to the default behavior, immediately selects the hold action when another key is tapped (pressed and then released) while the dual-role key is held down, even if this happens earlier than the tapping term. If another key is just pressed, but then the dual-role key is released before that other key (and earlier than the tapping term), this mode will still select the tap action. @@ -126,6 +126,73 @@ The code which decides between the tap and hold actions of dual-role keys suppor Note that until the tap-or-hold decision completes (which happens when either the dual-role key is released, or the tapping term has expired, or the extra condition for the selected decision mode is satisfied), key events are delayed and not transmitted to the host immediately. The default mode gives the most delay (if the dual-role key is held down, this mode always waits for the whole tapping term), and the other modes may give less delay when other keys are pressed, because the hold action may be selected earlier. +### Comparison :id=comparison + +To better illustrate the tap-or-hold decision modes, let us compare the expected output of each decision mode in a handful of tapping scenarios involving a mod-tap key (`LSFT_T(KC_A)`) and a regular key (`KC_B`) with the `TAPPING_TERM` set to 200ms. + +By default, mod-taps behave like `HOLD_ON_OTHER_KEY_PRESS`, while layer-taps behave like "Ignore Interrupt" out of the box. If you want "Ignore Interrupt"-like behaviour for mod-taps, you must enable `IGNORE_MOD_TAP_INTERRUPT`, or return `false` in the `get_hold_on_other_key_press` function for all mod-taps. + +Note: "`kc` held" in the "Physical key event" column means that the key wasn't physically released yet at this point in time. + +#### Distinct taps (AABB) :id=distinct-taps + +| Time | Physical key event |Ignore Interrupt| `PERMISSIVE_HOLD` | `HOLD_ON_OTHER_KEY_PRESS` | +|------|--------------------|----------------|-------------------|----------------------------| +| 0 | `LSFT_T(KC_A)` down| | | | +| 199 | `LSFT_T(KC_A)` up | a | a | a | +| 210 | `KC_B` down | ab | ab | ab | +| 220 | `KC_B` up | ab | ab | ab | + +| Time | Physical key event |Ignore Interrupt| `PERMISSIVE_HOLD` | `HOLD_ON_OTHER_KEY_PRESS` | +|------|--------------------|----------------|-------------------|----------------------------| +| 0 | `LSFT_T(KC_A)` down| | | | +| 200 | `LSFT_T(KC_A)` held|Shift| Shift | Shift | +| 201 | `LSFT_T(KC_A)` up |Shift| Shift | Shift | +| 205 | `KC_B` down | b | b | b | +| 210 | `KC_B` up | b | b | b | + +#### Nested tap (ABBA) :id=nested-tap + +| Time | Physical key event |Ignore Interrupt| `PERMISSIVE_HOLD` | `HOLD_ON_OTHER_KEY_PRESS` | +|------|--------------------|----------------|-------------------|----------------------------| +| 0 | `LSFT_T(KC_A)` down| | | | +| 110 | `KC_B` down | | | B | +| 120 | `KC_B` up | | B | B | +| 199 | `LSFT_T(KC_A)` up | ab | B | B | + +| Time | Physical key event |Ignore Interrupt| `PERMISSIVE_HOLD` | `HOLD_ON_OTHER_KEY_PRESS` | +|------|--------------------|----------------|-------------------|----------------------------| +| 0 | `LSFT_T(KC_A)` down| | | | +| 110 | `KC_B` down | | | B | +| 120 | `KC_B` up | | B | B | +| 200 | `LSFT_T(KC_A)` held| B | B | B | +| 210 | `LSFT_T(KC_A)` up | B | B | B | + +| Time | Physical key event |Ignore Interrupt| `PERMISSIVE_HOLD` | `HOLD_ON_OTHER_KEY_PRESS` | +|------|--------------------|----------------|-------------------|----------------------------| +| 0 | `LSFT_T(KC_A)` down| | | | +| 200 | `LSFT_T(KC_A)` held|Shift| Shift | Shift | +| 205 | `KC_B` down | B | B | B | +| 210 | `KC_B` up | B | B | B | +| 220 | `LSFT_T(KC_A)` up | B | B | B | + +#### Rolling keys (ABAB) :id=rolling-keys + +| Time | Physical key event |Ignore Interrupt| `PERMISSIVE_HOLD` | `HOLD_ON_OTHER_KEY_PRESS` | +|------|--------------------|----------------|-------------------|----------------------------| +| 0 | `LSFT_T(KC_A)` down| | | | +| 110 | `KC_B` down | | | B | +| 130 | `LSFT_T(KC_A)` up | ab | ab | B | +| 140 | `KC_B` up | ab | ab | B | + +| Time | Physical key event |Ignore Interrupt| `PERMISSIVE_HOLD` | `HOLD_ON_OTHER_KEY_PRESS` | +|------|--------------------|----------------|-------------------|----------------------------| +| 0 | `LSFT_T(KC_A)` down| | | | +| 110 | `KC_B` down | | | B | +| 200 | `LSFT_T(KC_A)` held| B | B | B | +| 205 | `LSFT_T(KC_A)` up | B | B | B | +| 210 | `KC_B` up | B | B | B | + ### Default Mode Example sequence 1 (the `L` key is also mapped to `KC_RGHT` on layer 2): @@ -179,8 +246,6 @@ since `SFT_T(KC_A)` is NOT held longer than the `TAPPING_TERM`. However, the actual output would be capital `X` (`SHIFT` + `x`) due to reasons explained under [Ignore Mod Tap Interrupt](#ignore-mod-tap-interrupt). - - ### Permissive Hold The “permissive hold” mode can be enabled for all dual-role keys by adding the corresponding option to `config.h`: @@ -212,7 +277,7 @@ An example of a sequence that is affected by the “permissive hold” mode: +---------------------------|--------+ ``` -Normally, if you do all this within the `TAPPING_TERM` (default: 200ms), this will be registered as `al` by the firmware and host system. With the `PERMISSIVE_HOLD` option enabled, the Layer Tap key is considered as a layer switch if another key is tapped, and the above sequence would be registered as `KC_RGHT` (the mapping of `L` on layer 2). We could describe this sequence as a “nested press” (the modified key's key down and key up events are “nested” between the dual-role key's key down and key up events). +Normally, if you do all this within the `TAPPING_TERM` (default: 200ms), this will be registered as `al` by the firmware and host system. With the `PERMISSIVE_HOLD` option enabled, the Layer Tap key is considered as a layer switch if another key is tapped, and the above sequence would be registered as `KC_RGHT` (the mapping of `L` on layer 2). We could describe this sequence as a “nested tap” (the modified key's key down and key up events are “nested” between the dual-role key's key down and key up events). However, this slightly different sequence will not be affected by the “permissive hold” mode: @@ -235,7 +300,7 @@ However, this slightly different sequence will not be affected by the “permiss In the sequence above the dual-role key is released before the other key is released, and if that happens within the tapping term, the “permissive hold” mode will still choose the tap action for the dual-role key, and the sequence will be registered as `al` by the host. We could describe this as a “rolling press” (the two keys' key down and key up events behave as if you were rolling a ball across the two keys, first pressing each key down in sequence and then releasing them in the same order). -?> The `PERMISSIVE_HOLD` option also affects Mod Tap keys, but this may not be noticeable if you do not also enable the `IGNORE_MOD_TAP_INTERRUPT` option for those keys, because the default handler for Mod Tap keys also considers both the “nested press” and “rolling press” sequences like shown above as a modifier hold, not the tap action. If you do not enable `IGNORE_MOD_TAP_INTERRUPT`, the effect of `PERMISSIVE_HOLD` on Mod Tap keys would be limited to reducing the delay before the key events are made visible to the host. +?> The `PERMISSIVE_HOLD` option is not noticeable if you also enable `HOLD_ON_OTHER_KEY_PRESS` because the latter option considers both the “nested tap” and “rolling press” sequences like shown above as a hold action, not the tap action. `HOLD_ON_OTHER_KEY_PRESS` makes the Tap-Or-Hold decision earlier in the chain of key events, thus taking a precedence over `PERMISSIVE_HOLD`. This remark also applies to default mod-taps. For more granular control of this feature, you can add the following to your `config.h`: @@ -291,7 +356,7 @@ An example of a sequence that is affected by the “hold on other key press” m Normally, if you do all this within the `TAPPING_TERM` (default: 200ms), this will be registered as `al` by the firmware and host system. With the `HOLD_ON_OTHER_KEY_PRESS` option enabled, the Layer Tap key is considered as a layer switch if another key is pressed, and the above sequence would be registered as `KC_RGHT` (the mapping of `L` on layer 2). -?> The `HOLD_ON_OTHER_KEY_PRESS` option also affects Mod Tap keys, but this may not be noticeable if you do not also enable the `IGNORE_MOD_TAP_INTERRUPT` option for those keys, because the default handler for Mod Tap keys also considers the “rolling press” sequence like shown above as a modifier hold, not the tap action. If you do not enable `IGNORE_MOD_TAP_INTERRUPT`, the effect of `HOLD_ON_OTHER_KEY_PRESS` on Mod Tap keys would be limited to reducing the delay before the key events are made visible to the host. +?> The `HOLD_ON_OTHER_KEY_PRESS` option is essentially redundant with the default mod-tap behaviour. The only notable difference is that `HOLD_ON_OTHER_KEY_PRESS` reduces the delay before the key events are made visible to the host. For more granular control of this feature, you can add the following to your `config.h`: @@ -355,26 +420,32 @@ However, if the `HOLD_ON_OTHER_KEY_PRESS` option is enabled in addition to `IGNO For more granular control of this feature, you can add the following to your `config.h`: ```c -#define IGNORE_MOD_TAP_INTERRUPT_PER_KEY +#define HOLD_ON_OTHER_KEY_PRESS_PER_KEY ``` +?> This option affects *all* dual-role keys. + You can then add the following function to your keymap: ```c -bool get_ignore_mod_tap_interrupt(uint16_t keycode, keyrecord_t *record) { +bool get_hold_on_other_key_press(uint16_t keycode, keyrecord_t *record) { switch (keycode) { case SFT_T(KC_SPC): // Do not force the mod-tap key press to be handled as a modifier // if any other key was pressed while the mod-tap key is held down. - return true; + return false; default: - // Force the mod-tap key press to be handled as a modifier if any + // Force the dual-role key press to be handled as a modifier if any // other key was pressed while the mod-tap key is held down. - return false; + return true; } } ``` +Note that you must return `false` in `get_hold_on_other_key_press` in order to apply `IGNORE_MOD_TAP_INTERRUPT` for a certain mod-tap key. + +?> `IGNORE_MOD_TAP_INTERRUPT[_PER_KEY]` is being progressively phased out to align the (default) behavior and configuration of mod-taps with the rest of dual-role keys. + ## Quick Tap Term When the user holds a key after tapping it, the tapping function is repeated by default, rather than activating the hold function. This allows keeping the ability to auto-repeat the tapping function of a dual-role key. `QUICK_TAP_TERM` enables fine tuning of that ability. If set to `0`, it will remove the auto-repeat ability and activate the hold function instead. -- cgit v1.2.3 From 9e4cfcd181a87c4f8adfaef5a766f788263ff60a Mon Sep 17 00:00:00 2001 From: Ryan Date: Wed, 14 Dec 2022 13:44:36 +1100 Subject: UCIS: remove `qk_` prefix (#19302) --- docs/feature_unicode.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'docs') diff --git a/docs/feature_unicode.md b/docs/feature_unicode.md index a93e9ad2ba..1ea411191e 100644 --- a/docs/feature_unicode.md +++ b/docs/feature_unicode.md @@ -83,7 +83,7 @@ UCIS_ENABLE = yes Then define a table like this in your keymap file: ```c -const qk_ucis_symbol_t ucis_symbol_table[] = UCIS_TABLE( +const ucis_symbol_t ucis_symbol_table[] = UCIS_TABLE( UCIS_SYM("poop", 0x1F4A9), // 💩 UCIS_SYM("rofl", 0x1F923), // 🤣 UCIS_SYM("cuba", 0x1F1E8, 0x1F1FA), // 🇨🇺 @@ -93,15 +93,15 @@ const qk_ucis_symbol_t ucis_symbol_table[] = UCIS_TABLE( By default, each table entry may be up to 3 code points long. This number can be changed by adding `#define UCIS_MAX_CODE_POINTS n` to your `config.h` file. -To use UCIS input, call `qk_ucis_start()`. Then, type the mnemonic for the character (such as "rofl") and hit Space, Enter or Esc. QMK should erase the "rofl" text and insert the laughing emoji. +To use UCIS input, call `ucis_start()`. Then, type the mnemonic for the character (such as "rofl") and hit Space, Enter or Esc. QMK should erase the "rofl" text and insert the laughing emoji. #### Customization There are several functions that you can define in your keymap to customize the functionality of this feature. -* `void qk_ucis_start_user(void)` – This runs when you call the "start" function, and can be used to provide feedback. By default, it types out a keyboard emoji. -* `void qk_ucis_success(uint8_t symbol_index)` – This runs when the input has matched something and has completed. By default, it doesn't do anything. -* `void qk_ucis_symbol_fallback (void)` – This runs when the input doesn't match anything. By default, it falls back to trying that input as a Unicode code. +* `void ucis_start_user(void)` – This runs when you call the "start" function, and can be used to provide feedback. By default, it types out a keyboard emoji. +* `void ucis_success(uint8_t symbol_index)` – This runs when the input has matched something and has completed. By default, it doesn't do anything. +* `void ucis_symbol_fallback (void)` – This runs when the input doesn't match anything. By default, it falls back to trying that input as a Unicode code. You can find the default implementations of these functions in [`process_ucis.c`](https://github.com/qmk/qmk_firmware/blob/master/quantum/process_keycode/process_ucis.c). -- cgit v1.2.3 From e2117564c54044c809903627c0061b5a9d129815 Mon Sep 17 00:00:00 2001 From: Ryan Date: Wed, 14 Dec 2022 13:46:01 +1100 Subject: Leader: remove `qk_` prefix (#19304) --- docs/feature_leader_key.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'docs') diff --git a/docs/feature_leader_key.md b/docs/feature_leader_key.md index e285d10597..4e7a487be7 100644 --- a/docs/feature_leader_key.md +++ b/docs/feature_leader_key.md @@ -93,18 +93,18 @@ While, this may be fine for most, if you want to specify the whole keycode (eg, ## Customization -The Leader Key feature has some additional customization to how the Leader Key feature works. It has two functions that can be called at certain parts of the process. Namely `leader_start()` and `leader_end()`. +The Leader Key feature has some additional customization to how the Leader Key feature works. It has two functions that can be called at certain parts of the process. Namely `leader_start_user()` and `leader_end_user()`. -The `leader_start()` function is called when you tap the `QK_LEAD` key, and the `leader_end()` function is called when either the leader sequence is completed, or the leader timeout is hit. +The `leader_start_user()` function is called when you tap the `QK_LEAD` key, and the `leader_end_user()` function is called when either the leader sequence is completed, or the leader timeout is hit. You can add these functions to your code (`keymap.c` usually) to add feedback to the Leader sequences (such as beeping or playing music). ```c -void leader_start(void) { +void leader_start_user(void) { // sequence started } -void leader_end(void) { +void leader_end_user(void) { // sequence ended (no success/failure detection) } ``` @@ -139,13 +139,13 @@ void matrix_scan_user(void) { } } -void leader_start(void) { +void leader_start_user(void) { #ifdef AUDIO_ENABLE PLAY_SONG(leader_start); #endif } -void leader_end(void) { +void leader_end_user(void) { if (did_leader_succeed) { #ifdef AUDIO_ENABLE PLAY_SONG(leader_succeed); -- cgit v1.2.3 From 1124bbc1db8fb26418bded7016c702de469b162f Mon Sep 17 00:00:00 2001 From: Joel Challis Date: Wed, 14 Dec 2022 11:14:10 +0000 Subject: Remove deprecated led_set_kb (#19273) * Remove led_set_kb maintaining existing led_set_user behaviour * Also call led_set_user --- docs/feature_led_indicators.md | 2 +- docs/hardware_keyboard_guidelines.md | 2 +- docs/ja/feature_led_indicators.md | 2 +- docs/ja/hardware_keyboard_guidelines.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) (limited to 'docs') diff --git a/docs/feature_led_indicators.md b/docs/feature_led_indicators.md index d89562a377..1f71cdb1c8 100644 --- a/docs/feature_led_indicators.md +++ b/docs/feature_led_indicators.md @@ -19,7 +19,7 @@ There are three ways to get the lock LED state: Two deprecated functions that provide the LED state as `uint8_t`: -* `uint8_t led_set_kb(uint8_t usb_led)` and `_user(uint8_t usb_led)` +* `uint8_t led_set_user(uint8_t usb_led)` * `uint8_t host_keyboard_leds()` ## Configuration Options diff --git a/docs/hardware_keyboard_guidelines.md b/docs/hardware_keyboard_guidelines.md index 6df86fb0fb..247ec9982f 100644 --- a/docs/hardware_keyboard_guidelines.md +++ b/docs/hardware_keyboard_guidelines.md @@ -188,7 +188,7 @@ The following functions are typically defined in this file: * `void matrix_init_kb(void)` * `void matrix_scan_kb(void)` * `bool process_record_kb(uint16_t keycode, keyrecord_t *record)` -* `void led_set_kb(uint8_t usb_led)` +* `bool led_update_kb(led_t led_state)` ### `` diff --git a/docs/ja/feature_led_indicators.md b/docs/ja/feature_led_indicators.md index 764b478c31..94ee063234 100644 --- a/docs/ja/feature_led_indicators.md +++ b/docs/ja/feature_led_indicators.md @@ -22,7 +22,7 @@ QMK は HID 仕様で定義された5つの LED の読み取りメソッドを LED の状態を `uint8_t` として提供する2つの非推奨の関数があります: -* `uint8_t led_set_kb(uint8_t usb_led)` と `_user(uint8_t usb_led)` +* `uint8_t led_set_user(uint8_t usb_led)` * `uint8_t host_keyboard_leds()` ## 設定オプション :id=configuration-options diff --git a/docs/ja/hardware_keyboard_guidelines.md b/docs/ja/hardware_keyboard_guidelines.md index c0e7c18be0..ef5f6df2b9 100644 --- a/docs/ja/hardware_keyboard_guidelines.md +++ b/docs/ja/hardware_keyboard_guidelines.md @@ -165,7 +165,7 @@ Clueboard は、サブフォルダをまとめるためとキーボードのリ * `void matrix_init_kb(void)` * `void matrix_scan_kb(void)` * `bool process_record_kb(uint16_t keycode, keyrecord_t *record)` -* `void led_set_kb(uint8_t usb_led)` +* `bool led_update_kb(led_t led_state)` ### `` -- cgit v1.2.3 From 1978007faefc0fb3af809ddf0d2ff1274e540570 Mon Sep 17 00:00:00 2001 From: Ryan Date: Thu, 15 Dec 2022 07:40:25 +1100 Subject: Tap Dance: remove `qk_` prefix (#19313) --- docs/feature_tap_dance.md | 64 +++++++++++++++++++++++------------------------ 1 file changed, 32 insertions(+), 32 deletions(-) (limited to 'docs') diff --git a/docs/feature_tap_dance.md b/docs/feature_tap_dance.md index 1062e32243..b7d8a5528f 100644 --- a/docs/feature_tap_dance.md +++ b/docs/feature_tap_dance.md @@ -64,7 +64,7 @@ enum { }; // Tap Dance definitions -qk_tap_dance_action_t tap_dance_actions[] = { +tap_dance_action_t tap_dance_actions[] = { // Tap once for Escape, twice for Caps Lock [TD_ESC_CAPS] = ACTION_TAP_DANCE_DOUBLE(KC_ESC, KC_CAPS), }; @@ -96,14 +96,14 @@ enum { #### Example 1: Send "Safety Dance!" After 100 Taps :id=example-1 ```c -void dance_egg(qk_tap_dance_state_t *state, void *user_data) { +void dance_egg(tap_dance_state_t *state, void *user_data) { if (state->count >= 100) { SEND_STRING("Safety dance!"); reset_tap_dance(state); } } -qk_tap_dance_action_t tap_dance_actions[] = { +tap_dance_action_t tap_dance_actions[] = { [CT_EGG] = ACTION_TAP_DANCE_FN(dance_egg), }; ``` @@ -113,7 +113,7 @@ qk_tap_dance_action_t tap_dance_actions[] = { ```c // On each tap, light up one LED, from right to left // On the fourth tap, turn them off from right to left -void dance_flsh_each(qk_tap_dance_state_t *state, void *user_data) { +void dance_flsh_each(tap_dance_state_t *state, void *user_data) { switch (state->count) { case 1: ergodox_right_led_3_on(); @@ -134,14 +134,14 @@ void dance_flsh_each(qk_tap_dance_state_t *state, void *user_data) { } // On the fourth tap, set the keyboard on flash state -void dance_flsh_finished(qk_tap_dance_state_t *state, void *user_data) { +void dance_flsh_finished(tap_dance_state_t *state, void *user_data) { if (state->count >= 4) { reset_keyboard(); } } // If the flash state didn't happen, then turn off LEDs, left to right -void dance_flsh_reset(qk_tap_dance_state_t *state, void *user_data) { +void dance_flsh_reset(tap_dance_state_t *state, void *user_data) { ergodox_right_led_1_off(); wait_ms(50); ergodox_right_led_2_off(); @@ -150,7 +150,7 @@ void dance_flsh_reset(qk_tap_dance_state_t *state, void *user_data) { } // All tap dances now put together. Example 2 is "CT_FLSH" -qk_tap_dance_action_t tap_dance_actions[] = { +tap_dance_action_t tap_dance_actions[] = { [TD_ESC_CAPS] = ACTION_TAP_DANCE_DOUBLE(KC_ESC, KC_CAPS), [CT_EGG] = ACTION_TAP_DANCE_FN(dance_egg), [CT_FLSH] = ACTION_TAP_DANCE_FN_ADVANCED(dance_flsh_each, dance_flsh_finished, dance_flsh_reset) @@ -169,7 +169,7 @@ typedef struct { } tap_dance_tap_hold_t; bool process_record_user(uint16_t keycode, keyrecord_t *record) { - qk_tap_dance_action_t *action; + tap_dance_action_t *action; switch (keycode) { case TD(CT_CLN): // list all tap dance keycodes with tap-hold configurations @@ -182,7 +182,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) { return true; } -void tap_dance_tap_hold_finished(qk_tap_dance_state_t *state, void *user_data) { +void tap_dance_tap_hold_finished(tap_dance_state_t *state, void *user_data) { tap_dance_tap_hold_t *tap_hold = (tap_dance_tap_hold_t *)user_data; if (state->pressed) { @@ -200,7 +200,7 @@ void tap_dance_tap_hold_finished(qk_tap_dance_state_t *state, void *user_data) { } } -void tap_dance_tap_hold_reset(qk_tap_dance_state_t *state, void *user_data) { +void tap_dance_tap_hold_reset(tap_dance_state_t *state, void *user_data) { tap_dance_tap_hold_t *tap_hold = (tap_dance_tap_hold_t *)user_data; if (tap_hold->held) { @@ -212,7 +212,7 @@ void tap_dance_tap_hold_reset(qk_tap_dance_state_t *state, void *user_data) { #define ACTION_TAP_DANCE_TAP_HOLD(tap, hold) \ { .fn = {NULL, tap_dance_tap_hold_finished, tap_dance_tap_hold_reset}, .user_data = (void *)&((tap_dance_tap_hold_t){tap, hold, 0}), } -qk_tap_dance_action_t tap_dance_actions[] = { +tap_dance_action_t tap_dance_actions[] = { [CT_CLN] = ACTION_TAP_DANCE_TAP_HOLD(KC_COLN, KC_SCLN), }; ``` @@ -256,11 +256,11 @@ enum { SOME_OTHER_DANCE }; -td_state_t cur_dance(qk_tap_dance_state_t *state); +td_state_t cur_dance(tap_dance_state_t *state); // For the x tap dance. Put it here so it can be used in any keymap -void x_finished(qk_tap_dance_state_t *state, void *user_data); -void x_reset(qk_tap_dance_state_t *state, void *user_data); +void x_finished(tap_dance_state_t *state, void *user_data); +void x_reset(tap_dance_state_t *state, void *user_data); ``` Now, at the bottom of your `keymap.c` file, you'll need to add the following: @@ -293,7 +293,7 @@ Now, at the bottom of your `keymap.c` file, you'll need to add the following: * For the third point, there does exist the 'TD_DOUBLE_SINGLE_TAP', however this is not fully tested * */ -td_state_t cur_dance(qk_tap_dance_state_t *state) { +td_state_t cur_dance(tap_dance_state_t *state) { if (state->count == 1) { if (state->interrupted || !state->pressed) return TD_SINGLE_TAP; // Key has not been interrupted, but the key is still held. Means you want to send a 'HOLD'. @@ -322,7 +322,7 @@ static td_tap_t xtap_state = { .state = TD_NONE }; -void x_finished(qk_tap_dance_state_t *state, void *user_data) { +void x_finished(tap_dance_state_t *state, void *user_data) { xtap_state.state = cur_dance(state); switch (xtap_state.state) { case TD_SINGLE_TAP: register_code(KC_X); break; @@ -337,7 +337,7 @@ void x_finished(qk_tap_dance_state_t *state, void *user_data) { } } -void x_reset(qk_tap_dance_state_t *state, void *user_data) { +void x_reset(tap_dance_state_t *state, void *user_data) { switch (xtap_state.state) { case TD_SINGLE_TAP: unregister_code(KC_X); break; case TD_SINGLE_HOLD: unregister_code(KC_LCTL); break; @@ -349,7 +349,7 @@ void x_reset(qk_tap_dance_state_t *state, void *user_data) { xtap_state.state = TD_NONE; } -qk_tap_dance_action_t tap_dance_actions[] = { +tap_dance_action_t tap_dance_actions[] = { [X_CTL] = ACTION_TAP_DANCE_FN_ADVANCED(NULL, x_finished, x_reset) }; ``` @@ -385,18 +385,18 @@ static td_state_t td_state; // Declare your tapdance functions: // Function to determine the current tapdance state -td_state_t cur_dance(qk_tap_dance_state_t *state); +td_state_t cur_dance(tap_dance_state_t *state); // `finished` and `reset` functions for each tapdance keycode -void altlp_finished(qk_tap_dance_state_t *state, void *user_data); -void altlp_reset(qk_tap_dance_state_t *state, void *user_data); +void altlp_finished(tap_dance_state_t *state, void *user_data); +void altlp_reset(tap_dance_state_t *state, void *user_data); ``` Below your `LAYOUT`, define each of the tapdance functions: ```c // Determine the tapdance state to return -td_state_t cur_dance(qk_tap_dance_state_t *state) { +td_state_t cur_dance(tap_dance_state_t *state) { if (state->count == 1) { if (state->interrupted || !state->pressed) return TD_SINGLE_TAP; else return TD_SINGLE_HOLD; @@ -408,7 +408,7 @@ td_state_t cur_dance(qk_tap_dance_state_t *state) { // Handle the possible states for each tapdance keycode you define: -void altlp_finished(qk_tap_dance_state_t *state, void *user_data) { +void altlp_finished(tap_dance_state_t *state, void *user_data) { td_state = cur_dance(state); switch (td_state) { case TD_SINGLE_TAP: @@ -426,7 +426,7 @@ void altlp_finished(qk_tap_dance_state_t *state, void *user_data) { } } -void altlp_reset(qk_tap_dance_state_t *state, void *user_data) { +void altlp_reset(tap_dance_state_t *state, void *user_data) { switch (td_state) { case TD_SINGLE_TAP: unregister_code16(KC_LPRN); @@ -443,7 +443,7 @@ void altlp_reset(qk_tap_dance_state_t *state, void *user_data) { } // Define `ACTION_TAP_DANCE_FN_ADVANCED()` for each tapdance keycode, passing in `finished` and `reset` functions -qk_tap_dance_action_t tap_dance_actions[] = { +tap_dance_action_t tap_dance_actions[] = { [ALT_LP] = ACTION_TAP_DANCE_FN_ADVANCED(NULL, altlp_finished, altlp_reset) }; ``` @@ -478,18 +478,18 @@ enum { // Declare the functions to be used with your tap dance key(s) // Function associated with all tap dances -td_state_t cur_dance(qk_tap_dance_state_t *state); +td_state_t cur_dance(tap_dance_state_t *state); // Functions associated with individual tap dances -void ql_finished(qk_tap_dance_state_t *state, void *user_data); -void ql_reset(qk_tap_dance_state_t *state, void *user_data); +void ql_finished(tap_dance_state_t *state, void *user_data); +void ql_reset(tap_dance_state_t *state, void *user_data); ``` Towards the bottom of your `keymap.c`, include the following code: ```c // Determine the current tap dance state -td_state_t cur_dance(qk_tap_dance_state_t *state) { +td_state_t cur_dance(tap_dance_state_t *state) { if (state->count == 1) { if (!state->pressed) return TD_SINGLE_TAP; else return TD_SINGLE_HOLD; @@ -504,7 +504,7 @@ static td_tap_t ql_tap_state = { }; // Functions that control what our tap dance key does -void ql_finished(qk_tap_dance_state_t *state, void *user_data) { +void ql_finished(tap_dance_state_t *state, void *user_data) { ql_tap_state.state = cur_dance(state); switch (ql_tap_state.state) { case TD_SINGLE_TAP: @@ -528,7 +528,7 @@ void ql_finished(qk_tap_dance_state_t *state, void *user_data) { } } -void ql_reset(qk_tap_dance_state_t *state, void *user_data) { +void ql_reset(tap_dance_state_t *state, void *user_data) { // If the key was held down and now is released then switch off the layer if (ql_tap_state.state == TD_SINGLE_HOLD) { layer_off(_MY_LAYER); @@ -537,7 +537,7 @@ void ql_reset(qk_tap_dance_state_t *state, void *user_data) { } // Associate our tap dance key with its functionality -qk_tap_dance_action_t tap_dance_actions[] = { +tap_dance_action_t tap_dance_actions[] = { [QUOT_LAYR] = ACTION_TAP_DANCE_FN_ADVANCED(NULL, ql_finished, ql_reset) }; -- cgit v1.2.3 From c6d0aa6ae42bc298c821dbbbd80df1c6905931d5 Mon Sep 17 00:00:00 2001 From: Albert Y <76888457+filterpaper@users.noreply.github.com> Date: Thu, 15 Dec 2022 19:29:26 +0800 Subject: Add change log for quick tap term (#19341) --- docs/ChangeLog/20230226/PR17007.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 docs/ChangeLog/20230226/PR17007.md (limited to 'docs') diff --git a/docs/ChangeLog/20230226/PR17007.md b/docs/ChangeLog/20230226/PR17007.md new file mode 100644 index 0000000000..bea04994b5 --- /dev/null +++ b/docs/ChangeLog/20230226/PR17007.md @@ -0,0 +1,31 @@ +`TAPPING_FORCE_HOLD` feature is now replaced by `QUICK_TAP_TERM`. Instead of turning off auto-repeat completely, user will have the option to configure a `QUICK_TAP_TERM` in milliseconds. When the user holds a tap-hold key after tapping it within `QUICK_TAP_TERM`, QMK will send the tap keycode to the host, enabling auto-repeat. + +Its value is set to `TAPPING_TERM` by default and it can be reduced to match typing habits to avoid false triggers. To disable auto-repeat completely, set `QUICK_TAP_TERM` to zero. + +`TAPPING_FORCE_HOLD_PER_KEY` is also deprecated and replaced by `QUICK_TAP_TERM_PER_KEY`. The old granular control function for tapping force hold is: + +```c +bool get_tapping_force_hold(uint16_t keycode, keyrecord_t *record) { + switch (keycode) { + case LT(1, KC_BSPC): + return true; + default: + return false; + } +} +``` + +That function can be replaced with: + +```c +uint16_t get_quick_tap_term(uint16_t keycode, keyrecord_t *record) { + switch (keycode) { + case SFT_T(KC_SPC): + return 0; + default: + return QUICK_TAP_TERM; + } +} +``` + +For more details, please read the updated documentation section on [Quick Tap Term](tap_hold.md#quick-tap-term). -- cgit v1.2.3 From 801d2ff940a5f19ee4fa7df992e86d1fd1daf610 Mon Sep 17 00:00:00 2001 From: Ryan Date: Fri, 30 Dec 2022 11:48:05 +1100 Subject: Remove useless line continuations (#19399) --- docs/keymap.md | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-) (limited to 'docs') diff --git a/docs/keymap.md b/docs/keymap.md index ea702ff0f2..66e9db1a7f 100644 --- a/docs/keymap.md +++ b/docs/keymap.md @@ -141,14 +141,15 @@ After this you'll find the layer definitions. Typically you'll have one or more Here is an example of the Clueboard's base layer: - /* Keymap _BL: Base Layer (Default Layer) - */ - [_BL] = LAYOUT( - F(0), KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_MINS, KC_EQL, KC_GRV, KC_BSPC, KC_PGUP, \ - KC_TAB, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, KC_LBRC, KC_RBRC, KC_BSLS, KC_PGDN, \ - KC_CAPS, KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, KC_SCLN, KC_QUOT, KC_NUHS, KC_ENT, \ - KC_LSFT, KC_NUBS, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, KC_SLSH, KC_INT1, KC_RSFT, KC_UP, \ - KC_LCTL, KC_LGUI, KC_LALT, KC_INT5, KC_SPC,KC_SPC, KC_INT4, KC_RALT, KC_RCTL, MO(_FL), KC_LEFT, KC_DOWN, KC_RGHT), +```c +[_BL] = LAYOUT( + F(0), KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_MINS, KC_EQL, KC_GRV, KC_BSPC, KC_PGUP, + KC_TAB, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, KC_LBRC, KC_RBRC, KC_BSLS, KC_PGDN, + KC_CAPS, KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, KC_SCLN, KC_QUOT, KC_NUHS, KC_ENT, + KC_LSFT, KC_NUBS, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, KC_SLSH, KC_INT1, KC_RSFT, KC_UP, + KC_LCTL, KC_LGUI, KC_LALT, KC_INT5, KC_SPC,KC_SPC, KC_INT4, KC_RALT, KC_RCTL, MO(_FL), KC_LEFT, KC_DOWN, KC_RGHT +), +``` Some interesting things to note about this: @@ -163,12 +164,15 @@ Some interesting things to note about this: Our function layer is, from a code point of view, no different from the base layer. Conceptually, however, you will build that layer as an overlay, not a replacement. For many people this distinction does not matter, but as you build more complicated layering setups it matters more and more. - [_FL] = LAYOUT( - KC_GRV, KC_F1, KC_F2, KC_F3, KC_F4, KC_F5, KC_F6, KC_F7, KC_F8, KC_F9, KC_F10, KC_F11, KC_F12, _______, KC_DEL, BL_STEP, \ - _______, _______, _______,_______,_______,_______,_______,_______,KC_PSCR,KC_SCRL, KC_PAUS, _______, _______, _______, _______, \ - _______, _______, MO(_CL),_______,_______,_______,_______,_______,_______,_______, _______, _______, _______, _______, \ - _______, _______, _______,_______,_______,_______,_______,_______,_______,_______, _______, _______, _______, _______, KC_PGUP, \ - _______, _______, _______, _______, _______,_______, _______, _______, _______, MO(_FL), KC_HOME, KC_PGDN, KC_END), +```c +[_FL] = LAYOUT( + KC_GRV, KC_F1, KC_F2, KC_F3, KC_F4, KC_F5, KC_F6, KC_F7, KC_F8, KC_F9, KC_F10, KC_F11, KC_F12, _______, KC_DEL, BL_STEP, + _______, _______, _______,_______,_______,_______,_______,_______,KC_PSCR,KC_SCRL, KC_PAUS, _______, _______, _______, _______, + _______, _______, MO(_CL),_______,_______,_______,_______,_______,_______,_______, _______, _______, _______, _______, + _______, _______, _______,_______,_______,_______,_______,_______,_______,_______, _______, _______, _______, _______, KC_PGUP, + _______, _______, _______, _______, _______,_______, _______, _______, _______, MO(_FL), KC_HOME, KC_PGDN, KC_END +), +``` Some interesting things to note: -- cgit v1.2.3 From b585ece5ef9309557ac6b61eadda4f00e4e52b0c Mon Sep 17 00:00:00 2001 From: Drashna Jaelre Date: Sat, 31 Dec 2022 16:56:32 -0800 Subject: Add Split support for Haptic feedback (#19203) --- docs/feature_split_keyboard.md | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'docs') diff --git a/docs/feature_split_keyboard.md b/docs/feature_split_keyboard.md index 0b475cc63d..eaef975fb7 100644 --- a/docs/feature_split_keyboard.md +++ b/docs/feature_split_keyboard.md @@ -286,6 +286,12 @@ This enables transmitting the pointing device status to the master side of the s !> There is additional required configuration for `SPLIT_POINTING_ENABLE` outlined in the [pointing device documentation](feature_pointing_device.md?id=split-keyboard-configuration). +```c +#define SPLIT_HAPTIC_ENABLE +``` + +This enables triggering of haptic feedback on the slave side of the split keyboard. For DRV2605L this will send the mode, but for solenoids it is expected that the desired mode is already set up on the slave. + ### Custom data sync between sides :id=custom-data-sync QMK's split transport allows for arbitrary data transactions at both the keyboard and user levels. This is modelled on a remote procedure call, with the master invoking a function on the slave side, with the ability to send data from master to slave, process it slave side, and send data back from slave to master. -- cgit v1.2.3 From 45851a10f66119ceff3baadde27f68e287eff481 Mon Sep 17 00:00:00 2001 From: David Hoelscher Date: Sat, 14 Jan 2023 04:24:54 -0600 Subject: Add RGB565 and RGB888 color support to Quantum Painter (#19382) --- docs/quantum_painter.md | 59 +++++++++++++++++++++++++++++++------------------ 1 file changed, 38 insertions(+), 21 deletions(-) (limited to 'docs') diff --git a/docs/quantum_painter.md b/docs/quantum_painter.md index 781b467a45..ac37053c79 100644 --- a/docs/quantum_painter.md +++ b/docs/quantum_painter.md @@ -32,15 +32,16 @@ Supported devices: ## Quantum Painter Configuration :id=quantum-painter-config -| Option | Default | Purpose | -|-----------------------------------------|---------|---------------------------------------------------------------------------------------------------------------------------------------------| -| `QUANTUM_PAINTER_NUM_IMAGES` | `8` | The maximum number of images/animations that can be loaded at any one time. | -| `QUANTUM_PAINTER_NUM_FONTS` | `4` | The maximum number of fonts that can be loaded at any one time. | -| `QUANTUM_PAINTER_CONCURRENT_ANIMATIONS` | `4` | The maximum number of animations that can be executed at the same time. | -| `QUANTUM_PAINTER_LOAD_FONTS_TO_RAM` | `FALSE` | Whether or not fonts should be loaded to RAM. Relevant for fonts stored in off-chip persistent storage, such as external flash. | -| `QUANTUM_PAINTER_PIXDATA_BUFFER_SIZE` | `32` | The limit of the amount of pixel data that can be transmitted in one transaction to the display. Higher values require more RAM on the MCU. | -| `QUANTUM_PAINTER_SUPPORTS_256_PALETTE` | `FALSE` | If 256-color palettes are supported. Requires significantly more RAM on the MCU. | -| `QUANTUM_PAINTER_DEBUG` | _unset_ | Prints out significant amounts of debugging information to CONSOLE output. Significant performance degradation, use only for debugging. | +| Option | Default | Purpose | +|------------------------------------------|---------|---------------------------------------------------------------------------------------------------------------------------------------------| +| `QUANTUM_PAINTER_NUM_IMAGES` | `8` | The maximum number of images/animations that can be loaded at any one time. | +| `QUANTUM_PAINTER_NUM_FONTS` | `4` | The maximum number of fonts that can be loaded at any one time. | +| `QUANTUM_PAINTER_CONCURRENT_ANIMATIONS` | `4` | The maximum number of animations that can be executed at the same time. | +| `QUANTUM_PAINTER_LOAD_FONTS_TO_RAM` | `FALSE` | Whether or not fonts should be loaded to RAM. Relevant for fonts stored in off-chip persistent storage, such as external flash. | +| `QUANTUM_PAINTER_PIXDATA_BUFFER_SIZE` | `32` | The limit of the amount of pixel data that can be transmitted in one transaction to the display. Higher values require more RAM on the MCU. | +| `QUANTUM_PAINTER_SUPPORTS_256_PALETTE` | `FALSE` | If 256-color palettes are supported. Requires significantly more RAM on the MCU. | +| `QUANTUM_PAINTER_SUPPORTS_NATIVE_COLORS` | `FALSE` | If native color range is supported. Requires significantly more RAM on the MCU. | +| `QUANTUM_PAINTER_DEBUG` | _unset_ | Prints out significant amounts of debugging information to CONSOLE output. Significant performance degradation, use only for debugging. | Drivers have their own set of configurable options, and are described in their respective sections. @@ -63,7 +64,7 @@ options: -d, --no-deltas Disables the use of delta frames when encoding animations. -r, --no-rle Disables the use of RLE when encoding images. -f FORMAT, --format FORMAT - Output format, valid types: pal256, pal16, pal4, pal2, mono256, mono16, mono4, mono2 + Output format, valid types: rgb888, rgb565, pal256, pal16, pal4, pal2, mono256, mono16, mono4, mono2 -o OUTPUT, --output OUTPUT Specify output directory. Defaults to same directory as input. -i INPUT, --input INPUT @@ -77,16 +78,18 @@ The `OUTPUT` argument needs to be a directory, and will default to the same dire The `FORMAT` argument can be any of the following: -| Format | Meaning | -|-----------|-----------------------------------------------------------------------| -| `pal256` | 256-color palette (requires `QUANTUM_PAINTER_SUPPORTS_256_PALETTE`) | -| `pal16` | 16-color palette | -| `pal4` | 4-color palette | -| `pal2` | 2-color palette | -| `mono256` | 256-shade grayscale (requires `QUANTUM_PAINTER_SUPPORTS_256_PALETTE`) | -| `mono16` | 16-shade grayscale | -| `mono4` | 4-shade grayscale | -| `mono2` | 2-shade grayscale | +| Format | Meaning | +|-----------|-------------------------------------------------------------------------------------------| +| `rgb888` | 16,777,216 colors in 8-8-8 RGB format (requires `QUANTUM_PAINTER_SUPPORTS_NATIVE_COLORS`) | +| `rgb565` | 65,536 colors in 5-6-5 RGB format (requires `QUANTUM_PAINTER_SUPPORTS_NATIVE_COLORS`) | +| `pal256` | 256-color palette (requires `QUANTUM_PAINTER_SUPPORTS_256_PALETTE`) | +| `pal16` | 16-color palette | +| `pal4` | 4-color palette | +| `pal2` | 2-color palette | +| `mono256` | 256-shade grayscale (requires `QUANTUM_PAINTER_SUPPORTS_256_PALETTE`) | +| `mono16` | 16-shade grayscale | +| `mono4` | 4-shade grayscale | +| `mono2` | 2-shade grayscale | **Examples**: @@ -154,7 +157,7 @@ options: -w, --raw Writes out the QFF file as raw data instead of c/h combo. -r, --no-rle Disable the use of RLE to minimise converted image size. -f FORMAT, --format FORMAT - Output format, valid types: pal256, pal16, pal4, pal2, mono256, mono16, mono4, mono2 + Output format, valid types: rgb565, pal256, pal16, pal4, pal2, mono256, mono16, mono4, mono2 -u UNICODE_GLYPHS, --unicode-glyphs UNICODE_GLYPHS Also generate the specified unicode glyphs. -n, --no-ascii Disables output of the full ASCII character set (0x20..0x7E), exporting only the glyphs specified. @@ -215,6 +218,8 @@ The maximum number of displays can be configured by changing the following in yo #define GC9A01_NUM_DEVICES 3 ``` +Native color format rgb565 is compatible with GC9A01 + #### ** ILI9163 ** Enabling support for the ILI9163 in Quantum Painter is done by adding the following to `rules.mk`: @@ -239,6 +244,8 @@ The maximum number of displays can be configured by changing the following in yo #define ILI9163_NUM_DEVICES 3 ``` +Native color format rgb565 is compatible with ILI9163 + #### ** ILI9341 ** Enabling support for the ILI9341 in Quantum Painter is done by adding the following to `rules.mk`: @@ -263,6 +270,8 @@ The maximum number of displays can be configured by changing the following in yo #define ILI9341_NUM_DEVICES 3 ``` +Native color format rgb565 is compatible with ILI9341 + #### ** ILI9488 ** Enabling support for the ILI9488 in Quantum Painter is done by adding the following to `rules.mk`: @@ -287,6 +296,8 @@ The maximum number of displays can be configured by changing the following in yo #define ILI9488_NUM_DEVICES 3 ``` +Native color format rgb888 is compatible with ILI9488 + #### ** SSD1351 ** Enabling support for the SSD1351 in Quantum Painter is done by adding the following to `rules.mk`: @@ -311,6 +322,8 @@ The maximum number of displays can be configured by changing the following in yo #define SSD1351_NUM_DEVICES 3 ``` +Native color format rgb565 is compatible with SSD1351 + #### ** ST7735 ** Enabling support for the ST7735 in Quantum Painter is done by adding the following to `rules.mk`: @@ -335,6 +348,8 @@ The maximum number of displays can be configured by changing the following in yo #define ST7735_NUM_DEVICES 3 ``` +Native color format rgb565 is compatible with ST7735 + !> Some ST7735 devices are known to have different drawing offsets -- despite being a 132x162 pixel display controller internally, some display panels are only 80x160, or smaller. These may require an offset to be applied; see `qp_set_viewport_offsets` above for information on how to override the offsets if they aren't correctly rendered. #### ** ST7789 ** @@ -361,6 +376,8 @@ The maximum number of displays can be configured by changing the following in yo #define ST7789_NUM_DEVICES 3 ``` +Native color format rgb565 is compatible with ST7789 + !> Some ST7789 devices are known to have different drawing offsets -- despite being a 240x320 pixel display controller internally, some display panels are only 240x240, or smaller. These may require an offset to be applied; see `qp_set_viewport_offsets` above for information on how to override the offsets if they aren't correctly rendered. -- cgit v1.2.3 From 0730740add19d3afe3d96ead50ba7d29e5dcb109 Mon Sep 17 00:00:00 2001 From: Joel Challis Date: Sun, 15 Jan 2023 15:04:32 +0000 Subject: Add mmoskal/uf2-stm32f103 bootloader support (#19594) --- docs/flashing.md | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) (limited to 'docs') diff --git a/docs/flashing.md b/docs/flashing.md index b3f055f6cb..a636f19c72 100644 --- a/docs/flashing.md +++ b/docs/flashing.md @@ -363,6 +363,47 @@ CLI Flashing sequence: * `:uf2-split-left` and `:uf2-split-right`: Flashes the firmware but also sets the handedness setting in EEPROM by generating a side specific firmware. +## uf2boot + +Keyboards may opt into supporting the uf2boot bootloader. This is currently only supported on the F103 bluepill. + +The `rules.mk` setting for this bootloader is `uf2boot`, and can be specified at the keymap or user level. + +To ensure compatibility with the uf2boot bootloader, make sure this block is present in your `rules.mk`: + +```make +# Bootloader selection +BOOTLOADER = uf2boot +``` + +Compatible flashers: + +* Any application able to copy a file from one place to another, such as _macOS Finder_ or _Windows Explorer_. + +Flashing sequence: + +1. Enter the bootloader using any of the following methods: + * Tap the `QK_BOOT` keycode + * Double-tap the `nRST` button on the PCB. +2. Wait for the OS to detect the device +3. Copy the .uf2 file to the new USB disk +4. Wait for the keyboard to become available + +or + +CLI Flashing sequence: + +1. Enter the bootloader using any of the following methods: + * Tap the `QK_BOOT` keycode + * Double-tap the `nRST` button on the PCB. +2. Wait for the OS to detect the device +3. Flash via QMK CLI eg. `qmk flash --keyboard handwired/onekey/bluepill_uf2boot --keymap default` +4. Wait for the keyboard to become available + +### `make` Targets + +* `:uf2-split-left` and `:uf2-split-right`: Flashes the firmware but also sets the handedness setting in EEPROM by generating a side specific firmware. + ## Raspberry Pi RP2040 UF2 The `rules.mk` setting for this bootloader is `rp2040`, and can be specified at the keymap or user level. -- cgit v1.2.3 From 82a94ea1bd4d930aebb15f7a3316836a0488421d Mon Sep 17 00:00:00 2001 From: Joel Challis Date: Wed, 18 Jan 2023 22:36:58 +0000 Subject: Add f303 to tinyuf2 bootloader support (#19620) --- docs/flashing.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/flashing.md b/docs/flashing.md index a636f19c72..443fa3123e 100644 --- a/docs/flashing.md +++ b/docs/flashing.md @@ -324,7 +324,7 @@ Flashing sequence: ## tinyuf2 -Keyboards may opt into supporting the tinyuf2 bootloader. This is currently only supported on the F401/F411 blackpill. +Keyboards may opt into supporting the tinyuf2 bootloader. This is currently only supported on F303/F401/F411. The `rules.mk` setting for this bootloader is `tinyuf2`, and can be specified at the keymap or user level. @@ -365,7 +365,7 @@ CLI Flashing sequence: ## uf2boot -Keyboards may opt into supporting the uf2boot bootloader. This is currently only supported on the F103 bluepill. +Keyboards may opt into supporting the uf2boot bootloader. This is currently only supported on F103. The `rules.mk` setting for this bootloader is `uf2boot`, and can be specified at the keymap or user level. -- cgit v1.2.3 From 272281f1a0a3d5f07e0dfa890f1af2f360ca54bf Mon Sep 17 00:00:00 2001 From: Sergey Vlasov Date: Thu, 19 Jan 2023 02:30:58 +0300 Subject: Add analog support for RP2040 (#19453) Co-authored-by: Ryan --- docs/adc_driver.md | 17 +++++++++++++++++ docs/platformdev_rp2040.md | 2 +- 2 files changed, 18 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/adc_driver.md b/docs/adc_driver.md index 69fff4b3c2..494d90c94f 100644 --- a/docs/adc_driver.md +++ b/docs/adc_driver.md @@ -43,6 +43,8 @@ Then place this include at the top of your code: ### ARM +#### STM32 + Note that some of these pins are doubled-up on ADCs with the same channel. This is because the pins can be used for either ADC. Also note that the F0 and F3 use different numbering schemes. The F0 has a single ADC and the channels are 0-indexed, whereas the F3 has 4 ADCs and the channels are 1-indexed. This is because the F0 uses the `ADCv1` implementation of the ADC, whereas the F3 uses the `ADCv3` implementation. @@ -121,6 +123,21 @@ Also note that the F0 and F3 use different numbering schemes. The F0 has a singl ² Not all STM32F4xx devices have ADC2 and/or ADC3, therefore some configurations shown in this table may be unavailable; in particular, pins `F4`…`F10` cannot be used as ADC inputs on devices which do not have ADC3. Check the device datasheet to confirm which pin functions are supported. +#### RP2040 + +RP2040 has only a single ADC (`ADCD1` in ChibiOS); in the QMK API the index for that ADC is 0. + +|Channel|Pin | +|-------|-------------------| +|0 |`GP26` | +|1 |`GP27` | +|2 |`GP28` | +|3 |`GP29` | +|4 |Temperature sensor*| + + +* The temperature sensor is disabled by default and needs to be enabled by the RP2040-specific function: `adcRPEnableTS(&ADCD1)`. The ADC must be initialized before calling that function; an easy way to ensure that is to perform a dummy conversion. + ## Functions ### AVR diff --git a/docs/platformdev_rp2040.md b/docs/platformdev_rp2040.md index 11a93edd89..b5b32c7b08 100644 --- a/docs/platformdev_rp2040.md +++ b/docs/platformdev_rp2040.md @@ -4,7 +4,7 @@ The following table shows the current driver status for peripherals on RP2040 MC | System | Support | | ---------------------------------------------------------------- | ---------------------------------------------- | -| [ADC driver](adc_driver.md) | Support planned (no ETA) | +| [ADC driver](adc_driver.md) | :heavy_check_mark: | | [Audio](audio_driver.md#pwm-hardware) | :heavy_check_mark: | | [Backlight](feature_backlight.md) | :heavy_check_mark: | | [I2C driver](i2c_driver.md) | :heavy_check_mark: | -- cgit v1.2.3 From cf935d97ae479e7a1e1f2f2f248b93e52e4cc69e Mon Sep 17 00:00:00 2001 From: Ryan Date: Sat, 21 Jan 2023 03:21:17 +1100 Subject: Fix functions with empty params (#19647) * Fix functions with empty params * Found a bunch more --- docs/gpio_control.md | 2 +- docs/quantum_painter_lvgl.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/gpio_control.md b/docs/gpio_control.md index e1f1515b71..12413dfc8e 100644 --- a/docs/gpio_control.md +++ b/docs/gpio_control.md @@ -30,7 +30,7 @@ The above functions are not always guaranteed to work atomically. Therefore, if eg. ```c -void some_function() { +void some_function(void) { // some process ATOMIC_BLOCK_FORCEON { // Atomic Processing diff --git a/docs/quantum_painter_lvgl.md b/docs/quantum_painter_lvgl.md index 3edb37fbce..4d10160baf 100644 --- a/docs/quantum_painter_lvgl.md +++ b/docs/quantum_painter_lvgl.md @@ -45,7 +45,7 @@ To init. the display please read the [Display Initialisation](quantum_painter.md ### Quantum Painter LVGL Detach :id=lvgl-api-init ```c -void qp_lvgl_detach() +void qp_lvgl_detach(void) ``` The `qp_lvgl_detach` function stops the internal LVGL ticks and releases resources related to it. -- cgit v1.2.3 From 043d8e1140e09327b72ed3bd55f369e1faf1a334 Mon Sep 17 00:00:00 2001 From: Ryan Date: Mon, 30 Jan 2023 03:44:16 +1100 Subject: Remove deprecated Quantum keycodes (#19712) --- docs/configurator_default_keymaps.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/configurator_default_keymaps.md b/docs/configurator_default_keymaps.md index d08ec29539..ec74f4740c 100644 --- a/docs/configurator_default_keymaps.md +++ b/docs/configurator_default_keymaps.md @@ -54,7 +54,7 @@ const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { KC_LCTL, KC_LGUI, KC_LALT, KC_SPC, KC_RALT, MO(1), KC_RGUI, KC_RCTL, KC_LEFT, KC_DOWN, KC_RGHT), [1] = LAYOUT_all( - KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, RGB_TOG, RGB_MOD, RGB_HUD, RGB_HUI, RGB_SAD, RGB_SAI, RGB_VAD, RGB_VAI, BL_TOGG, BL_DEC, BL_INC, + KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, RGB_TOG, RGB_MOD, RGB_HUD, RGB_HUI, RGB_SAD, RGB_SAI, RGB_VAD, RGB_VAI, BL_TOGG, BL_DOWN, BL_UP, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_VOLU, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, QK_BOOT, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_MPLY, KC_MNXT, KC_VOLD, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, @@ -82,7 +82,7 @@ The default keymap uses the `LAYOUT_all` macro, so that will be the value of the "KC_LCTL", "KC_LGUI", "KC_LALT", "KC_SPC", "KC_RALT", "MO(1)", "KC_RGUI", "KC_RCTL", "KC_LEFT", "KC_DOWN", "KC_RGHT" ], [ - "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "RGB_TOG", "RGB_MOD", "RGB_HUD", "RGB_HUI", "RGB_SAD", "RGB_SAI", "RGB_VAD", "RGB_VAI", "BL_TOGG", "BL_DEC", "BL_INC", + "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "RGB_TOG", "RGB_MOD", "RGB_HUD", "RGB_HUI", "RGB_SAD", "RGB_SAI", "RGB_VAD", "RGB_VAI", "BL_TOGG", "BL_DOWN", "BL_UP", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_VOLU", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "QK_BOOT", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_MPLY", "KC_MNXT", "KC_VOLD", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", -- cgit v1.2.3 From 242b80c63ffff022172755da35fb4767d5f837c2 Mon Sep 17 00:00:00 2001 From: Ryan Date: Mon, 30 Jan 2023 18:47:50 +1100 Subject: Move MIDI code out of tmk_core (#19704) --- docs/feature_midi.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'docs') diff --git a/docs/feature_midi.md b/docs/feature_midi.md index 1f0809ef14..775a5e34ee 100644 --- a/docs/feature_midi.md +++ b/docs/feature_midi.md @@ -250,10 +250,10 @@ For the above, the `MI_C` keycode will produce a C3 (note number 48), and so on. * `quantum/process_keycode/process_midi.c` * `quantum/quantum_keycodes.h` - * `tmk_core/protocol/midi.h` - * `tmk_core/protocol/midi.c` - * `tmk_core/protocol/qmk_midi.c` - * `tmk_core/protocol/midi_device.h` + * `quantum/midi/midi.h` + * `quantum/midi/midi.c` + * `quantum/midi/qmk_midi.c` + * `quantum/midi/midi_device.h`