aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/compatible_microcontrollers.md4
-rw-r--r--docs/config_options.md2
-rw-r--r--docs/drivers/gpio.md2
-rw-r--r--docs/drivers/ws2812.md2
-rw-r--r--docs/features/bluetooth.md10
-rw-r--r--docs/features/combo.md44
-rw-r--r--docs/keycodes.md10
-rw-r--r--docs/other_vscode.md5
-rw-r--r--docs/quantum_painter.md36
9 files changed, 95 insertions, 20 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/config_options.md b/docs/config_options.md
index fec6b22b13..90a708dd99 100644
--- a/docs/config_options.md
+++ b/docs/config_options.md
@@ -426,8 +426,6 @@ Use these to enable or disable building certain features. The more you have enab
* Key combo feature
* `NKRO_ENABLE`
* USB N-Key Rollover - if this doesn't work, see here: https://github.com/tmk/tmk_keyboard/wiki/FAQ#nkro-doesnt-work
-* `RING_BUFFERED_6KRO_REPORT_ENABLE`
- * USB 6-Key Rollover - Instead of stopping any new input once 6 keys are pressed, the oldest key is released and the new key is pressed.
* `AUDIO_ENABLE`
* Enable the audio subsystem.
* `KEY_OVERRIDE_ENABLE`
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/drivers/ws2812.md b/docs/drivers/ws2812.md
index 61addf1917..64343d3c6a 100644
--- a/docs/drivers/ws2812.md
+++ b/docs/drivers/ws2812.md
@@ -236,7 +236,7 @@ The following `#define`s apply only to the `pwm` driver:
|`WS2812_PWM_COMPLEMENTARY_OUTPUT`|*Not defined* |Whether the PWM output is complementary (`TIMx_CHyN`) |
::: tip
-Using a complementary timer output (`TIMx_CHyN`) is possible only for advanced-control timers (1, 8 and 20 on STM32), and the `STM32_PWM_USE_ADVANCED` option in `mcuconf.h` must be set to `TRUE`. Complementary outputs of general-purpose timers are not supported due to ChibiOS limitations.
+Using a complementary timer output (`TIMx_CHyN`) is possible only for advanced-control timers (1, 8 and 20 on STM32). Complementary outputs of general-purpose timers are not supported due to ChibiOS limitations.
:::
## API {#api}
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: ![VSCode Settings](https://i.imgur.com/EGrPM1L.png)
:::
-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 ...`).
diff --git a/docs/quantum_painter.md b/docs/quantum_painter.md
index 1d844d0f94..782d496ff7 100644
--- a/docs/quantum_painter.md
+++ b/docs/quantum_painter.md
@@ -28,6 +28,8 @@ Supported devices:
| ILI9341 | RGB LCD | 240x320 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ili9341_spi` |
| ILI9486 | RGB LCD | 320x480 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ili9486_spi` |
| ILI9488 | RGB LCD | 320x480 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ili9488_spi` |
+| LD7032 (SPI) | Monochrome OLED | 128x40 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ld7032_spi` |
+| LD7032 (I2C) | Monochrome OLED | 128x40 | I2C | `QUANTUM_PAINTER_DRIVERS += ld7032_i2c` |
| SSD1351 | RGB OLED | 128x128 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ssd1351_spi` |
| ST7735 | RGB LCD | 132x162, 80x160 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += st7735_spi` |
| ST7789 | RGB LCD | 240x320, 240x240 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += st7789_spi` |
@@ -478,6 +480,40 @@ Native color format mono2 is compatible with SH1106
SSD1306 and SH1106 are almost entirely identical, to the point of being indisinguishable by Quantum Painter. Enable SH1106 support in Quantum Painter and create SH1106 devices in firmware to perform drawing operations on SSD1306 displays.
+==== LD7032
+
+Enabling support for the LD7032 in Quantum Painter is done by adding the following to `rules.mk`:
+
+```make
+QUANTUM_PAINTER_ENABLE = yes
+# For SPI:
+QUANTUM_PAINTER_DRIVERS += ld7032_spi
+# For I2C:
+QUANTUM_PAINTER_DRIVERS += ld7032_i2c
+```
+
+Creating a SH1106 device in firmware can then be done with the following APIs:
+
+```c
+// SPI-based LD7032:
+painter_device_t qp_ld7032_make_spi_device(uint16_t panel_width, uint16_t panel_height, pin_t chip_select_pin, pin_t dc_pin, pin_t reset_pin, uint16_t spi_divisor, int spi_mode);
+// I2C-based LD7032:
+painter_device_t qp_ld7032_make_i2c_device(uint16_t panel_width, uint16_t panel_height, uint8_t i2c_address);
+```
+
+The device handle returned from the `qp_ld7032_make_???_device` function can be used to perform all other drawing operations.
+
+The maximum number of displays of each type can be configured by changing the following in your `config.h` (default is 1):
+
+```c
+// 3 SPI displays:
+#define LD7032_NUM_SPI_DEVICES 3
+// 3 I2C displays:
+#define LD7032_NUM_I2C_DEVICES 3
+```
+
+Native color format mono2 is compatible with LD7032.
+
:::::
===== Surface