refactor(docs): Use new admonition title syntax and disable mdx v1 compat

docs/docs/behaviors/backlight.md

@@ -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.

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,7 +98,7 @@ 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.
 :::
 

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 Output selection 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.
 :::

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.
 :::

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.
 :::

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.

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.
 

docs/docs/config/system.md

@@ -34,7 +34,7 @@ Exactly zero or one of the following options may be set to `y`. The first is use
 | `CONFIG_ZMK_HID_REPORT_TYPE_HKRO` | Enable `CONFIG_ZMK_HID_KEYBOARD_REPORT_SIZE` key roll over.                                           |
 | `CONFIG_ZMK_HID_REPORT_TYPE_NKRO` | Enable full N-key roll over. This may prevent the keyboard from working with some BIOS/UEFI versions. |
 
-:::note NKRO usages
+:::note[NKRO usages]
 
 By default the NKRO max usage is set so as to maximize compatibility, however certain less frequently used keys (F13-F24 and INTL1-8) will not work with it. One solution is to set `CONFIG_ZMK_HID_KEYBOARD_NKRO_EXTENDED_REPORT=y`, however this is known to break compatibility with Android and thus not enabled by default.
 
@@ -72,7 +72,7 @@ Exactly zero or one of the following options may be set to `y`. The first is use
 | `CONFIG_ZMK_USB_BOOT`             | bool   | Enable USB Boot protocol support        | n               |
 | `CONFIG_ZMK_USB_INIT_PRIORITY`    | int    | USB init priority                       | 50              |
 
-:::note USB Boot protocol support
+:::note[USB Boot protocol support]
 
 By default USB Boot protocol support is disabled, however certain situations such as the input of Bitlocker pins or FileVault passwords may require it to be enabled.
 

docs/docs/development/usb-logging.mdx

@@ -11,7 +11,7 @@ If you are developing ZMK on a device that does not have a built in UART for deb
 Zephyr can be configured to create a USB CDC ACM device and the direct all `printk`, console output, and log
 messages to that device instead.
 
-:::danger Battery Life Impact
+:::danger[Battery Life Impact]
 
 Enabling logging increases the power usage of your keyboard, and can have a non-trivial impact to your time on battery.
 It is recommended to only enable logging when needed, and not leaving it on by default.

docs/docs/features/bluetooth.md

@@ -22,7 +22,7 @@ The only known vulnerability in the protocol is a risk of an active man-in-the-m
 By default, ZMK supports five "profiles" for selecting which bonded host
 device should receive the keyboard input.
 
-:::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 automatically when you initiate pairing with another device. To pair with a new device select an unused profile with or clearing the current profile, using the [`&bt` behavior](../behaviors/bluetooth.md) on your keyboard.
 

docs/docs/features/combos.md

@@ -44,7 +44,7 @@ Key positions are numbered like the keys in your keymap, starting at 0. So, if t
 - Fully overlapping combos like `0 1` and `0 1 2` are supported.
 - You are not limited to `&kp` bindings. You can use all ZMK behaviors there, like `&mo`, `&bt`, `&mt`, `&lt` etc.
 
-:::note Source-specific behaviors on split keyboards
+:::note[Source-specific behaviors on split keyboards]
 Invoking a source-specific behavior such as one of the [reset behaviors](behaviors/reset.md) using a combo will always trigger it on the central side of the keyboard, regardless of the side that the keys corresponding to `key-positions` are on.
 :::
 

docs/docs/user-setup.mdx

@@ -103,7 +103,7 @@ Keyboard Selection:
 Pick an keyboard:
 ```
 
-:::note For a keyboard not in the included list:
+:::note[For a keyboard not in the included list:]
 If you are building firmware for a new keyboard that is not included in the built-in
 list of keyboards, you can choose any keyboard from the list that is similar to yours (e.g. in terms of unibody/split and [onboard controller](hardware.mdx#onboard)/[composite](hardware.mdx#composite)) to generate the repository,
 and edit / add necessary files. You can follow the [new shield guide](development/new-shield.mdx) if you are adding support for a composite keyboard.
@@ -202,7 +202,7 @@ storage device. Once the flash is complete, the controller should unmount the US
 flashed firmware. It is recommended that you test your keyboard works over USB first to rule out hardware issues, before trying to
 connect to it wirelessly.
 
-:::warning Split keyboards
+:::warning[Split keyboards]
 
 For split keyboards, only the central half (typically the left side) will send keyboard outputs over USB or advertise to other devices
 over bluetooth. Peripheral half will only send keystrokes to the central once they are paired and connected. For this reason it is

docs/docusaurus.config.js

@@ -157,4 +157,11 @@ module.exports = {
       },
     ],
   ],
+  markdown: {
+    mdx1Compat: {
+      comments: false,
+      admonitions: false,
+      headingIds: true,
+    },
+  },
 };