refactor(docs): Use new admonition title syntax and disable mdx v1 compat
This commit is contained in:
parent
ee855de349
commit
dcfe07d9f6
13 changed files with 26 additions and 19 deletions
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
:::
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue