aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/_aliases.json4
-rw-r--r--docs/_sidebar.json5
-rw-r--r--docs/cli_commands.md18
-rw-r--r--docs/compatible_microcontrollers.md8
-rw-r--r--docs/config_options.md2
-rw-r--r--docs/driver_installation_zadig.md1
-rw-r--r--docs/drivers/gpio.md2
-rw-r--r--docs/drivers/ws2812.md47
-rw-r--r--docs/feature_converters.md6
-rw-r--r--docs/feature_layers.md4
-rw-r--r--docs/features/combo.md70
-rw-r--r--docs/features/joystick.md51
-rw-r--r--docs/features/layer_lock.md139
-rw-r--r--docs/features/os_detection.md30
-rw-r--r--docs/features/pointing_device.md1
-rw-r--r--docs/features/rgb_matrix.md62
-rw-r--r--docs/features/rgblight.md10
-rw-r--r--docs/features/wireless.md (renamed from docs/features/bluetooth.md)24
-rw-r--r--docs/flashing.md33
-rw-r--r--docs/keycodes.md74
-rw-r--r--docs/other_vscode.md5
-rw-r--r--docs/porting_your_keyboard_to_qmk.md147
-rw-r--r--docs/quantum_painter.md36
-rw-r--r--docs/ref_functions.md4
-rw-r--r--docs/reference_info_json.md4
25 files changed, 591 insertions, 196 deletions
diff --git a/docs/_aliases.json b/docs/_aliases.json
index f06e032215..0dfcdea1e2 100644
--- a/docs/_aliases.json
+++ b/docs/_aliases.json
@@ -16,6 +16,8 @@
"/tutorial": "/newbs",
"/unicode": "/feature_unicode",
+ "/features/bluetooth": "/features/wireless",
+
"/adc_driver": "/drivers/adc",
"/apa102_driver": "/drivers/apa102",
"/audio_driver": "/drivers/audio",
@@ -24,7 +26,7 @@
"/feature_auto_shift": "/features/auto_shift",
"/feature_autocorrect": "/features/autocorrect",
"/feature_backlight": "/features/backlight",
- "/feature_bluetooth": "/features/bluetooth",
+ "/feature_bluetooth": "/features/wireless",
"/feature_bootmagic": "/features/bootmagic",
"/feature_caps_word": "/features/caps_word",
"/feature_combo": "/features/combo",
diff --git a/docs/_sidebar.json b/docs/_sidebar.json
index d691011d64..15c3cbec31 100644
--- a/docs/_sidebar.json
+++ b/docs/_sidebar.json
@@ -123,6 +123,7 @@
{ "text": "Key Lock", "link": "/features/key_lock" },
{ "text": "Key Overrides", "link": "/features/key_overrides" },
{ "text": "Layers", "link": "/feature_layers" },
+ { "text": "Layer Lock", "link": "/features/layer_lock" },
{ "text": "One Shot Keys", "link": "/one_shot_keys" },
{ "text": "OS Detection", "link": "/features/os_detection" },
{ "text": "Raw HID", "link": "/features/rawhid" },
@@ -166,7 +167,6 @@
]
},
{ "text": "Audio", "link": "/features/audio" },
- { "text": "Bluetooth", "link": "/features/bluetooth" },
{ "text": "Bootmagic", "link": "/features/bootmagic" },
{ "text": "Converters", "link": "/feature_converters" },
{ "text": "Custom Matrix", "link": "/custom_matrix" },
@@ -179,7 +179,8 @@
{ "text": "Pointing Device", "link": "/features/pointing_device" },
{ "text": "PS/2 Mouse", "link": "/features/ps2_mouse" },
{ "text": "Split Keyboard", "link": "/features/split_keyboard" },
- { "text": "Stenography", "link": "/features/stenography" }
+ { "text": "Stenography", "link": "/features/stenography" },
+ { "text": "Wireless", "link": "/features/wireless" }
]
},
{
diff --git a/docs/cli_commands.md b/docs/cli_commands.md
index 7d74d8e617..4cd5ae98c3 100644
--- a/docs/cli_commands.md
+++ b/docs/cli_commands.md
@@ -153,20 +153,26 @@ qmk cd
This command allows for searching through keyboard/keymap targets, filtering by specific criteria. `info.json` and `rules.mk` files contribute to the search data, as well as keymap configurations, and the results can be filtered using "dotty" syntax matching the overall `info.json` file format.
-For example, one could search for all keyboards using STM32F411:
+For example, one could search for all keyboards powered by the STM32F411 microcontroller:
```
-qmk find -f 'processor=STM32F411'
+qmk find -f 'processor==STM32F411'
```
-...and one can further constrain the list to keyboards using STM32F411 as well as rgb_matrix support:
+The list can be further constrained by passing additional filter expressions:
```
-qmk find -f 'processor=STM32F411' -f 'features.rgb_matrix=true'
+qmk find -f 'processor==STM32F411' -f 'features.rgb_matrix==true'
```
-The following filter expressions are also supported:
+The following filter expressions are supported:
+ - `key == value`: Match targets where `key` is equal to `value`. May include wildcards such as `*` and `?`.
+ - `key != value`: Match targets where `key` is not `value`. May include wildcards such as `*` and `?`.
+ - `key < value`: Match targets where `key` is a number less than `value`.
+ - `key > value`: Match targets where `key` is a number greater than `value`.
+ - `key <= value`: Match targets where `key` is a number less than or equal to `value`.
+ - `key >= value`: Match targets where `key` is a number greater than or equal to `value`.
- `exists(key)`: Match targets where `key` is present.
- `absent(key)`: Match targets where `key` is not present.
- `contains(key, value)`: Match targets where `key` contains `value`. Can be used for strings, arrays and object keys.
@@ -175,7 +181,7 @@ The following filter expressions are also supported:
You can also list arbitrary values for each matched target with `--print`:
```
-qmk find -f 'processor=STM32F411' -p 'keyboard_name' -p 'features.rgb_matrix'
+qmk find -f 'processor==STM32F411' -p 'keyboard_name' -p 'features.rgb_matrix'
```
**Usage**:
diff --git a/docs/compatible_microcontrollers.md b/docs/compatible_microcontrollers.md
index 785aee30d5..f148c39191 100644
--- a/docs/compatible_microcontrollers.md
+++ b/docs/compatible_microcontrollers.md
@@ -57,6 +57,10 @@ You can also use any ARM chip with USB that [ChibiOS](https://www.chibios.org) s
* [WB32F3G71xx](http://www.westberrytech.com)
* [WB32FQ95xx](http://www.westberrytech.com)
+### Artery (AT32)
+
+ * [AT32F415](https://www.arterychip.com/en/product/AT32F415.jsp)
+
### NXP (Kinetis)
* [MKL26Z64](https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/kl-series-cortex-m0-plus/kinetis-kl2x-72-96-mhz-usb-ultra-low-power-microcontrollers-mcus-based-on-arm-cortex-m0-plus-core:KL2x)
@@ -75,10 +79,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/driver_installation_zadig.md b/docs/driver_installation_zadig.md
index 9743c0adc2..1a5bd1cc34 100644
--- a/docs/driver_installation_zadig.md
+++ b/docs/driver_installation_zadig.md
@@ -98,6 +98,7 @@ The device name here is the name that appears in Zadig, and may not be what the
|`bootloadhid` |HIDBoot |`16C0:05DF` |HidUsb |
|`usbasploader`|USBasp |`16C0:05DC` |libusbK|
|`apm32-dfu` |APM32 DFU ISP Mode |`314B:0106` |WinUSB |
+|`at32-dfu` |AT32 Bootloader DFU |`2E3C:DF11` |WinUSB |
|`stm32-dfu` |STM32 BOOTLOADER |`0483:DF11` |WinUSB |
|`gd32v-dfu` |GD32V BOOTLOADER |`28E9:0189` |WinUSB |
|`kiibohd` |Kiibohd DFU Bootloader |`1C11:B007` |WinUSB |
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 88c096794f..4d1e727928 100644
--- a/docs/drivers/ws2812.md
+++ b/docs/drivers/ws2812.md
@@ -252,18 +252,49 @@ 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}
-### `void ws2812_setleds(rgb_led_t *ledarray, uint16_t number_of_leds)` {#api-ws2812-setleds}
+### `void ws2812_init(void)` {#api-ws2812-init}
-Send RGB data to the WS2812 LED chain.
+Initialize the LED driver. This function should be called first.
-#### Arguments {#api-ws2812-setleds-arguments}
+---
- - `rgb_led_t *ledarray`
- A pointer to the LED array.
- - `uint16_t number_of_leds`
- The length of the LED array.
+### `void ws2812_set_color(int index, uint8_t red, uint8_t green, uint8_t blue)` {#api-ws2812-set-color}
+
+Set the color of a single LED. This function does not immediately update the LEDs; call `ws2812_flush()` after you are finished.
+
+#### Arguments {#api-ws2812-set-color-arguments}
+
+ - `int index`
+ The LED index in the WS2812 chain.
+ - `uint8_t red`
+ The red value to set.
+ - `uint8_t green`
+ The green value to set.
+ - `uint8_t blue`
+ The blue value to set.
+
+---
+
+### `void ws812_set_color_all(uint8_t red, uint8_t green, uint8_t blue)` {#api-ws2812-set-color-all}
+
+Set the color of all LEDs.
+
+#### Arguments {#api-ws2812-set-color-all-arguments}
+
+ - `uint8_t red`
+ The red value to set.
+ - `uint8_t green`
+ The green value to set.
+ - `uint8_t blue`
+ The blue value to set.
+
+---
+
+### `void ws2812_flush(void)` {#api-ws2812-flush}
+
+Flush the PWM values to the LED chain.
diff --git a/docs/feature_converters.md b/docs/feature_converters.md
index 0021c34e51..06cc7b3a11 100644
--- a/docs/feature_converters.md
+++ b/docs/feature_converters.md
@@ -21,6 +21,7 @@ The following converters are available at this time:
| `promicro` | `liatris` |
| `promicro` | `imera` |
| `promicro` | `michi` |
+| `promicro` | `svlinky` |
| `elite_c` | `stemcell` |
| `elite_c` | `rp2040_ce` |
| `elite_c` | `elite_pi` |
@@ -87,6 +88,7 @@ If a board currently supported in QMK uses a [Pro Micro](https://www.sparkfun.co
| [Liatris](https://splitkb.com/products/liatris) | `liatris` |
| [Imera](https://splitkb.com/products/imera) | `imera` |
| [Michi](https://github.com/ci-bus/michi-promicro-rp2040) | `michi` |
+| [Svlinky](https://github.com/sadekbaroudi/svlinky) | `svlinky` |
Converter summary:
@@ -105,6 +107,7 @@ Converter summary:
| `liatris` | `-e CONVERT_TO=liatris` | `CONVERT_TO=liatris` | `#ifdef CONVERT_TO_LIATRIS` |
| `imera` | `-e CONVERT_TO=imera` | `CONVERT_TO=imera` | `#ifdef CONVERT_TO_IMERA` |
| `michi` | `-e CONVERT_TO=michi` | `CONVERT_TO=michi` | `#ifdef CONVERT_TO_MICHI` |
+| `svlinky` | `-e CONVERT_TO=svlinky` | `CONVERT_TO=svlinky` | `#ifdef CONVERT_TO_SVLINKY` |
### Proton C {#proton_c}
@@ -170,6 +173,9 @@ The Bonsai C4 only has one on-board LED (B2), and by default, both the Pro Micro
Feature set is identical to [Adafruit KB2040](#kb2040). VBUS detection is enabled by default for superior split keyboard support. For more information, refer to the [Community Edition pinout](platformdev_rp2040#rp2040_ce) docs.
+### Svlinky {#svlinky}
+
+Feature set is a pro micro equivalent of the [RP2040 Community Edition](#rp2040_ce), except that two of the analog GPIO have been replaced with digital only GPIO. These two were moved to the FPC connector to support the [VIK specification](https://github.com/sadekbaroudi/vik). This means that if you are expecting analog support on all 4 pins as provided on a RP2040 Community Edition pinout, you will not have that. Please see the [Svlinky github page](https://github.com/sadekbaroudi/svlinky) for more details.
## Elite-C
diff --git a/docs/feature_layers.md b/docs/feature_layers.md
index fe9932fadb..45f02fe536 100644
--- a/docs/feature_layers.md
+++ b/docs/feature_layers.md
@@ -17,6 +17,9 @@ These functions allow you to activate layers in various ways. Note that layers a
* `TO(layer)` - activates *layer* and de-activates all other layers (except your default layer). This function is special, because instead of just adding/removing one layer to your active layer stack, it will completely replace your current active layers, uniquely allowing you to replace higher layers with a lower one. This is activated on keydown (as soon as the key is pressed).
* `TT(layer)` - Layer Tap-Toggle. If you hold the key down, *layer* is activated, and then is de-activated when you let go (like `MO`). If you repeatedly tap it, the layer will be toggled on or off (like `TG`). It needs 5 taps by default, but you can change this by defining `TAPPING_TOGGLE` -- for example, `#define TAPPING_TOGGLE 2` to toggle on just two taps.
+See also the [Layer Lock key](features/layer_lock), which locks the highest
+active layer until pressed again.
+
### Caveats {#caveats}
Currently, the `layer` argument of `LT()` is limited to layers 0-15, and the `kc` argument to the [Basic Keycode set](keycodes_basic), meaning you can't use keycodes like `LCTL()`, `KC_TILD`, or anything greater than `0xFF`. This is because QMK uses 16-bit keycodes, of which 4 bits are used for the function identifier and 4 bits for the layer, leaving only 8 bits for the keycode.
@@ -74,6 +77,7 @@ There are a number of functions (and variables) related to how you can use or ma
| `default_layer_and(layer_mask)` | Turns on layers based on matching enabled bits between specifed layer and existing default layer state. |
| `default_layer_xor(layer_mask)` | Turns on layers based on non-matching bits between specifed layer and existing default layer state. |
| `default_layer_debug(layer_mask)` | Prints out the current bit mask and highest active default layer to debugger console. |
+| [`set_single_default_layer(layer)`](ref_functions.md#setting-the-persistent-default-layer) | Sets the default layer, but does _not_ write it to persistent memory (EEPROM). |
| [`set_single_persistent_default_layer(layer)`](ref_functions.md#setting-the-persistent-default-layer) | Sets the default layer and writes it to persistent memory (EEPROM). |
| [`update_tri_layer(x, y, z)`](ref_functions.md#update_tri_layerx-y-z) | Checks if layers `x` and `y` are both on, and sets `z` based on that (on if both on, otherwise off). |
| [`update_tri_layer_state(state, x, y, z)`](ref_functions.md#update_tri_layer_statestate-x-y-z) | Does the same as `update_tri_layer(x, y, z)`, but from `layer_state_set_*` functions. |
diff --git a/docs/features/combo.md b/docs/features/combo.md
index bdb8c4b15f..afe202ad54 100644
--- a/docs/features/combo.md
+++ b/docs/features/combo.md
@@ -152,14 +152,15 @@ In order to use these features, the following configuration options and function
| Config Flag | Function | Description |
|-----------------------------|-----------------------------------------------------------|--------------------------------------------------------------------------------------------------------|
-| `COMBO_TERM_PER_COMBO` | uint16_t get_combo_term(uint16_t index, combo_t \*combo) | Optional per-combo timeout window. (default: `COMBO_TERM`) |
-| `COMBO_MUST_HOLD_PER_COMBO` | bool get_combo_must_hold(uint16_t index, combo_t \*combo) | Controls if a given combo should fire immediately on tap or if it needs to be held. (default: `false`) |
-| `COMBO_MUST_TAP_PER_COMBO` | bool get_combo_must_tap(uint16_t index, combo_t \*combo) | Controls if a given combo should fire only if tapped within `COMBO_HOLD_TERM`. (default: `false`) |
-| `COMBO_MUST_PRESS_IN_ORDER_PER_COMBO` | bool get_combo_must_press_in_order(uint16_t index, combo_t \*combo) | Controls if a given combo should fire only if its keys are pressed in order. (default: `true`) |
+| `COMBO_TERM_PER_COMBO` | `uint16_t get_combo_term(uint16_t combo_index, combo_t *combo)` | Optional per-combo timeout window. (default: `COMBO_TERM`) |
+| `COMBO_MUST_HOLD_PER_COMBO` | `bool get_combo_must_hold(uint16_t combo_index, combo_t *combo)` | Controls if a given combo should fire immediately on tap or if it needs to be held. (default: `false`) |
+| `COMBO_MUST_TAP_PER_COMBO` | `bool get_combo_must_tap(uint16_t combo_index, combo_t *combo)` | Controls if a given combo should fire only if tapped within `COMBO_HOLD_TERM`. (default: `false`) |
+| `COMBO_MUST_PRESS_IN_ORDER_PER_COMBO` | `bool get_combo_must_press_in_order(uint16_t combo_index, combo_t *combo)` | Controls if a given combo should fire only if its keys are pressed in order. (default: `true`) |
Examples:
```c
-uint16_t get_combo_term(uint16_t index, combo_t *combo) {
+#ifdef COMBO_TERM_PER_COMBO
+uint16_t get_combo_term(uint16_t combo_index, combo_t *combo) {
// decide by combo->keycode
switch (combo->keycode) {
case KC_X:
@@ -167,7 +168,7 @@ uint16_t get_combo_term(uint16_t index, combo_t *combo) {
}
// or with combo index, i.e. its name from enum.
- switch (index) {
+ switch (combo_index) {
case COMBO_NAME_HERE:
return 9001;
}
@@ -182,8 +183,10 @@ uint16_t get_combo_term(uint16_t index, combo_t *combo) {
return COMBO_TERM;
}
+#endif
-bool get_combo_must_hold(uint16_t index, combo_t *combo) {
+#ifdef COMBO_MUST_HOLD_PER_COMBO
+bool get_combo_must_hold(uint16_t combo_index, combo_t *combo) {
// Same as above, decide by keycode, the combo index, or by the keys in the chord.
if (KEYCODE_IS_MOD(combo->keycode) ||
@@ -192,15 +195,17 @@ bool get_combo_must_hold(uint16_t index, combo_t *combo) {
return true;
}
- switch (index) {
+ switch (combo_index) {
case COMBO_NAME_HERE:
return true;
}
return false;
}
+#endif
-bool get_combo_must_tap(uint16_t index, combo_t *combo) {
+#ifdef COMBO_MUST_TAP_PER_COMBO
+bool get_combo_must_tap(uint16_t combo_index, combo_t *combo) {
// If you want all combos to be tap-only, just uncomment the next line
// return true
@@ -219,7 +224,9 @@ bool get_combo_must_tap(uint16_t index, combo_t *combo) {
return false;
}
+#endif
+#ifdef COMBO_MUST_PRESS_IN_ORDER_PER_COMBO
bool get_combo_must_press_in_order(uint16_t combo_index, combo_t *combo) {
switch (combo_index) {
/* List combos here that you want to only activate if their keys
@@ -231,6 +238,7 @@ bool get_combo_must_press_in_order(uint16_t combo_index, combo_t *combo) {
return false;
}
}
+#endif
```
### Generic hook to (dis)allow a combo activation
@@ -307,6 +315,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/features/joystick.md b/docs/features/joystick.md
index 69db4655d5..cbf6c6daf7 100644
--- a/docs/features/joystick.md
+++ b/docs/features/joystick.md
@@ -1,6 +1,6 @@
# Joystick {#joystick}
-This feature provides game controller input as a joystick device supporting up to 6 axes and 32 buttons. Axes can be read either from an [ADC-capable input pin](../drivers/adc), or can be virtual, so that its value is provided by your code.
+This feature provides game controller input as a joystick device supporting up to 6 axes, 32 buttons and a hat switch. Axes can be read either from an [ADC-capable input pin](../drivers/adc), or can be virtual, so that its value is provided by your code.
An analog device such as a [potentiometer](https://en.wikipedia.org/wiki/Potentiometer) found on an analog joystick's axes is based on a voltage divider, where adjusting the movable wiper controls the output voltage which can then be read by the microcontroller's ADC.
@@ -37,6 +37,42 @@ By default, two axes and eight buttons are defined, with a reported resolution o
You must define at least one button or axis. Also note that the maximum ADC resolution of the supported AVR MCUs is 10-bit, and 12-bit for most STM32 MCUs.
:::
+### Hat Switch {#hat-switch}
+
+To enable the 8-way hat switch, add the following to your `config.h`:
+
+```c
+#define JOYSTICK_HAS_HAT
+````
+
+The position can be set by calling `joystick_set_hat(value)`. The range of values moves clockwise from the top (ie. north), with the default "center" position represented by a value of `-1`:
+
+```
+ 0
+ 7 N 1
+ NW .--'--. NE
+ / \
+6 W | -1 | E 2
+ \ /
+ SW '--.--' SE
+ 5 S 3
+ 4
+```
+
+Alternatively you can use these predefined names:
+
+|Define |Value|Angle|
+|------------------------|-----|-----|
+|`JOYSTICK_HAT_CENTER` |`-1` | |
+|`JOYSTICK_HAT_NORTH` |`0` |0° |
+|`JOYSTICK_HAT_NORTHEAST`|`1` |45° |
+|`JOYSTICK_HAT_EAST` |`2` |90° |
+|`JOYSTICK_HAT_SOUTHEAST`|`3` |135° |
+|`JOYSTICK_HAT_SOUTH` |`4` |180° |
+|`JOYSTICK_HAT_SOUTHWEST`|`5` |225° |
+|`JOYSTICK_HAT_WEST` |`6` |270° |
+|`JOYSTICK_HAT_NORTHWEST`|`7` |315° |
+
### Axes {#axes}
When defining axes for your joystick, you must provide a definition array typically in your `keymap.c`.
@@ -149,6 +185,8 @@ Contains the state of the joystick.
A bit-packed array containing the joystick button states. The size is calculated as `(JOYSTICK_BUTTON_COUNT - 1) / 8 + 1`.
- `int16_t axes[]`
An array of analog values for each defined axis.
+ - `int8_t hat`
+ The hat switch position.
- `bool dirty`
Whether the current state needs to be sent to the host.
@@ -222,3 +260,14 @@ Set the value of the given axis.
The axis to set the value of.
- `int16_t value`
The value to set.
+
+---
+
+### `void joystick_set_hat(int8_t value)` {#api-joystick-set-hat}
+
+Set the position of the hat switch.
+
+#### Arguments {#api-joystick-set-hat-arguments}
+
+ - `int8_t value`
+ The hat switch position to set.
diff --git a/docs/features/layer_lock.md b/docs/features/layer_lock.md
new file mode 100644
index 0000000000..aaf323accc
--- /dev/null
+++ b/docs/features/layer_lock.md
@@ -0,0 +1,139 @@
+# Layer Lock
+
+Some [layer switches](../feature_layers#switching-and-toggling-layers) access
+the layer by holding the key, including momentary layer `MO(layer)` and layer
+tap `LT(layer, key)` keys. You may sometimes need to stay on the layer for a
+long period of time. Layer Lock "locks" the current layer to stay on, supposing
+it was accessed by one of:
+
+ * `MO(layer)` momentary layer switch
+ * `LT(layer, key)` layer tap
+ * `OSL(layer)` one-shot layer
+ * `TT(layer)` layer tap toggle
+ * `LM(layer, mod)` layer-mod key (the layer is locked, but not the mods)
+
+Press the Layer Lock key again to unlock the layer. Additionally, when a layer
+is locked, layer switch keys that turn off the layer such as `TO(other_layer)`
+will unlock it.
+
+
+## How do I enable Layer Lock
+
+In your rules.mk, add:
+
+```make
+LAYER_LOCK_ENABLE = yes
+```
+
+Pick a key in your keymap on a layer you intend to lock, and assign it the
+keycode `QK_LAYER_LOCK` (short alias `QK_LLCK`). Note that locking the base
+layer has no effect, so typically, this key is used on layers above the base
+layer.
+
+
+## Example use
+
+Consider a keymap with the following base layer.
+
+![Base layer with a MO(NAV) key.](https://i.imgur.com/DkEhj9x.png)
+
+The highlighted key is a momentary layer switch `MO(NAV)`. Holding it accesses a
+navigation layer.
+
+![Nav layer with a Layer Lock key.](https://i.imgur.com/2wUZNWk.png)
+
+
+Holding the NAV key is fine for brief use, but awkward to continue holding when
+using navigation functions continuously. The Layer Lock key comes to the rescue:
+
+1. Hold the NAV key, activating the navigation layer.
+2. Tap Layer Lock.
+3. Release NAV. The navigation layer stays on.
+4. Make use of the arrow keys, etc.
+5. Tap Layer Lock or NAV again to turn the navigation layer back off.
+
+A variation that would also work is to put the Layer Lock key on the base layer
+and make other layers transparent (`KC_TRNS`) in that position. Pressing the
+Layer Lock key locks (or unlocks) the highest active layer, regardless of which
+layer the Layer Lock key is on.
+
+
+## Idle timeout
+
+Optionally, Layer Lock may be configured to unlock if the keyboard is idle
+for some time. In config.h, define `LAYER_LOCK_IDLE_TIMEOUT` in units of
+milliseconds:
+
+```c
+#define LAYER_LOCK_IDLE_TIMEOUT 60000 // Turn off after 60 seconds.
+```
+
+
+## Functions
+
+Use the following functions to query and manipulate the layer lock state.
+
+| Function | Description |
+|----------------------------|------------------------------------|
+| `is_layer_locked(layer)` | Checks whether `layer` is locked. |
+| `layer_lock_on(layer)` | Locks and turns on `layer`. |
+| `layer_lock_off(layer)` | Unlocks and turns off `layer`. |
+| `layer_lock_invert(layer)` | Toggles whether `layer` is locked. |
+
+
+## Representing the current Layer Lock state
+
+There is an optional callback `layer_lock_set_user()` that gets called when a
+layer is locked or unlocked. This is useful to represent the current lock state
+for instance by setting an LED. In keymap.c, define
+
+```c
+bool layer_lock_set_user(layer_state_t locked_layers) {
+ // Do something like `set_led(is_layer_locked(NAV));`
+ return true;
+}
+```
+
+The argument `locked_layers` is a bitfield in which the kth bit is on if the kth
+layer is locked. Alternatively, you can use `is_layer_locked(layer)` to check if
+a given layer is locked.
+
+
+## Combine Layer Lock with a mod-tap
+
+It is possible to create a [mod-tap MT key](../mod_tap) that acts as a modifier
+on hold and Layer Lock on tap. Since Layer Lock is not a [basic
+keycode](../keycodes_basic), attempting `MT(mod, QK_LLCK)` is invalid does not
+work directly, yet this effect can be achieved through [changing the tap
+function](../mod_tap#changing-tap-function). For example, the following
+implements a `SFTLLCK` key that acts as Shift on hold and Layer Lock on tap:
+
+```c
+#define SFTLLCK LSFT_T(KC_0)
+
+// Use SFTLLCK in your keymap...
+
+bool process_record_user(uint16_t keycode, keyrecord_t *record) {
+ switch (keycode) {
+ case SFTLLCK:
+ if (record->tap.count) {
+ if (record->event.pressed) {
+ // Toggle the lock on the highest layer.
+ layer_lock_invert(get_highest_layer(layer_state));
+ }
+ return false;
+ }
+ break;
+
+ // Other macros...
+ }
+ return true;
+}
+```
+
+In the above, `KC_0` is an arbitrary placeholder for the tapping keycode. This
+keycode will never be sent, so any basic keycode will do. In
+`process_record_user()`, the tap press event is changed to toggle the lock on
+the highest layer. Layer Lock can be combined with a [layer-tap LT
+key](../feature_layers#switching-and-toggling-layers) similarly.
+
diff --git a/docs/features/os_detection.md b/docs/features/os_detection.md
index d0556d2549..880e88d4b9 100644
--- a/docs/features/os_detection.md
+++ b/docs/features/os_detection.md
@@ -70,17 +70,33 @@ The process is done in steps, generating a number of intermediate results until
We therefore resort to debouncing the result until it has been stable for a given amount of milliseconds.
This amount can be configured, in case your board is not stable within the default debouncing time of 200ms.
-## KVM and USB switches
-
-Some KVM and USB switches may not trigger the USB controller on the keyboard to fully reset upon switching machines.
-If your keyboard does not redetect the OS in this situation, you can force the keyboard to reset when the USB initialization event is detected, forcing the USB controller to be reconfigured.
-
## Configuration Options
-* `#define OS_DETECTION_DEBOUNCE 200`
+* `#define OS_DETECTION_DEBOUNCE 250`
* defined the debounce time for OS detection, in milliseconds
+ * defaults to 250ms
* `#define OS_DETECTION_KEYBOARD_RESET`
- * enables the keyboard reset upon a USB device reinitilization, such as switching devices on some KVMs
+ * enables the keyboard reset upon a USB device reinitilization
+ * this setting may help with detection issues when switching between devices on some KVMs (see [Troubleshooting](#troubleshooting))
+* `#define OS_DETECTION_SINGLE_REPORT`
+ * allows the report callbacks to be called only once, when the OS detection result is considered stable
+ * subsequent changes in the detection results, if any, are ignored
+ * this setting may help with delayed stability issues when switching devices on some KVMs (see [Troubleshooting](#troubleshooting))
+
+## Troubleshooting
+
+Some KVMs and USB switches may cause issues when the OS detection is turned on.
+Here is a list of common issues and how to fix them:
+
+* **Problem**: _keyboard won't redetect the OS when switching between machines using a KVM_
+ * **Explanation**: some KVMs keep the USB controller powered on during the switch and OS
+ detection happens when the USB device description is being assembled.
+ * **Solution**: use `OS_DETECTION_KEYBOARD_RESET` to force the keyboard to reset upon switching.
+* **Problem**: _keyboard OS detection callback gets invoked even minuted after startup_
+ * **Explanation**: some OSes, notably macOS on ARM-based Macs, may cause this behavior.
+ The actual cause is not known at this time.'
+ * **Solution**: use `OS_DETECTION_SINGLE_REPORT` to suppress repeated callback invocations.
+
## Debug
diff --git a/docs/features/pointing_device.md b/docs/features/pointing_device.md
index a6bf521a18..0ecf82c8df 100644
--- a/docs/features/pointing_device.md
+++ b/docs/features/pointing_device.md
@@ -394,6 +394,7 @@ Ideally, new sensor hardware should be added to `drivers/sensors/` and `quantum/
| Setting | Description | Default |
| ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------- |
| `MOUSE_EXTENDED_REPORT` | (Optional) Enables support for extended mouse reports. (-32767 to 32767, instead of just -127 to 127). | _not defined_ |
+| `WHEEL_EXTENDED_REPORT` | (Optional) Enables support for extended wheel reports. (-32767 to 32767, instead of just -127 to 127). | _not defined_ |
| `POINTING_DEVICE_ROTATION_90` | (Optional) Rotates the X and Y data by 90 degrees. | _not defined_ |
| `POINTING_DEVICE_ROTATION_180` | (Optional) Rotates the X and Y data by 180 degrees. | _not defined_ |
| `POINTING_DEVICE_ROTATION_270` | (Optional) Rotates the X and Y data by 270 degrees. | _not defined_ |
diff --git a/docs/features/rgb_matrix.md b/docs/features/rgb_matrix.md
index bc14bb6277..0e53ce9c35 100644
--- a/docs/features/rgb_matrix.md
+++ b/docs/features/rgb_matrix.md
@@ -81,38 +81,21 @@ As mentioned earlier, the center of the keyboard by default is expected to be `{
## Keycodes {#keycodes}
-All RGB keycodes are currently shared with the RGBLIGHT system:
-
-|Key |Aliases |Description |
-|-------------------|----------|--------------------------------------------------------------------------------------|
-|`RGB_TOG` | |Toggle RGB lighting on or off |
-|`RGB_MODE_FORWARD` |`RGB_MOD` |Cycle through modes, reverse direction when Shift is held |
-|`RGB_MODE_REVERSE` |`RGB_RMOD`|Cycle through modes in reverse, forward direction when Shift is held |
-|`RGB_HUI` | |Increase hue, decrease hue when Shift is held |
-|`RGB_HUD` | |Decrease hue, increase hue when Shift is held |
-|`RGB_SAI` | |Increase saturation, decrease saturation when Shift is held |
-|`RGB_SAD` | |Decrease saturation, increase saturation when Shift is held |
-|`RGB_VAI` | |Increase value (brightness), decrease value when Shift is held |
-|`RGB_VAD` | |Decrease value (brightness), increase value when Shift is held |
-|`RGB_SPI` | |Increase effect speed (does not support eeprom yet), decrease speed when Shift is held|
-|`RGB_SPD` | |Decrease effect speed (does not support eeprom yet), increase speed when Shift is held|
-|`RGB_MODE_PLAIN` |`RGB_M_P` |Static (no animation) mode |
-|`RGB_MODE_BREATHE` |`RGB_M_B` |Breathing animation mode |
-|`RGB_MODE_RAINBOW` |`RGB_M_R` |Full gradient scrolling left to right (uses the `RGB_MATRIX_CYCLE_LEFT_RIGHT` mode) |
-|`RGB_MODE_SWIRL` |`RGB_M_SW`|Full gradient spinning pinwheel around center of keyboard (uses `RGB_MATRIX_CYCLE_PINWHEEL` mode) |
-
-* `RGB_MODE_*` keycodes will generally work, but not all of the modes are currently mapped to the correct effects for the RGB Matrix system.
-
-`RGB_MODE_PLAIN`, `RGB_MODE_BREATHE`, `RGB_MODE_RAINBOW`, and `RGB_MODE_SWIRL` are the only ones that are mapped properly. The rest don't have a direct equivalent, and are not mapped.
-
-::: tip
-`RGB_*` keycodes cannot be used with functions like `tap_code16(RGB_HUD)` as they're not USB HID keycodes. If you wish to replicate similar behaviour in custom code within your firmware (e.g. inside `encoder_update_user()` or `process_record_user()`), the equivalent [RGB functions](#functions) should be used instead.
-:::
-
-
-::: warning
-By default, if you have both the [RGB Light](rgblight) and the RGB Matrix feature enabled, these keycodes will work for both features, at the same time. You can disable the keycode functionality by defining the `*_DISABLE_KEYCODES` option for the specific feature.
-:::
+|Key |Aliases |Description |
+|-------------------------------|---------|-----------------------------------|
+|`QK_RGB_MATRIX_ON` |`RM_ON` |Turn on RGB Matrix |
+|`QK_RGB_MATRIX_OFF` |`RM_OFF` |Turn off RGB Matrix |
+|`QK_RGB_MATRIX_TOGGLE` |`RM_TOGG`|Toggle RGB Matrix on or off |
+|`QK_RGB_MATRIX_MODE_NEXT` |`RM_NEXT`|Cycle through animations |
+|`QK_RGB_MATRIX_MODE_PREVIOUS` |`RM_PREV`|Cycle through animations in reverse|
+|`QK_RGB_MATRIX_HUE_UP` |`RM_HUEU`|Cycle through hue |
+|`QK_RGB_MATRIX_HUE_DOWN` |`RM_HUED`|Cycle through hue in reverse |
+|`QK_RGB_MATRIX_SATURATION_UP` |`RM_SATU`|Increase the saturation |
+|`QK_RGB_MATRIX_SATURATION_DOWN`|`RM_SATD`|Decrease the saturation |
+|`QK_RGB_MATRIX_VALUE_UP` |`RM_VALU`|Increase the brightness level |
+|`QK_RGB_MATRIX_VALUE_DOWN` |`RM_VALD`|Decrease the brightness level |
+|`QK_RGB_MATRIX_SPEED_UP` |`RM_SPDU`|Increase the animation speed |
+|`QK_RGB_MATRIX_SPEED_DOWN` |`RM_SPDD`|Decrease the animation speed |
## RGB Matrix Effects {#rgb-matrix-effects}
@@ -289,7 +272,7 @@ Solid reactive effects will pulse RGB light on key presses with user configurabl
#define RGB_MATRIX_SOLID_REACTIVE_GRADIENT_MODE
```
-Gradient mode will loop through the color wheel hues over time and its duration can be controlled with the effect speed keycodes (`RGB_SPI`/`RGB_SPD`).
+Gradient mode will loop through the color wheel hues over time and its duration can be controlled with the effect speed keycodes (`RM_SPDU`/`RM_SPDD`).
## Custom RGB Matrix Effects {#custom-rgb-matrix-effects}
@@ -396,7 +379,6 @@ These are defined in [`color.h`](https://github.com/qmk/qmk_firmware/blob/master
#define RGB_MATRIX_DEFAULT_VAL RGB_MATRIX_MAXIMUM_BRIGHTNESS // Sets the default brightness value, if none has been set
#define RGB_MATRIX_DEFAULT_SPD 127 // Sets the default animation speed, if none has been set
#define RGB_MATRIX_DEFAULT_FLAGS LED_FLAG_ALL // Sets the default LED flags, if none has been set
-#define RGB_MATRIX_DISABLE_KEYCODES // disables control of rgb matrix by keycodes (must use code functions to control the feature)
#define RGB_MATRIX_SPLIT { X, Y } // (Optional) For split keyboards, the number of LEDs connected on each half. X = left, Y = Right.
// If reactive effects are enabled, you also will want to enable SPLIT_TRANSPORT_MIRROR
#define RGB_TRIGGER_ON_KEYDOWN // Triggers RGB keypress events on key down. This makes RGB control feel more responsive. This may cause RGB to not function properly on some boards
@@ -496,18 +478,18 @@ This example sets the modifiers to be a specific color based on the layer state.
```c
bool rgb_matrix_indicators_advanced_user(uint8_t led_min, uint8_t led_max) {
- HSV hsv = {0, 255, 255};
+ hsv_t hsv = {0, 255, 255};
if (layer_state_is(layer_state, 2)) {
- hsv = (HSV){130, 255, 255};
+ hsv = (hsv_t){130, 255, 255};
} else {
- hsv = (HSV){30, 255, 255};
+ hsv = (hsv_t){30, 255, 255};
}
if (hsv.v > rgb_matrix_get_val()) {
hsv.v = rgb_matrix_get_val();
}
- RGB rgb = hsv_to_rgb(hsv);
+ rgb_t rgb = hsv_to_rgb(hsv);
for (uint8_t i = led_min; i < led_max; i++) {
if (HAS_FLAGS(g_led_config.flags[i], 0x01)) { // 0x01 == LED_FLAG_MODIFIER
@@ -873,13 +855,13 @@ Set the global effect hue, saturation, and value (brightness). New state is not
---
-### `HSV rgb_matrix_get_hsv(void)` {#api-rgb-matrix-get-hsv}
+### `hsv_t rgb_matrix_get_hsv(void)` {#api-rgb-matrix-get-hsv}
Get the current global effect hue, saturation, and value (brightness).
#### Return Value {#api-rgb-matrix-get-hsv-return}
-The current effect HSV as an `HSV` struct.
+The current effect HSV as an `hsv_t` struct.
---
diff --git a/docs/features/rgblight.md b/docs/features/rgblight.md
index 794398a0f9..4322fe796e 100644
--- a/docs/features/rgblight.md
+++ b/docs/features/rgblight.md
@@ -59,6 +59,10 @@ Changing the **Value** sets the overall brightness.<br>
## Keycodes
+::: warning
+These keycodes also simultaneously control [RGB Matrix](rgb_matrix), if enabled. This behaviour is in the process of being deprecated, so during this time it is recommended to additionally include the dedicated RGB Matrix keycodes to your keymap, and add `#define RGB_MATRIX_DISABLE_SHARED_KEYCODES` to `config.h`.
+:::
+
|Key |Aliases |Description |
|------------------------------|----------|---------------------------------------------------------------------|
|`QK_UNDERGLOW_TOGGLE` |`UG_TOGG` |Toggle RGB lighting on or off |
@@ -87,11 +91,6 @@ Changing the **Value** sets the overall brightness.<br>
These keycodes cannot be used with functions like `tap_code16()` as they are not USB HID keycodes. If you wish to replicate similar behaviour in custom code within your firmware (e.g. inside `encoder_update_user()` or `process_record_user()`), the equivalent [RGB functions](#functions) should be used instead.
:::
-
-::: warning
-By default, if you have both the RGB Light and the [RGB Matrix](rgb_matrix) feature enabled, these keycodes will work for both features, at the same time. You can disable the keycode functionality by defining the `*_DISABLE_KEYCODES` option for the specific feature.
-:::
-
## Configuration
Your RGB lighting can be configured by placing these `#define`s in your `config.h`:
@@ -104,7 +103,6 @@ Your RGB lighting can be configured by placing these `#define`s in your `config.
|`RGBLIGHT_LIMIT_VAL` |`255` |The maximum brightness level |
|`RGBLIGHT_SLEEP` |*Not defined* |If defined, the RGB lighting will be switched off when the host goes to sleep |
|`RGBLIGHT_SPLIT` |*Not defined* |If defined, synchronization functionality for split keyboards is added |
-|`RGBLIGHT_DISABLE_KEYCODES`|*Not defined* |If defined, disables the ability to control RGB Light from the keycodes. You must use code functions to control the feature|
|`RGBLIGHT_DEFAULT_MODE` |`RGBLIGHT_MODE_STATIC_LIGHT`|The default mode to use upon clearing the EEPROM |
|`RGBLIGHT_DEFAULT_HUE` |`0` (red) |The default hue to use upon clearing the EEPROM |
|`RGBLIGHT_DEFAULT_SAT` |`UINT8_MAX` (255) |The default saturation to use upon clearing the EEPROM |
diff --git a/docs/features/bluetooth.md b/docs/features/wireless.md
index 1dbf15f4e1..0d73ad3583 100644
--- a/docs/features/bluetooth.md
+++ b/docs/features/wireless.md
@@ -1,4 +1,4 @@
-# Bluetooth
+# Wireless / Bluetooth
## Bluetooth Known Supported Hardware
@@ -39,8 +39,20 @@ 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_AUTO` | `OU_AUTO` | Automatically switch to USB when plugged in, otherwise use wireless |
+| `QK_OUTPUT_NEXT` | `OU_NEXT` | Cycle forwards through USB, Bluetooth, and 2.4GHz (when available) **(not yet implemented)** |
+| `QK_OUTPUT_PREV` | `OU_PREV` | Cycle backwards through USB, Bluetooth, and 2.4GHz (when available) **(not yet implemented)** |
+| `QK_OUTPUT_NONE` | `OU_NONE` | Disable all output **(not yet implemented)** |
+| `QK_OUTPUT_USB` | `OU_USB` | Output to USB only |
+| `QK_OUTPUT_2P4GHZ` | `OU_2P4G` | Output to 2.4GHz only **(not yet implemented)** |
+| `QK_OUTPUT_BLUETOOTH` | `OU_BT` | Output to Bluetooth only |
+| `QK_BLUETOOTH_PROFILE_NEXT` | `BT_NEXT` | Move to the next Bluetooth profile **(not yet implemented)** |
+| `QK_BLUETOOTH_PROFILE_PREV` | `BT_PREV` | Move to the previous Bluetooth profile **(not yet implemented)** |
+| `QK_BLUETOOTH_UNPAIR` | `BT_UNPR` | Un-pair the current Bluetooth profile **(not yet implemented)** |
+| `QK_BLUETOOTH_PROFILE1` | `BT_PRF1` | Swap to Bluetooth profile #1 **(not yet implemented)** |
+| `QK_BLUETOOTH_PROFILE2` | `BT_PRF2` | Swap to Bluetooth profile #2 **(not yet implemented)** |
+| `QK_BLUETOOTH_PROFILE3` | `BT_PRF3` | Swap to Bluetooth profile #3 **(not yet implemented)** |
+| `QK_BLUETOOTH_PROFILE4` | `BT_PRF4` | Swap to Bluetooth profile #4 **(not yet implemented)** |
+| `QK_BLUETOOTH_PROFILE5` | `BT_PRF5` | Swap to Bluetooth profile #5 **(not yet implemented)** |
diff --git a/docs/flashing.md b/docs/flashing.md
index 2afb858860..29dc780aaf 100644
--- a/docs/flashing.md
+++ b/docs/flashing.md
@@ -345,6 +345,39 @@ Flashing sequence:
3. Flash a .bin file
4. Reset the device into application mode (may be done automatically)
+## AT32 DFU
+
+All AT32 MCUs come preloaded with a factory bootloader that cannot be modified nor deleted.
+
+To ensure compatibility with the AT32-DFU bootloader, make sure this block is present in your `rules.mk`:
+
+```make
+# Bootloader selection
+BOOTLOADER = at32-dfu
+```
+
+Compatible flashers:
+
+* [dfu-util](https://dfu-util.sourceforge.net/) / `:dfu-util` target in QMK (recommended command line)
+ ```
+ dfu-util -a 0 -d 2E3C:DF11 -s 0x8000000:leave -D <filename>
+ ```
+
+Flashing sequence:
+
+1. Enter the bootloader using any of the following methods:
+ * Tap the `QK_BOOT` keycode
+ * If a reset circuit is present, tap the `RESET` button on the PCB; some boards may also have a toggle switch that must be flipped
+ * Otherwise, you need to bridge `BOOT0` to VCC (via `BOOT0` button or jumper), short `RESET` to GND (via `RESET` button or jumper), and then let go of the `BOOT0` bridge
+2. Wait for the OS to detect the device
+3. Flash a .bin file
+4. Reset the device into application mode (may be done automatically)
+
+### `make` Targets
+
+* `:dfu-util`: Waits until an AT32 bootloader device is available, and then flashes the firmware.
+* `:dfu-util-split-left` and `:dfu-util-split-right`: Flashes the firmware as with `:dfu-util`, but also sets the handedness setting in EEPROM.
+
## tinyuf2
Keyboards may opt into supporting the tinyuf2 bootloader. This is currently only supported on F303/F401/F411.
diff --git a/docs/keycodes.md b/docs/keycodes.md
index 9038c2b6d7..cae6418266 100644
--- a/docs/keycodes.md
+++ b/docs/keycodes.md
@@ -290,15 +290,27 @@ See also: [Backlighting](features/backlight)
| `QK_BACKLIGHT_DOWN` | `BL_DOWN` | Decrease the backlight level |
| `QK_BACKLIGHT_TOGGLE_BREATHING` | `BL_BRTG` | Toggle backlight breathing |
-## Bluetooth {#bluetooth}
-
-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 |
+## Wireless/Bluetooth {#bluetooth}
+
+See also: [Wireless](features/wireless)
+
+| Key | Aliases | Description |
+|-----------------------------|-----------|-----------------------------------------------------------------------------------------------|
+| `QK_OUTPUT_AUTO` | `OU_AUTO` | Automatically switch to USB when plugged in, otherwise use wireless |
+| `QK_OUTPUT_NEXT` | `OU_NEXT` | Cycle forwards through USB, Bluetooth, and 2.4GHz (when available) **(not yet implemented)** |
+| `QK_OUTPUT_PREV` | `OU_PREV` | Cycle backwards through USB, Bluetooth, and 2.4GHz (when available) **(not yet implemented)** |
+| `QK_OUTPUT_NONE` | `OU_NONE` | Disable all output **(not yet implemented)** |
+| `QK_OUTPUT_USB` | `OU_USB` | Output to USB only |
+| `QK_OUTPUT_2P4GHZ` | `OU_2P4G` | Output to 2.4GHz only **(not yet implemented)** |
+| `QK_OUTPUT_BLUETOOTH` | `OU_BT` | Output to Bluetooth only |
+| `QK_BLUETOOTH_PROFILE_NEXT` | `BT_NEXT` | Move to the next Bluetooth profile **(not yet implemented)** |
+| `QK_BLUETOOTH_PROFILE_PREV` | `BT_PREV` | Move to the previous Bluetooth profile **(not yet implemented)** |
+| `QK_BLUETOOTH_UNPAIR` | `BT_UNPR` | Un-pair the current Bluetooth profile **(not yet implemented)** |
+| `QK_BLUETOOTH_PROFILE1` | `BT_PRF1` | Swap to Bluetooth profile #1 **(not yet implemented)** |
+| `QK_BLUETOOTH_PROFILE2` | `BT_PRF2` | Swap to Bluetooth profile #2 **(not yet implemented)** |
+| `QK_BLUETOOTH_PROFILE3` | `BT_PRF3` | Swap to Bluetooth profile #3 **(not yet implemented)** |
+| `QK_BLUETOOTH_PROFILE4` | `BT_PRF4` | Swap to Bluetooth profile #4 **(not yet implemented)** |
+| `QK_BLUETOOTH_PROFILE5` | `BT_PRF5` | Swap to Bluetooth profile #5 **(not yet implemented)** |
## Caps Word {#caps-word}
@@ -375,6 +387,14 @@ See also: [Key Lock](features/key_lock)
|---------|--------------------------------------------------------------|
|`QK_LOCK`|Hold down the next key pressed, until the key is pressed again|
+## Layer Lock {#layer-lock}
+
+See also: [Layer Lock](features/layer_lock)
+
+|Key |Aliases |Description |
+|---------------|---------|----------------------------------|
+|`QK_LAYER_LOCK`|`QK_LLCK`|Locks or unlocks the highest layer|
+
## Layer Switching {#layer-switching}
See also: [Layer Switching](feature_layers#switching-and-toggling-layers)
@@ -728,23 +748,25 @@ See also: [RGB Lighting](features/rgblight)
|`RGB_MODE_RGBTEST` |`RGB_M_T` |Red, Green, Blue test animation mode (deprecated) |
|`RGB_MODE_TWINKLE` |`RGB_M_TW`|Twinkle animation mode (deprecated) |
-## RGB Matrix Lighting {#rgb-matrix-lighting}
-
-See also: [RGB Matrix Lighting](features/rgb_matrix)
-
-|Key |Aliases |Description |
-|-------------------|----------|--------------------------------------------------------------------------------------|
-|`RGB_TOG` | |Toggle RGB lighting on or off |
-|`RGB_MODE_FORWARD` |`RGB_MOD` |Cycle through modes, reverse direction when Shift is held |
-|`RGB_MODE_REVERSE` |`RGB_RMOD`|Cycle through modes in reverse, forward direction when Shift is held |
-|`RGB_HUI` | |Increase hue, decrease hue when Shift is held |
-|`RGB_HUD` | |Decrease hue, increase hue when Shift is held |
-|`RGB_SAI` | |Increase saturation, decrease saturation when Shift is held |
-|`RGB_SAD` | |Decrease saturation, increase saturation when Shift is held |
-|`RGB_VAI` | |Increase value (brightness), decrease value when Shift is held |
-|`RGB_VAD` | |Decrease value (brightness), increase value when Shift is held |
-|`RGB_SPI` | |Increase effect speed (does not support eeprom yet), decrease speed when Shift is held|
-|`RGB_SPD` | |Decrease effect speed (does not support eeprom yet), increase speed when Shift is held|
+## RGB Matrix {#rgb-matrix}
+
+See also: [RGB Matrix](features/rgb_matrix)
+
+|Key |Aliases |Description |
+|-------------------------------|---------|-----------------------------------|
+|`QK_RGB_MATRIX_ON` |`RM_ON` |Turn on RGB Matrix |
+|`QK_RGB_MATRIX_OFF` |`RM_OFF` |Turn off RGB Matrix |
+|`QK_RGB_MATRIX_TOGGLE` |`RM_TOGG`|Toggle RGB Matrix on or off |
+|`QK_RGB_MATRIX_MODE_NEXT` |`RM_NEXT`|Cycle through animations |
+|`QK_RGB_MATRIX_MODE_PREVIOUS` |`RM_PREV`|Cycle through animations in reverse|
+|`QK_RGB_MATRIX_HUE_UP` |`RM_HUEU`|Cycle through hue |
+|`QK_RGB_MATRIX_HUE_DOWN` |`RM_HUED`|Cycle through hue in reverse |
+|`QK_RGB_MATRIX_SATURATION_UP` |`RM_SATU`|Increase the saturation |
+|`QK_RGB_MATRIX_SATURATION_DOWN`|`RM_SATD`|Decrease the saturation |
+|`QK_RGB_MATRIX_VALUE_UP` |`RM_VALU`|Increase the brightness level |
+|`QK_RGB_MATRIX_VALUE_DOWN` |`RM_VALD`|Decrease the brightness level |
+|`QK_RGB_MATRIX_SPEED_UP` |`RM_SPDU`|Increase the animation speed |
+|`QK_RGB_MATRIX_SPEED_DOWN` |`RM_SPDD`|Decrease the animation speed |
## US ANSI Shifted Symbols {#us-ansi-shifted-symbols}
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/porting_your_keyboard_to_qmk.md b/docs/porting_your_keyboard_to_qmk.md
index e5a1f803f7..737ec4a2cf 100644
--- a/docs/porting_your_keyboard_to_qmk.md
+++ b/docs/porting_your_keyboard_to_qmk.md
@@ -4,52 +4,51 @@ This page describes the support for [Compatible Microcontrollers](compatible_mic
If you have not yet you should read the [Keyboard Guidelines](hardware_keyboard_guidelines) to get a sense of how keyboards fit into QMK.
-
QMK has a number of features to simplify working with keyboards. For most, you don't have to write a single line of code. To get started, run `qmk new-keyboard`:
```
$ qmk new-keyboard
Ψ Generating a new QMK keyboard directory
-Name Your Keyboard Project
-For more infomation, see:
-https://docs.qmk.fm/hardware_keyboard_guidelines#naming-your-keyboardproject
-
-keyboard Name? mycoolkeeb
-
-Attribution
-Used for maintainer, copyright, etc
-
-Your GitHub Username? [jsmith]
-
-More Attribution
-Used for maintainer, copyright, etc
-
-Your Real Name? [John Smith]
-
-Pick Base Layout
-As a starting point, one of the common layouts can be used to bootstrap the process
-
-Default Layout?
- 1. 60_ansi
-...
- 50. tkl_iso
- 51. none of the above
-Please enter your choice: [51]
-
-What Powers Your Project
-For more infomation, see:
-https://docs.qmk.fm/#/compatible_microcontrollers
-
-MCU?
- 1. atmega32u4
-...
- 22. STM32F303
-Please enter your choice: [12]
+Ψ Name Your Keyboard Project
+Ψ For more information, see:
+https://docs.qmk.fm/hardware_keyboard_guidelines#naming-your-keyboard-project
+Keyboard Name? mycoolkeeb
+Ψ Attribution
+Ψ Used for maintainer, copyright, etc.
+Your GitHub Username? [jsmith]
+Ψ More Attribution
+Ψ Used for maintainer, copyright, etc.
+Your Real Name? [John Smith]
+Ψ Pick Base Layout
+Ψ As a starting point, one of the common layouts can be used to
+bootstrap the process
+Default Layout?
+ 1. 60_abnt2
+ ...
+ 65. none of the above
+Please enter your choice: [65]
+Ψ What Powers Your Project
+Ψ Is your board using a separate development board, such as a Pro Micro,
+or is the microcontroller integrated onto the PCB?
+
+For more information, see:
+https://docs.qmk.fm/compatible_microcontrollers
+Using a Development Board? [y/n] y
+Ψ Select Development Board
+Ψ For more information, see:
+https://docs.qmk.fm/compatible_microcontrollers
+Development Board?
+ 1. bit_c_pro
+ ...
+ 14. promicro
+ ...
+ 18. svlinky
+Please enter your choice: [14]
Ψ Created a new keyboard called mycoolkeeb.
-Ψ To start working on things, `cd` into keyboards/mycoolkeeb,
-Ψ or open the directory in your preferred text editor.
-Ψ And build with qmk compile -kb mycoolkeeb -km default.
+Ψ Build Command: qmk compile -kb mycoolkeeb -km default.
+Ψ Project Location: /Users/jsmith/qmk_firmware/keyboards/mycoolkeeb.
+Ψ Now update the config files to match the hardware!
```
This will create all the files needed to support your new keyboard, and populate the settings with default values. Now you just need to customize it for your keyboard.
@@ -58,13 +57,13 @@ This will create all the files needed to support your new keyboard, and populate
This is where you'll describe your keyboard. Please follow the [Keyboard Readme Template](documentation_templates#keyboard-readmemd-template) when writing your `readme.md`. You're encouraged to place an image at the top of your `readme.md`, please use an external service such as [Imgur](https://imgur.com) to host the images.
-## `info.json`
+## `keyboard.json`
-The `info.json` file is where you configure the hardware and feature set for your keyboard. There are a lot of options that can be placed in that file, too many to list here. For a complete overview of available options see the [Data Driven Configuration Options](reference_info_json) page.
+The `keyboard.json` file is where you configure the hardware and feature set for your keyboard. There are a lot of options that can be placed in that file, too many to list here. For a complete overview of available options see the [Data Driven Configuration Options](reference_info_json) page.
### Hardware Configuration
-At the top of the `info.json` you'll find USB related settings. These control how your keyboard appears to the Operating System. If you don't have a good reason to change you should leave the `usb.vid` as `0xFEED`. For the `usb.pid` you should pick a number that is not yet in use.
+At the top of the `keyboard.json` you'll find USB related settings. These control how your keyboard appears to the Operating System. If you don't have a good reason to change you should leave the `usb.vid` as `0xFEED`. For the `usb.pid` you should pick a number that is not yet in use.
Do change the `manufacturer` and `keyboard_name` lines to accurately reflect your keyboard.
@@ -82,10 +81,11 @@ Do change the `manufacturer` and `keyboard_name` lines to accurately reflect you
Windows and macOS will display the `manufacturer` and `keyboard_name` in the list of USB devices. `lsusb` on Linux instead prefers the values in the list maintained by the [USB ID Repository](http://www.linux-usb.org/usb-ids.html). By default, it will only use `manufacturer` and `keyboard_name` if the list does not contain that `usb.vid` / `usb.pid`. `sudo lsusb -v` will show the values reported by the device, and they are also present in kernel logs after plugging it in.
:::
-
### Matrix Configuration
-The next section of the `info` file deals with your keyboard's matrix. The first thing you should define is which pins on your MCU are connected to rows and columns. To do so simply specify the names of those pins:
+The next section of the `keyboard.json` deals with your keyboard's matrix. The first thing you should define is which pins on your MCU are connected to rows and columns. To do so simply specify the names of those pins:
+
+#### Diode Matrix
```json
"matrix_pins": {
@@ -94,7 +94,7 @@ 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`).
+The matrix dimensions are inferred from the length of the `matrix_pins.cols` and `matrix_pins.rows` arrays (previously specified explicitly in `config.h` with `MATRIX_ROWS` and `MATRIX_COLS`).
Finally, you can specify the direction your diodes point. This can be `COL2ROW` or `ROW2COL`.
@@ -103,54 +103,56 @@ Finally, you can specify the direction your diodes point. This can be `COL2ROW`
```
#### Direct Pin Matrix
-To configure a keyboard where each switch is connected to a separate pin and ground instead of sharing row and column pins, use `matrix_pins.direct`. The mapping defines the pins of each switch in rows and columns, from left to right. The size of the `matrix_pins.direct` array infers the size of the matrix. Use `NO_PIN` to fill in blank spaces. Overrides the behaviour of `diode_direction`, `matrix_pins.cols` and `matrix_pins.rows`.
+
+To configure a keyboard where each switch is connected to a separate pin and ground instead of sharing row and column pins, use `matrix_pins.direct`. This overrides the behaviour of `diode_direction`, `matrix_pins.cols` and `matrix_pins.rows`, and they should not be specified together.
```json
"matrix_pins": {
"direct": [
- ["F1", "E6", "B0", "B2", "B3" ],
- ["F5", "F0", "B1", "B7", "D2" ],
- ["F6", "F7", "C7", "D5", "D3" ],
- ["B5", "C6", "B6", "NO_PIN", "NO_PIN"]
+ ["F1", "E6", "B0", "B2", "B3"],
+ ["F5", "F0", "B1", "B7", "D2"],
+ ["F6", "F7", "C7", "D5", "D3"],
+ ["B5", "C6", "B6", null, null]
]
},
```
-### Layout macros
+Here, the matrix dimensions are inferred directly from the dimensions of the `matrix_pins.direct` array. Since there are no row or column pins to prescribe the matrix dimensions, you can arrange it however you like. Each "row" must contain the same number of "column"s; use `null` to fill in blank spaces, but try to minimize them.
+
+### Layout Macros
-Next is configuring Layout Macro(s). These define the physical arrangement of keys, and its position within the matrix that a switch are connected to. This allows you to have a physical arrangement of keys that differs from the wiring matrix.
+Next is configuring layout macro(s). These define the physical arrangement of keys, and their position within the matrix that switches are connected to. This allows you to have a physical arrangement of keys that differs from the wiring matrix.
```json
"layouts": {
"LAYOUT_ortho_4x4": {
"layout": [
- { "matrix": [0, 0], "x": 0, "y": 0 },
- { "matrix": [0, 1], "x": 1, "y": 0 },
- { "matrix": [0, 2], "x": 2, "y": 0 },
- { "matrix": [0, 3], "x": 3, "y": 0 },
- { "matrix": [1, 0], "x": 0, "y": 1 },
- { "matrix": [1, 1], "x": 1, "y": 1 },
- { "matrix": [1, 2], "x": 2, "y": 1 },
- { "matrix": [1, 3], "x": 3, "y": 1 },
- { "matrix": [2, 0], "x": 0, "y": 2 },
- { "matrix": [2, 1], "x": 1, "y": 2 },
- { "matrix": [2, 2], "x": 2, "y": 2 },
- { "matrix": [2, 3], "x": 3, "y": 2 },
- { "matrix": [3, 0], "x": 0, "y": 3 },
- { "matrix": [3, 1], "x": 1, "y": 3 },
- { "matrix": [3, 2], "x": 2, "y": 3 },
- { "matrix": [3, 3], "x": 3, "y": 3 }
+ {"matrix": [0, 0], "x": 0, "y": 0},
+ {"matrix": [0, 1], "x": 1, "y": 0},
+ {"matrix": [0, 2], "x": 2, "y": 0},
+ {"matrix": [0, 3], "x": 3, "y": 0},
+ {"matrix": [1, 0], "x": 0, "y": 1},
+ {"matrix": [1, 1], "x": 1, "y": 1},
+ {"matrix": [1, 2], "x": 2, "y": 1},
+ {"matrix": [1, 3], "x": 3, "y": 1},
+ {"matrix": [2, 0], "x": 0, "y": 2},
+ {"matrix": [2, 1], "x": 1, "y": 2},
+ {"matrix": [2, 2], "x": 2, "y": 2},
+ {"matrix": [2, 3], "x": 3, "y": 2},
+ {"matrix": [3, 0], "x": 0, "y": 3},
+ {"matrix": [3, 1], "x": 1, "y": 3},
+ {"matrix": [3, 2], "x": 2, "y": 3},
+ {"matrix": [3, 3], "x": 3, "y": 3}
]
}
}
-
```
-In the above example,
+In the above example,
* `LAYOUT_ortho_4x4` defines the name of the layout macro
* It must conform to the [layout guidelines](hardware_keyboard_guidelines#keyboard-name-h)
-* `"matrix": [0, 0]` defines the electrical position
+* `"matrix": [0, 0]` defines the matrix row and column that the key is associated with
::: tip
See also: [Split Keyboard Layout Macro](features/split_keyboard#layout-macro) and [Matrix to Physical Layout](understanding_qmk#matrix-to-physical-layout-map).
@@ -158,9 +160,10 @@ See also: [Split Keyboard Layout Macro](features/split_keyboard#layout-macro) an
## Additional Configuration
-There are a lot of features that can be turned on or off, configured or tuned. Some of these have yet to be migrated over to [Data Driven Configuration](data_driven_config). The following sections cover the process for when an `info.json` option is unavailable.
+There are a lot of features that can be turned on or off, configured or tuned. Some of these have yet to be migrated over to [Data Driven Configuration](data_driven_config). The following sections cover the process for when a data-driven option is unavailable.
### Configuration Options
+
For available options for `config.h`, you should see the [Config Options](config_options#the-configh-file) page for more details.
### Build Options
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
diff --git a/docs/ref_functions.md b/docs/ref_functions.md
index 3304981ef5..599515ebc1 100644
--- a/docs/ref_functions.md
+++ b/docs/ref_functions.md
@@ -69,7 +69,7 @@ layer_state_t layer_state_set_user(layer_state_t state) {
Do you want to set the default layer, so that it's retained even after you unplug the board? If so, this is the function for you.
-To use this, you would use `set_single_persistent_default_layer(layer)`. If you have a name defined for your layer, you can use that instead (such as _QWERTY, _DVORAK or _COLEMAK).
+To do this, you would use `set_single_persistent_default_layer(layer)`. If you have a name defined for your layer, you can use that instead (such as _QWERTY, _DVORAK or _COLEMAK).
This will set the default layer, update the persistent settings, and play a tune if you have [Audio](features/audio) enabled on your board, and the default layer sounds set.
@@ -82,6 +82,8 @@ To configure the default layer sounds, you would want to define this in your `co
}
```
+If you do not require it to be retained after you unplug the board, use `set_single_default_layer(layer)` instead.
+
::: tip
There are a large number of predefined songs in [quantum/audio/song_list.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/audio/song_list.h) that you can use.
diff --git a/docs/reference_info_json.md b/docs/reference_info_json.md
index c1061cdf82..99ff7b1f7a 100644
--- a/docs/reference_info_json.md
+++ b/docs/reference_info_json.md
@@ -177,9 +177,9 @@ Configures the [Backlight](features/backlight) feature.
* `pins` <Badge type="info">Array: Pin</Badge>
* A list of GPIO pins connected to the backlight LEDs (`software` and `timer` drivers only).
-## Bluetooth {#bluetooth}
+## Wireless/Bluetooth {#bluetooth}
-Configures the [Bluetooth](features/bluetooth) feature.
+Configures the [Wireless](features/wireless) feature.
* `bluetooth`
* `driver` <Badge type="info">String</Badge>