zmkfirmware · caksoylar · Jan 21, 2024 · Jan 12, 2024 · Jan 12, 2024 · Jan 12, 2024
diff --git a/docs/.eslintrc.js b/docs/.eslintrc.js
@@ -8,6 +8,7 @@ module.exports = {
   extends: [
     "eslint:recommended",
     "plugin:react/recommended",
+    "plugin:react/jsx-runtime",
     "plugin:mdx/recommended",
     "prettier",
   ],
@@ -19,7 +20,7 @@ module.exports = {
     sourceType: "module",
   },
   plugins: ["react"],
-  rules: {},
+  rules: { "react/no-unescaped-entities": "off" },
   settings: {
     react: {
       version: "detect",

diff --git a/docs/blog/2023-11-09-keymap-editor.md → docs/blog/2023-11-09-keymap-editor.mdx b/docs/blog/2023-11-09-keymap-editor.md → docs/blog/2023-11-09-keymap-editor.mdx
@@ -7,13 +7,16 @@ author_image_url: https://avatars.githubusercontent.com/u/7876996
 tags: [keyboards, firmware, community]
 ---
 
-import ThemedImage from '@theme/ThemedImage';
+import ThemedImage from "@theme/ThemedImage";
 
 <ThemedImage
-alt="Shows a screenshot of the Keymap Editor application featuring a graphical layout of the Corne Keyboard with a keymap loaded from the nickcoutsos/keymap-editor-demo-crkbd GitHub repository."
-sources={{
-    light: require('./assets/2023-11-09-keymap-editor/editor-screenshot-light.png').default,
-    dark: require('./assets/2023-11-09-keymap-editor/editor-screenshot-dark.png').default,
+  alt="Shows a screenshot of the Keymap Editor application featuring a graphical layout of the Corne Keyboard with a keymap loaded from the nickcoutsos/keymap-editor-demo-crkbd GitHub repository."
+  sources={{
+    light:
+      require("./assets/2023-11-09-keymap-editor/editor-screenshot-light.png")
+        .default,
+    dark: require("./assets/2023-11-09-keymap-editor/editor-screenshot-dark.png")
+      .default,
   }}
 />
 

diff --git a/docs/docs/behaviors/backlight.md b/docs/docs/behaviors/backlight.md
@@ -5,7 +5,7 @@ sidebar_label: Backlight
 
 ## Summary
 
-This page contains [backlight](../features/backlight.md) behaviors supported by ZMK.
+This page contains [backlight](../features/backlight.mdx) behaviors supported by ZMK.
 
 ## Backlight Action Defines
 
@@ -36,7 +36,7 @@ Here is a table describing the action for each define:
 - Parameter #1: The backlight action define, e.g. `BL_TOG` or `BL_INC`
 - Parameter #2: Only applies to `BL_SET`and is the brightness value
 
-:::note Backlight settings persistence
+:::note[Backlight settings persistence]
 The backlight settings that are changed via the `&bl` behavior will be saved to flash storage and hence persist across restarts and firmware flashes.
 They will also override the start values set by [`CONFIG_ZMK_BACKLIGHT_*_START` settings](../config/backlight.md#kconfig).
 However the settings will only be saved after [`CONFIG_ZMK_SETTINGS_SAVE_DEBOUNCE`](../config/system.md#general) milliseconds in order to reduce potential wear on the flash memory.

diff --git a/docs/docs/behaviors/bluetooth.md b/docs/docs/behaviors/bluetooth.md
@@ -9,7 +9,7 @@ The bluetooth behavior allows management of various settings and states related
 between the keyboard and the host. By default, ZMK supports five "profiles" for selecting which bonded host
 computer/laptop/keyboard should receive the keyboard input; many of the commands here operate on those profiles.
 
-:::note Connection Management
+:::note[Connection Management]
 When pairing to a host device ZMK saves bond information to the selected
 profile. It will not replace this when you initiate pairing with another device.
 To pair with a new device, select a profile that doesn't have a pairing with `BT_SEL`, `BT_NXT` or
@@ -47,7 +47,7 @@ Here is a table describing the command for each define:
 | `BT_SEL`     | Select the 0-indexed profile by number; must include a number as an argument in the keymap to work correctly, e.g. `BT_SEL 0`.                                                     |
 | `BT_DISC`    | Disconnect from the 0-indexed profile by number, if it's currently connected and inactive; must include a number as an argument in the keymap to work correctly, e.g. `BT_DISC 0`. |
 
-:::note Selected profile persistence
+:::note[Selected profile persistence]
 The profile that is selected by the `BT_SEL`/`BT_PRV`/`BT_NXT` actions will be saved to flash storage and hence persist across restarts and firmware flashes.
 However it will only be saved after [`CONFIG_ZMK_SETTINGS_SAVE_DEBOUNCE`](../config/system.md#general) milliseconds in order to reduce potential wear on the flash memory.
 :::
@@ -98,10 +98,10 @@ ZMK support bluetooth “profiles” which allows connection to multiple devices
 
 The bluetooth MAC address and negotiated keys during pairing are stored in the permanent storage on your chip and can be reused even after reflashing the firmware. If for some reason you want to delete the stored information, you can bind the `BT_CLR` behavior described above to a key and use it to clear the _current_ profile.
 
-:::note Number of Profiles
+:::note[Number of Profiles]
 Please note there are five available Bluetooth profiles by default. If you need to adjust the number of available profiles, set `CONFIG_BT_MAX_CONN` _and_ `CONFIG_BT_MAX_PAIRED` to the desired number of profiles, `n`, or `n+1` for split keyboards, in your `zmk-config` `.conf` file.
 :::
 
 :::note
-If you clear bond of a paired profile, make sure you do the same thing on the peer device as well (typically achieved by _removing_ or _forgetting_ the bluetooth connection). Otherwise the peer will try to connect to your keyboard whenever it discovers it. But while the MAC address of both devices could remain the same, the security key no longer match: the peer device still possess the old key negotiated in the previous pairing procedure, but our keyboard firmware has deleted that key. So the connection will fail. If you [enabled USB logging](../development/usb-logging.md), you might see a lot of failed connection attempts due to the reason of “Security failed”.
+If you clear bond of a paired profile, make sure you do the same thing on the peer device as well (typically achieved by _removing_ or _forgetting_ the bluetooth connection). Otherwise the peer will try to connect to your keyboard whenever it discovers it. But while the MAC address of both devices could remain the same, the security key no longer match: the peer device still possess the old key negotiated in the previous pairing procedure, but our keyboard firmware has deleted that key. So the connection will fail. If you [enabled USB logging](../development/usb-logging.mdx), you might see a lot of failed connection attempts due to the reason of “Security failed”.
 :::
diff --git a/docs/docs/behaviors/hold-tap.md → docs/docs/behaviors/hold-tap.mdx b/docs/docs/behaviors/hold-tap.md → docs/docs/behaviors/hold-tap.mdx
@@ -3,8 +3,8 @@ title: Hold-Tap Behavior
 sidebar_label: Hold-Tap
 ---
 
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
 
 ## Summary
 
@@ -132,7 +132,7 @@ the hold-tap. For homerow mods, this is not always ideal, because it prevents co
 
 #### Using different behavior types with hold-taps
 
-You can create instances of hold-taps invoking most [behavior types](../features/keymaps.md#behaviors) for hold or tap actions, by referencing their node labels in the `bindings` value.
+You can create instances of hold-taps invoking most [behavior types](../features/keymaps.mdx#behaviors) for hold or tap actions, by referencing their node labels in the `bindings` value.
 The two parameters that are passed to the hold-tap in your keymap will be forwarded to the referred behaviors, first one to the hold behavior and second one to the tap.
 
 If you use behaviors that accept no parameters such as [mod-morphs](mod-morph.md) or [macros](macros.md), you can pass a dummy parameter value such as `0` to the hold-tap when you use it in your keymap.
@@ -289,7 +289,7 @@ A popular method of implementing Autoshift in ZMK involves a C-preprocessor macr
 
 <TabItem value="mo_tog">
 
-This hold-tap example implements a [momentary-layer](layers.md/#momentary-layer) when the keybind is held and a [toggle-layer](layers.md/#toggle-layer) when it is tapped. Similar to the Autoshift and Sticky Hold use-cases, a `MO_TOG(layer)` macro is defined such that the `&mo` and `&tog` behaviors can target a single layer.
+This hold-tap example implements a [momentary-layer](layers.md#momentary-layer) when the keybind is held and a [toggle-layer](layers.md#toggle-layer) when it is tapped. Similar to the Autoshift and Sticky Hold use-cases, a `MO_TOG(layer)` macro is defined such that the `&mo` and `&tog` behaviors can target a single layer.
 
 ```dts title="Hold-Tap Example: Momentary layer on Hold, Toggle layer on Tap"
 #include <dt-bindings/zmk/keys.h>

diff --git a/docs/docs/behaviors/layers.md b/docs/docs/behaviors/layers.md
@@ -59,7 +59,7 @@ Example:
 
 ### Configuration
 
-You can configure a different tapping term or tweak other properties noted in the [hold-tap](hold-tap.md#advanced-configuration) documentation page in your keymap:
+You can configure a different tapping term or tweak other properties noted in the [hold-tap](hold-tap.mdx#advanced-configuration) documentation page in your keymap:
 
 ```dts
 &lt {
@@ -74,11 +74,11 @@ You can configure a different tapping term or tweak other properties noted in th
 ```
 
 :::info
-Functionally, the layer-tap is a [hold-tap](hold-tap.md) of the ["tap-preferred" flavor](hold-tap.md/#flavors) and a [`tapping-term-ms`](hold-tap.md/#tapping-term-ms) of 200 that takes in a [`momentary layer`](#momentary-layer) and a [keypress](key-press.md) as its "hold" and "tap" parameters, respectively.
+Functionally, the layer-tap is a [hold-tap](hold-tap.mdx) of the ["tap-preferred" flavor](hold-tap.mdx#flavors) and a [`tapping-term-ms`](hold-tap.mdx#tapping-term-ms) of 200 that takes in a [`momentary layer`](#momentary-layer) and a [keypress](key-press.md) as its "hold" and "tap" parameters, respectively.
 
 For users who want to send a different [keycode](../codes/index.mdx) depending on if the same key is held or tapped, see [Mod-Tap](mod-tap.md).
 
-Similarly, for users looking to create a keybind like the layer-tap that depending on how long the key is held, invokes behaviors like [sticky keys](sticky-key.md) or [key toggles](key-toggle.md), see [Hold-Tap](hold-tap.md).
+Similarly, for users looking to create a keybind like the layer-tap that depending on how long the key is held, invokes behaviors like [sticky keys](sticky-key.md) or [key toggles](key-toggle.md), see [Hold-Tap](hold-tap.mdx).
 
 :::
 

diff --git a/docs/docs/behaviors/mod-tap.md b/docs/docs/behaviors/mod-tap.md
@@ -45,10 +45,10 @@ You can configure a different tapping term in your keymap:
 ```
 
 :::info
-Under the hood, the mod-tap is simply a [hold-tap](hold-tap.md) of the ["hold-preferred" flavor](hold-tap.md/#flavors) with a [`tapping-term-ms`](hold-tap.md/#tapping-term-ms) of 200 that takes in two [keypresses](key-press.md) as its "hold" and "tap" parameters. This means that the mod-tap can be used to invoke **any** [keycode](../codes/index.mdx), and is not limited to only activating [modifier keys](../codes/modifiers.mdx) when it is held.
+Under the hood, the mod-tap is simply a [hold-tap](hold-tap.mdx) of the ["hold-preferred" flavor](hold-tap.mdx#flavors) with a [`tapping-term-ms`](hold-tap.mdx#tapping-term-ms) of 200 that takes in two [keypresses](key-press.md) as its "hold" and "tap" parameters. This means that the mod-tap can be used to invoke **any** [keycode](../codes/index.mdx), and is not limited to only activating [modifier keys](../codes/modifiers.mdx) when it is held.
 
-For users who want to momentarily access a specific [layer](../features/keymaps#layers) while a key is held and send a keycode when the same key is tapped, see [Layer-Tap](layers.md/#layer-tap).
+For users who want to momentarily access a specific [layer](../features/keymaps.mdx#layers) while a key is held and send a keycode when the same key is tapped, see [Layer-Tap](layers.md#layer-tap).
 
-Similarly, for users looking to create a keybind like the mod-tap that invokes behaviors _other_ than [keypresses](key-press.md), like [sticky keys](sticky-key.md) or [key toggles](key-toggle.md), see [Hold-Tap](hold-tap.md).
+Similarly, for users looking to create a keybind like the mod-tap that invokes behaviors _other_ than [keypresses](key-press.md), like [sticky keys](sticky-key.md) or [key toggles](key-toggle.md), see [Hold-Tap](hold-tap.mdx).
 
 :::
diff --git a/docs/docs/behaviors/outputs.md b/docs/docs/behaviors/outputs.md
@@ -12,7 +12,7 @@ keyboard to USB for power but outputting to a different device over bluetooth.
 By default, output is sent to USB when both USB and BLE are connected.
 Once you select a different output, it will be remembered until you change it again.
 
-:::note Powering the keyboard via USB
+:::note[Powering the keyboard via USB]
 ZMK is not always able to detect if the other end of a USB connection accepts keyboard input or not.
 So if you are using USB only to power your keyboard (for example with a charger or a portable power bank), you will want
 to select the BLE output through below behavior to be able to send keystrokes to the selected bluetooth profile.
@@ -44,7 +44,7 @@ The output selection behavior changes the preferred output on press.
 - Reference: `&out`
 - Parameter #1: Command, e.g. `OUT_BLE`
 
-:::note External power state persistence
+:::note[Output selection persistence]
 The endpoint that is selected by the `&out` behavior will be saved to flash storage and hence persist across restarts and firmware flashes.
 However it will only be saved after [`CONFIG_ZMK_SETTINGS_SAVE_DEBOUNCE`](../config/system.md#general) milliseconds in order to reduce potential wear on the flash memory.
 :::

diff --git a/docs/docs/behaviors/power.md b/docs/docs/behaviors/power.md
@@ -43,7 +43,7 @@ Here is a table describing the command for each define:
 - Reference: `&ext_power`
 - Parameter#1: Command, e.g `EP_ON`
 
-:::note External power state persistence
+:::note[External power state persistence]
 The on/off state that is set by the `&ext_power` behavior will be saved to flash storage and hence persist across restarts and firmware flashes.
 However it will only be saved after [`CONFIG_ZMK_SETTINGS_SAVE_DEBOUNCE`](../config/system.md#general) milliseconds in order to reduce potential wear on the flash memory.
 :::

diff --git a/docs/docs/behaviors/reset.md b/docs/docs/behaviors/reset.md
@@ -46,6 +46,6 @@ Example:
 
 Both basic and bootloader reset behaviors are source-specific: This means that it affects the side of the keyboard that contains the behavior binding for split keyboards. For example if you press a key with the `&sys_reset` binding on the left half of the keyboard, the left half will be reset. If you want to be able to reset both sides you can put the bindings on both sides of the keyboard and activate it on the side you would like to reset.
 
-:::note Peripheral invocation
+:::note[Peripheral invocation]
 The peripheral side of the keyboard has to be paired and connected to the central side in order to be able to activate these behaviors, even if it is possible to trigger the behavior using only keys on that side. This is because the key bindings are processed on the central side which would then instruct the peripheral side to reset.
 :::
diff --git a/docs/docs/behaviors/tap-dance.md → docs/docs/behaviors/tap-dance.mdx b/docs/docs/behaviors/tap-dance.md → docs/docs/behaviors/tap-dance.mdx
@@ -3,8 +3,8 @@ title: Tap-Dance Behavior
 sidebar_label: Tap-Dance
 ---
 
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
 
 ## Summary
 
@@ -20,7 +20,7 @@ Defines the maximum elapsed time after the last tap-dance keybind press before a
 
 #### `bindings`
 
-An array of one or more keybinds. This list can include [any ZMK keycode](../codes/) and any listed ZMK behavior, like [hold-taps](hold-tap.md), or [sticky keys](sticky-key.md). The index of a keybind in the `bindings` array corresponds to the number of times the tap-dance binding is pressed. For example, in the [basic tap-dance counter](#basic-example-counter) shown below, `&kp N2` is the second binding in the array of `bindings`: we then see an output of `2` when the `td0` binding is pressed twice.
+An array of one or more keybinds. This list can include [any ZMK keycode](../codes/) and any listed ZMK behavior, like [hold-taps](hold-tap.mdx), or [sticky keys](sticky-key.md). The index of a keybind in the `bindings` array corresponds to the number of times the tap-dance binding is pressed. For example, in the [basic tap-dance counter](#basic-example-counter) shown below, `&kp N2` is the second binding in the array of `bindings`: we then see an output of `2` when the `td0` binding is pressed twice.
 
 The number of bindings in this array also determines the tap-dance's maximum number of keypresses. When a tap-dance reaches its maximum number of keypresses, it will immediately invoke the last behavior in its list of `bindings`, rather than waiting for [`tapping-term-ms`](#tapping-term-ms) to expire before the output is displayed.
 

diff --git a/docs/docs/behaviors/underglow.md b/docs/docs/behaviors/underglow.md
@@ -43,7 +43,7 @@ Here is a table describing the action for each define:
 - Parameter #1: The RGB action define, e.g. `RGB_TOG` or `RGB_BRI`
 - Parameter #2: Only applies to `RGB_COLOR_HSB` and is the HSB representation of the color to set (see below for an example)
 
-:::note HSB Values
+:::note[HSB Values]
 
 When specifying HSB values you'll need to use `RGB_COLOR_HSB(h, s, b)` in your keymap file.
 
@@ -55,7 +55,7 @@ Value Limits:
 
 :::
 
-:::note RGB settings persistence
+:::note[RGB settings persistence]
 The RGB settings that are changed via the `&rgb_ug` behavior will be saved to flash storage and hence persist across restarts and firmware flashes.
 They will also override the start values set by [`CONFIG_ZMK_RGB_*_START` settings](../config/underglow.md#kconfig).
 However the settings will only be saved after [`CONFIG_ZMK_SETTINGS_SAVE_DEBOUNCE`](../config/system.md#general) milliseconds in order to reduce potential wear on the flash memory.

diff --git a/docs/docs/config/backlight.md b/docs/docs/config/backlight.md
@@ -3,7 +3,7 @@ title: Backlight Configuration
 sidebar_label: Backlight
 ---
 
-See the [backlight feature page](../features/backlight.md) for more details, including instructions for adding backlight support to a board.
+See the [backlight feature page](../features/backlight.mdx) for more details, including instructions for adding backlight support to a board.
 
 See [Configuration Overview](index.md) for instructions on how to change these settings.
 
@@ -37,4 +37,4 @@ See the Zephyr devicetree bindings for LED drivers:
 - [gpio-leds](https://docs.zephyrproject.org/3.0.0/reference/devicetree/bindings/gpio/gpio-leds.html)
 - [pwm-leds](https://docs.zephyrproject.org/latest/build/dts/api/bindings/led/pwm-leds.html)
 
-See the [backlight feature page](../features/backlight.md) for examples of the properties that must be set to enable backlighting.
+See the [backlight feature page](../features/backlight.mdx) for examples of the properties that must be set to enable backlighting.
diff --git a/docs/docs/config/battery.md b/docs/docs/config/battery.md
@@ -16,13 +16,13 @@ Definition file: [zmk/app/Kconfig](https://github.com/zmkfirmware/zmk/blob/main/
 | `CONFIG_ZMK_BATTERY_REPORTING`       | bool | Enables/disables all battery level detection/reporting | n       |
 | `CONFIG_ZMK_BATTERY_REPORT_INTERVAL` | int  | Battery level report interval in seconds               | 60      |
 
-:::note Default setting
+:::note[Default setting]
 
 While `CONFIG_ZMK_BATTERY_REPORTING` is disabled by default it is implied by `CONFIG_ZMK_BLE`, thus any board with BLE enabled will have this automatically enabled unless explicitly overriden.
 
 :::
 
-:::note BLE reporting on MacOS
+:::note[BLE reporting on MacOS]
 
 On macOS the BLE battery reporting packets can cause the computer to wakeup from sleep. To prevent this, the battery _reporting_ service can be disabled by setting `CONFIG_BT_BAS=n`. This setting is independent of battery _monitoring_, for instance the battery level can still be indicated on a display.
 

diff --git a/docs/docs/config/behaviors.md b/docs/docs/config/behaviors.md
@@ -49,7 +49,7 @@ You can use the following nodes to tweak the default behaviors:
 
 Creates a custom behavior that triggers one behavior when a key is held or a different one when the key is tapped.
 
-See the [hold-tap behavior](../behaviors/hold-tap.md) documentation for more details and examples.
+See the [hold-tap behavior](../behaviors/hold-tap.mdx) documentation for more details and examples.
 
 ### Devicetree
 
@@ -77,7 +77,7 @@ The `flavor` property may be one of:
 - `"tap-preferred"`
 - `"tap-unless-interrupted"`
 
-See the [hold-tap behavior documentation](../behaviors/hold-tap.md) for an explanation of each flavor.
+See the [hold-tap behavior documentation](../behaviors/hold-tap.mdx) for an explanation of each flavor.
 
 `hold-trigger-key-positions` is an array of zero-based key position indices.
 
@@ -243,7 +243,7 @@ You can use the following nodes to tweak the default behaviors:
 
 Creates a custom behavior that triggers a different behavior corresponding to the number of times the key is tapped.
 
-See the [tap dance behavior](../behaviors/tap-dance.md) documentation for more details and examples.
+See the [tap dance behavior](../behaviors/tap-dance.mdx) documentation for more details and examples.
 
 ### Devicetree