diff options
Diffstat (limited to 'docs')
-rw-r--r-- | docs/compatible_microcontrollers.md | 4 | ||||
-rw-r--r-- | docs/drivers/gpio.md | 2 | ||||
-rw-r--r-- | docs/features/bluetooth.md | 10 | ||||
-rw-r--r-- | docs/features/combo.md | 44 | ||||
-rw-r--r-- | docs/keycodes.md | 10 | ||||
-rw-r--r-- | docs/other_vscode.md | 5 |
6 files changed, 58 insertions, 17 deletions
diff --git a/docs/compatible_microcontrollers.md b/docs/compatible_microcontrollers.md index 785aee30d5..e2d27e06f2 100644 --- a/docs/compatible_microcontrollers.md +++ b/docs/compatible_microcontrollers.md @@ -75,10 +75,6 @@ You can also use any ARM chip with USB that [ChibiOS](https://www.chibios.org) s For a detailed overview about the RP2040 support by QMK see the [dedicated RP2040 page](platformdev_rp2040). -## Atmel ATSAM - -There is limited support for one of Atmel's ATSAM microcontrollers, that being the [ATSAMD51J18A](https://www.microchip.com/wwwproducts/en/ATSAMD51J18A) used by the [Massdrop keyboards](https://github.com/qmk/qmk_firmware/tree/master/keyboards/massdrop). However, it is not recommended to design a board with this microcontroller as the support is quite specialized to Massdrop hardware. - ## RISC-V ### GigaDevice diff --git a/docs/drivers/gpio.md b/docs/drivers/gpio.md index 9ce4f2aa20..b21a17bc39 100644 --- a/docs/drivers/gpio.md +++ b/docs/drivers/gpio.md @@ -13,7 +13,7 @@ The following macros provide basic control of GPIOs and are found in `platforms/ |`gpio_set_pin_input_low(pin)` |Set pin as input with builtin pull-down resistor (unavailable on AVR)| |`gpio_set_pin_output(pin)` |Set pin as output (alias of `gpio_set_pin_output_push_pull`) | |`gpio_set_pin_output_push_pull(pin)` |Set pin as output, push/pull mode | -|`gpio_set_pin_output_open_drain(pin)`|Set pin as output, open-drain mode (unavailable on AVR and ATSAM) | +|`gpio_set_pin_output_open_drain(pin)`|Set pin as output, open-drain mode (unavailable on AVR) | |`gpio_write_pin_high(pin)` |Set pin level as high, assuming it is an output | |`gpio_write_pin_low(pin)` |Set pin level as low, assuming it is an output | |`gpio_write_pin(pin, level)` |Set pin level, assuming it is an output | diff --git a/docs/features/bluetooth.md b/docs/features/bluetooth.md index 1dbf15f4e1..d3634498be 100644 --- a/docs/features/bluetooth.md +++ b/docs/features/bluetooth.md @@ -39,8 +39,8 @@ BLUETOOTH_DRIVER = bluefruit_le # or rn42 This is used when multiple keyboard outputs can be selected. Currently this only allows for switching between USB and Bluetooth on keyboards that support both. -|Key |Aliases |Description | -|---------------------|---------|----------------------------------------------| -|`QK_OUTPUT_AUTO` |`OU_AUTO`|Automatically switch between USB and Bluetooth| -|`QK_OUTPUT_USB` |`OU_USB` |USB only | -|`QK_OUTPUT_BLUETOOTH`|`OU_BT` |Bluetooth only | +| Key | Aliases | Description | +|-----------------------|----------------------|------------------------------------------------| +| `QK_OUTPUT_NEXT` | `OU_NEXT`, `OU_AUTO` | Automatically switch between USB and Bluetooth | +| `QK_OUTPUT_USB` | `OU_USB` | USB only | +| `QK_OUTPUT_BLUETOOTH` | `OU_BT` | Bluetooth only | diff --git a/docs/features/combo.md b/docs/features/combo.md index bdb8c4b15f..10e33b72a6 100644 --- a/docs/features/combo.md +++ b/docs/features/combo.md @@ -307,6 +307,50 @@ bool process_combo_key_release(uint16_t combo_index, combo_t *combo, uint8_t key return false; } ``` + +### Customizable key repress +By defining `COMBO_PROCESS_KEY_REPRESS` and implementing `bool process_combo_key_repress(uint16_t combo_index, combo_t *combo, uint8_t key_index, uint16_t keycode)` you can run your custom code when you repress just released key of a combo. By combining it with custom `process_combo_event` we can for example make special handling for Alt+Tab to switch windows, which, on combo F+G activation, registers Alt and presses Tab - then we can switch windows forward by releasing G and pressing it again, or backwards with F key. Here's the full example: + +```c +enum combos { + CMB_ALTTAB +}; + +const uint16_t PROGMEM combo_alttab[] = {KC_F, KC_G, COMBO_END}; + +combo_t key_combos[COMBO_LENGTH] = { + [CMB_ALTTAB] = COMBO(combo_alttab, KC_NO), // KC_NO to leave processing for process_combo_event +}; + +void process_combo_event(uint16_t combo_index, bool pressed) { + switch (combo_index) { + case CMB_ALTTAB: + if (pressed) { + register_mods(MOD_LALT); + tap_code(KC_TAB); + } else { + unregister_mods(MOD_LALT); + } + break; + } +} + +bool process_combo_key_repress(uint16_t combo_index, combo_t *combo, uint8_t key_index, uint16_t keycode) { + switch (combo_index) { + case CMB_ALTTAB: + switch (keycode) { + case KC_F: + tap_code16(S(KC_TAB)); + return true; + case KC_G: + tap_code(KC_TAB); + return true; + } + } + return false; +} +``` + ### Layer independent combos If you, for example, use multiple base layers for different key layouts, one for QWERTY, and another one for Colemak, you might want your combos to work from the same key positions on all layers. Defining the same combos again for another layout is redundant and takes more memory. The solution is to just check the keycodes from one layer. diff --git a/docs/keycodes.md b/docs/keycodes.md index 9038c2b6d7..9107ca5eb8 100644 --- a/docs/keycodes.md +++ b/docs/keycodes.md @@ -294,11 +294,11 @@ See also: [Backlighting](features/backlight) See also: [Bluetooth](features/bluetooth) -|Key |Aliases |Description | -|---------------------|---------|----------------------------------------------| -|`QK_OUTPUT_AUTO` |`OU_AUTO`|Automatically switch between USB and Bluetooth| -|`QK_OUTPUT_USB` |`OU_USB` |USB only | -|`QK_OUTPUT_BLUETOOTH`|`OU_BT` |Bluetooth only | +| Key | Aliases | Description | +|-----------------------|----------------------|------------------------------------------------| +| `QK_OUTPUT_NEXT` | `OU_NEXT`, `OU_AUTO` | Automatically switch between USB and Bluetooth | +| `QK_OUTPUT_USB` | `OU_USB` | USB only | +| `QK_OUTPUT_BLUETOOTH` | `OU_BT` | Bluetooth only | ## Caps Word {#caps-word} diff --git a/docs/other_vscode.md b/docs/other_vscode.md index 31208d8f3b..ab2b23e96b 100644 --- a/docs/other_vscode.md +++ b/docs/other_vscode.md @@ -177,12 +177,13 @@ You'll need to perform some modifications to the file above in order to target y Windows builds of QMK Firmware are generally compiled using QMK MSYS, and the path to gdb's location (`C:\\QMK_MSYS\\mingw64\\bin`) needs to be specified under `armToolchainPath` for it to be detected. You may also need to change the GDB path to point at `C:\\QMK_MSYS\\mingw64\\bin\\gdb-multiarch.exe` in the VSCode Cortex-Debug user settings:  ::: -Optionally, the following modifications should also be made to the keyboard's `rules.mk` file to disable optimisations -- not strictly required but will ensure breakpoints and variable viewing works correctly: +The following modifications must be made to the keyboard's `rules.mk` file to enable debug information and disable optimisations -- this will ensure breakpoints and variable viewing works correctly: ```makefile +# Enable debug information in the final binaries +DEBUG_ENABLE = yes # Disable optimisations for debugging purposes LTO_ENABLE = no OPT = g -DEBUG = 3 ``` At this point, you should build and flash your firmware through normal methods (`qmk compile ...` and `qmk flash ...`). |