diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/blog/2020-08-12-zmk-sotf-1.md | 4 | ||||
| -rw-r--r-- | docs/docs/assets/bond-clearing/corne.jpg | bin | 0 -> 147244 bytes | |||
| -rw-r--r-- | docs/docs/assets/bond-clearing/kyria.jpg | bin | 0 -> 140236 bytes | |||
| -rw-r--r-- | docs/docs/behavior/key-press.md | 5 | ||||
| -rw-r--r-- | docs/docs/behavior/layers.md | 55 | ||||
| -rw-r--r-- | docs/docs/behavior/lighting.md | 11 | ||||
| -rw-r--r-- | docs/docs/behavior/misc.md | 42 | ||||
| -rw-r--r-- | docs/docs/behavior/mod-tap.md | 30 | ||||
| -rw-r--r-- | docs/docs/behavior/reset.md | 43 | ||||
| -rw-r--r-- | docs/docs/bond-reset.md | 27 | ||||
| -rw-r--r-- | docs/docs/dev-guide-new-shield.md | 53 | ||||
| -rw-r--r-- | docs/docs/dev-setup.md | 27 | ||||
| -rw-r--r-- | docs/docs/feature/underglow.md | 8 | ||||
| -rw-r--r-- | docs/docs/hardware.md | 2 | ||||
| -rw-r--r-- | docs/sidebars.js | 5 | ||||
| -rw-r--r-- | docs/static/setup.sh | 3 |
16 files changed, 253 insertions, 62 deletions
diff --git a/docs/blog/2020-08-12-zmk-sotf-1.md b/docs/blog/2020-08-12-zmk-sotf-1.md index 2b69535..8a3ca7c 100644 --- a/docs/blog/2020-08-12-zmk-sotf-1.md +++ b/docs/blog/2020-08-12-zmk-sotf-1.md @@ -28,10 +28,10 @@ There's been lots of various activity in ZMK land! Despite the flurry of activity, there are still some serious bugs and show stoppers that potential ZMK users should be aware of: - [Bluetooth Related](https://github.com/zmkfirmware/zmk/issues/58) - There are several key bugs and fixes needed, including one complete show stopper: - - Fully working split wireless is not working. In particular, both split halves can properly pair, but once they do so, pairing with the _central_ host will not work. Workaround: You can currently have both halves pair, and use USB on the central side (Left side right now for Kyria, Corne, Lily58) and receive HID events over USB. + - <del>Fully working split wireless is not working. In particular, both split halves can properly pair, but once they do so, pairing with the _central_ host will not work. Workaround: You can currently have both halves pair, and use USB on the central side (Left side right now for Kyria, Corne, Lily58) and receive HID events over USB.</del> - Fixed in <a href="https://github.com/zmkfirmware/zmk/commit/8b61beb2bbc62f754db670ad77266f84edde041d">8b61beb</a>. - BT bond information is not currently stored to the devices, so after powering off or restarting your device, users need to re-pair - USB - There is one important USB related bug which is a showstopper: - - The Zephyr USB stack does not have a built in queue for endpoint data being written. As a result, HID events sent by ZMK are sometimes [dropped, or lost](https://github.com/zmkfirmware/zmk/issues/84). + - <del>The Zephyr USB stack does not have a built in queue for endpoint data being written. As a result, HID events sent by ZMK are sometimes <a href="https://github.com/zmkfirmware/zmk/issues/84">dropped, or lost</a>.</del> - Fixed by <a href="https://github.com/careyk007">careyk007</a> in <a href="https://github.com/zmkfirmware/zmk/pull/93">#93</a>. ## Next Steps diff --git a/docs/docs/assets/bond-clearing/corne.jpg b/docs/docs/assets/bond-clearing/corne.jpg Binary files differnew file mode 100644 index 0000000..1e070a2 --- /dev/null +++ b/docs/docs/assets/bond-clearing/corne.jpg diff --git a/docs/docs/assets/bond-clearing/kyria.jpg b/docs/docs/assets/bond-clearing/kyria.jpg Binary files differnew file mode 100644 index 0000000..9fa22a0 --- /dev/null +++ b/docs/docs/assets/bond-clearing/kyria.jpg diff --git a/docs/docs/behavior/key-press.md b/docs/docs/behavior/key-press.md index 08296bb..2edce1d 100644 --- a/docs/docs/behavior/key-press.md +++ b/docs/docs/behavior/key-press.md @@ -1,10 +1,11 @@ --- -title: Key Presses +title: Key Press Behaviors +sidebar_label: Key Press --- ## Summary -The most basic of behaiors, is the ability to send certain keycode presses and releases in response to activating +The most basic of behaviors, is the ability to send certain keycode presses and releases in response to activating a certain key. For reference on keycode values, see the [USB HID Usage Tables](https://www.usb.org/document-library/hid-usage-tables-12). diff --git a/docs/docs/behavior/layers.md b/docs/docs/behavior/layers.md index 2388caf..da7f07f 100644 --- a/docs/docs/behavior/layers.md +++ b/docs/docs/behavior/layers.md @@ -1,5 +1,6 @@ --- -title: Layers +title: Layer Behaviors +sidebar_label: Layers --- ## Summary @@ -39,3 +40,55 @@ Example: ``` &mo LOWER ``` + +## Toggle Layer + +The "toggle layer" behavior allows you to enable a layer until the layer is manually disabled. + +### Behavior Binding + +- Reference: `&tog` +- Parameter: The layer number to enable/disable, e.g. `1` + +Example: + +``` +&tog LOWER +``` + +"Toggle layer" for a : + +``` +#define DEFAULT 0 +#define NAVI 1 + +#define NONE 0 + +/ { + keymap { + compatible = "zmk,keymap"; + + default_layer { + bindings = < + &tog NAVI &kp KDIV &kp KMLT &kp KMIN + &kp NUM_7 &kp NUM_8 &kp NUM_9 &kp KPLS + &kp NUM_4 &kp NUM_5 &kp NUM_6 &kp KPLS + &kp NUM_1 &kp NUM_2 &kp NUM_3 &kp RET + &kp NUM_0 &kp NUM_0 &kp DOT &kp RET + >; + }; + + nav_layer { + bindings = < + &tog NAVI &kp KDIV &kp KMLT &kp KMIN + &kp HOME &kp UARW &kp PGUP &kp KPLS + &kp LARW &none &kp RARW &kp KPLS + &kp END &kp DARW &kp PGDN &kp RET + &kp INS &kp INS &kp DEL &kp RET + >; + }; + }; +}; +``` + +It is possible to use "toggle layer" to have keys that raise and lower the layers as well. diff --git a/docs/docs/behavior/lighting.md b/docs/docs/behavior/lighting.md index 432960e..2d4f532 100644 --- a/docs/docs/behavior/lighting.md +++ b/docs/docs/behavior/lighting.md @@ -1,15 +1,16 @@ --- -title: Lighting +title: Lighting Behavior +sidebar_label: Lighting --- ## Summary -Lighting is often used for either aesthetics or for the practical purposes of lighting up keys in the dark. +Lighting is often used for either aesthetics or for the practical purposes of lighting up keys in the dark. Currently ZMK supports RGB underglow, which can be changed and configured using its behavior. ## RGB Action Defines -RGB actions defines are provided through the [`dt-bindings/zmk/rgb.h`](https://github.com/zmkfirmware/zmk/blob/main/app/include/dt-bindings/zmk/rgb.h) header, +RGB actions defines are provided through the [`dt-bindings/zmk/rgb.h`](https://github.com/zmkfirmware/zmk/blob/main/app/include/dt-bindings/zmk/rgb.h) header, which is added at the top of the keymap file: ``` @@ -21,7 +22,7 @@ This will allow you to reference the actions defined in this header such as `RGB Here is a table describing the action for each define: | Define | Action | -|-----------|-----------------------------------------------------------| +| --------- | --------------------------------------------------------- | | `RGB_TOG` | Toggles the RGB feature on and off | | `RGB_HUI` | Increases the hue of the RGB feature | | `RGB_HUD` | Decreases the hue of the RGB feature | @@ -47,4 +48,4 @@ Example: ``` &rgb_ug RGB_TOG -```
\ No newline at end of file +``` diff --git a/docs/docs/behavior/misc.md b/docs/docs/behavior/misc.md new file mode 100644 index 0000000..446ba33 --- /dev/null +++ b/docs/docs/behavior/misc.md @@ -0,0 +1,42 @@ +--- +title: Miscellaneous Behaviors +sidebar_label: Miscellaneous +--- + +## Summary + +There are a few miscellaneous behaviors that are helpful when working with layers in keymaps, +in particular, with handling what happens in higher layers, and if events are passed to +the next layer or not + +## Transparent + +The transparent behavior simply ignores key position presses/releases, so they will be +passed down to the next active layer in the stack. + +### Behavior Binding + +- Reference: `&trans` +- Parameters: None + +Example: + +``` +&trans +``` + +## None + +The none behavior simply swallows and stops key position presses/releases, so they will **not** +be passed down to the next active layer in the stack. + +### Behavior Binding + +- Reference: `&none` +- Parameters: None + +Example: + +``` +&none +``` diff --git a/docs/docs/behavior/mod-tap.md b/docs/docs/behavior/mod-tap.md new file mode 100644 index 0000000..08e9b65 --- /dev/null +++ b/docs/docs/behavior/mod-tap.md @@ -0,0 +1,30 @@ +--- +title: Mod-Tap Behavior +sidebar_label: Mod-Tap +--- + +## Summary + +The Mod-Tap behavior allows varying the effect of pressing and releasing a key position depending +on whether it is used with other simultaneous key presses at the same time. + +If pressed and released independently, the Mod-Tap behavior will send the press and release events +for the configure keycode. If pressed and held while another key is pressed and released, then +the configured modifiers will be applied to that _other_ key press, and no press will be generated +on the release of the Mod-Tap key. + +## Mod-Tap + +The Mod-Tap behavior either acts as a held modifier, or as a tapped keycode. + +### Behavior Binding + +- Reference: `&mt` +- Parameter #1: The modifiers to be used when activating as a modifier, e.g. `MOD_LSFT` +- Parameter #2: The keycode to sent when used as a tap, e.g. `A`, `B`. + +Example: + +``` +&mt MOD_LSFT A +``` diff --git a/docs/docs/behavior/reset.md b/docs/docs/behavior/reset.md new file mode 100644 index 0000000..8cf122b --- /dev/null +++ b/docs/docs/behavior/reset.md @@ -0,0 +1,43 @@ +--- +title: Reset Behaviors +sidebar_label: Reset +--- + +## Summary + +There are two available behaviors that can be used to trigger a reset of the keyboard. +The first is a soft reset, that will simply reset and re-run the currently flashed +firmware; the second when triggered will reset into the bootloader, allowing you to +flash a new firmware to the keyboard. + +## Reset + +The basic reset behavior will reset the keyboard and re-run the firmware flashed +to the device + +### Behavior Binding + +- Reference: `&reset` +- Parameters: None + +Example: + +``` +&reset +``` + +## Bootloader Reset + +The bootloader reset behavior will reset the keyboard and put it into bootloader mode, allowing +you to flash a new firmware. + +### Behavior Binding + +- Reference: `&bootloader` +- Parameters: None + +Example: + +``` +&bootloader +``` diff --git a/docs/docs/bond-reset.md b/docs/docs/bond-reset.md new file mode 100644 index 0000000..1d3732b --- /dev/null +++ b/docs/docs/bond-reset.md @@ -0,0 +1,27 @@ +--- +id: bond-reset +title: Reset BLE Connections +sidebar_label: BLE Reset +--- + +Known as a 'bond reset', a special key combination, that is not related to the user defined key map, which +clears all wireless connection configurations. The keys must be held for 3 to 5 seconds after the device is +reset. + +:::warning +Currently, ZMK only supports a single BLE host. If you remove the keyboard from the host's bluetooth devices +list, you will need to clear the bonds. +::: + +### Split Keyboards + +Split keyboards will need to be cleared on both halves. For best results try to reset them at the same time. + + +## Kyria + + + +## Corne + +
\ No newline at end of file diff --git a/docs/docs/dev-guide-new-shield.md b/docs/docs/dev-guide-new-shield.md index 1119806..8556623 100644 --- a/docs/docs/dev-guide-new-shield.md +++ b/docs/docs/dev-guide-new-shield.md @@ -81,9 +81,9 @@ this might look something like: ; row-gpios - = <&pro_micro_a 1 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)> - , <&pro_micro_a 2 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)> - , <&pro_micro_a 3 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)> + = <&pro_micro_a 1 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)> + , <&pro_micro_a 2 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)> + , <&pro_micro_a 3 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)> ; }; }; @@ -147,51 +147,38 @@ Some important things to note: ## Default Keymap -Each keyboard should provide an OOTB default keymap to be used when building the firmware, which can be overridden and customized by user configs. For "shield keyboards", this should be placed in the `app/boards/shields/<shield_name>/keymap/keymap.overlay` file. The keymap is configured as an additional devicetree overlay that includes the following: +Each keyboard should provide an OOTB default keymap to be used when building the firmware, which can be overridden and customized by user configs. For "shield keyboards", this should be placed in the `app/boards/shields/<shield_name>/<shield_name>.keymap` file. The keymap is configured as an additional devicetree overlay that includes the following: -- A node with `compatible="zmk,layers"` where each child node is a layer with a `bindings` array that binds each key position to a given behavior (e.g. key press, momentarily layer, etc). -- A node with `compatible="zmk,keymap"` that references the layers with a `layers` phandle-array property. -- A chosen node named `zmk,keymap` that references the defined keymap. +- A node with `compatible="zmk,keymap"` where each child node is a layer with a `bindings` array that binds each key position to a given behavior (e.g. key press, momentarily layer, etc). -Here is an example simple keymap for the nice60, with only one layer: +Here is an example simple keymap for the Kyria, with only one layer: ``` #include <behaviors.dtsi> #include <dt-bindings/zmk/keys.h> / { - chosen { - zmk,keymap = &keymap0; - }; - - keymap0: keymap { + keymap { compatible = "zmk,keymap"; - label ="Default nice!60 Keymap"; - layers = <&default>; - }; - layers { - compatible = "zmk,layers"; - - default: layer_0 { - label = "DEFAULT"; -// ------------------------------------------------------------------------------------------ -// | ESC | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | - | = | BKSP | -// | TAB | Q | W | E | R | T | Y | U | I | O | P | [ | ] | "|" | -// | CAPS | A | S | D | F | G | H | J | K | L | ; | ' | ENTER | -// | SHIFT | Z | X | C | V | B | N | M | , | . | / | SHIFT | -// | CTL | WIN | ALT | SPACE | ALT | WIN | MENU | CTL | -// ------------------------------------------------------------------------------------------ + default_layer { +// --------------------------------------------------------------------------------------------------------------------------------- +// | ESC | Q | W | E | R | T | | Y | U | I | O | P | \ | +// | TAB | A | S | D | F | G | | H | J | K | L | ; | ' | +// | SHIFT | Z | X | C | V | B | L SHIFT | L SHIFT | | L SHIFT | L SHIFT | N | M | , | . | / | CTRL | +// | GUI | DEL | RET | SPACE | ESC | | RET | SPACE | TAB | BSPC | R-ALT | bindings = < - &kp ESC &kp NUM_1 &kp NUM_2 &kp NUM_3 &kp NUM_4 &kp NUM_5 &kp NUM_6 &kp NUM_7 &kp NUM_8 &kp NUM_9 &kp NUM_0 &kp MINUS &kp EQL &kp BKSP - &kp TAB &kp Q &kp W &kp E &kp R &kp T &kp Y &kp U &kp I &kp O &kp P &kp LBKT &kp RBKT &kp BSLH - &kp CLCK &kp A &kp S &kp D &kp F &kp G &kp H &kp J &kp K &kp L &kp SCLN &kp QUOT &kp RET - &kp LSFT &kp Z &kp X &kp C &kp V &kp B &kp N &kp M &kp CMMA &kp DOT &kp FSLH &kp RSFT - &kp LCTL &kp LGUI &kp LALT &kp SPC &kp RALT &kp RGUI &kp GUI &kp RCTL + &kp ESC &kp Q &kp W &kp E &kp R &kp T &kp Y &kp U &kp I &kp O &kp P &kp BSLH + &kp TAB &kp A &kp S &kp D &kp F &kp G &kp H &kp J &kp K &kp L &kp SCLN &kp QUOT + &kp LSFT &kp Z &kp X &kp C &kp V &kp B &kp LSFT &kp LSFT &kp LSFT &kp LSFT &kp N &kp M &kp CMMA &kp DOT &kp FSLH &kp RCTL + &kp LGUI &kp DEL &kp RET &kp SPC &kp ESC &kp RET &kp SPC &kp TAB &kp BKSP &kp RALT >; + + sensor-bindings = <&inc_dec_cp M_VOLU M_VOLD &inc_dec_kp PGUP PGDN>; }; }; }; + ``` :::note diff --git a/docs/docs/dev-setup.md b/docs/docs/dev-setup.md index 5cceb73..6e893b3 100644 --- a/docs/docs/dev-setup.md +++ b/docs/docs/dev-setup.md @@ -180,7 +180,7 @@ brew install cmake ninja python3 ccache dtc git wget ### West Build Command -`west` is the [Zephyr™ meta-tool](https://docs.zephyrproject.org/latest/guides/west/index.html) used to configure and build Zephyr™ applications. +`west` is the [Zephyr™ meta-tool](https://docs.zephyrproject.org/2.3.0/guides/west/index.html) used to configure and build Zephyr™ applications. West can be installed by using the `pip` python package manager. @@ -223,7 +223,7 @@ The installation will prompt with several questions about installation location, <TabItem value="raspberryos"> Because Raspberry OS (Raspbian) runs on the same architecture (but different ABI) as the keyboard MCUs, -the operating system's installed [cross compilers](https://docs.zephyrproject.org/latest/getting_started/toolchain_other_x_compilers.html) can be used to target the different ABI. +the operating system's installed [cross compilers](https://docs.zephyrproject.org/2.3.0/getting_started/toolchain_other_x_compilers.html) can be used to target the different ABI. First, the cross compiler should be installed: @@ -259,23 +259,20 @@ The installation will prompt with several questions about installation location, #### GNU ARM Embedded -Since the Zephyr™ SDK is not available for Windows, we recommending following the steps to install the [GNU ARM Embedded](https://docs.zephyrproject.org/latest/getting_started/toolchain_3rd_party_x_compilers.html#gnu-arm-embedded). +Since the Zephyr™ SDK is not available for Windows, we recommending following the steps to install the [GNU ARM Embedded](https://docs.zephyrproject.org/2.3.0/getting_started/toolchain_3rd_party_x_compilers.html#gnu-arm-embedded). </TabItem> <TabItem value="mac"> -#### Zephyr™ ARM SDK +#### GNU ARM Embedded -To build firmwares for the ARM architecture (all supported MCUs/keyboards at this point), you'll need to install the Zephyr™ ARM SDK to your system: +Since the Zephyr™ SDK is not available for macOS, we recommending following the steps to install the [GNU ARM Embedded](https://docs.zephyrproject.org/2.3.0/getting_started/toolchain_3rd_party_x_compilers.html#gnu-arm-embedded). -``` -export ZSDK_VERSION=0.11.2 -wget -q "https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v${ZSDK_VERSION}/zephyr-toolchain-arm-${ZSDK_VERSION}-setup.run" && \ - sh "zephyr-toolchain-arm-${ZSDK_VERSION}-setup.run" --quiet -- -d ~/.local/zephyr-sdk-${ZSDK_VERSION} && \ - rm "zephyr-toolchain-arm-\${ZSDK_VERSION}-setup.run" -``` +:::warning Security Controls Workaround -The installation will prompt with several questions about installation location, and creating a default `~/.zephyrrc` for you with various variables. The defaults should normally work as expected. +Please be sure to read the [additional setup instructions](https://docs.zephyrproject.org/2.3.0/getting_started/installation_mac.html#mac-gatekeeper) needed to address security controls found in macOS 10.15 Catalina and newer + +::: </TabItem> </OsTabs> @@ -342,7 +339,7 @@ pip3 install --user -r zephyr/scripts/requirements-base.txt ### Environment Variables By default, the Zephyr™ SDK will create a file named `~/.zephyrrc` with the correct environment variables to build ZMK. -We suggest two main [options](https://docs.zephyrproject.org/latest/guides/env_vars.html?highlight=zephyrrc) for how to load those settings. +We suggest two main [options](https://docs.zephyrproject.org/2.3.0/guides/env_vars.html?highlight=zephyrrc) for how to load those settings. #### Per Shell @@ -442,7 +439,7 @@ an onboard MCU, or one that uses a MCU board addon. ### Keyboard (Shield) + MCU Board -ZMK treats keyboards that take a MCU addon board as [shields](https://docs.zephyrproject.org/latest/guides/porting/shields.html), and treats the smaller MCU board as the true [board](https://docs.zephyrproject.org/latest/guides/porting/board_porting.html) +ZMK treats keyboards that take a MCU addon board as [shields](https://docs.zephyrproject.org/2.3.0/guides/porting/shields.html), and treats the smaller MCU board as the true [board](https://docs.zephyrproject.org/2.3.0/guides/porting/board_porting.html) Given the following: @@ -458,7 +455,7 @@ west build -b proton_c -- -DSHIELD=kyria_left -DKEYMAP=default ### Keyboard With Onboard MCU -Keyboards with onboard MCU chips are simply treated as the [board](https://docs.zephyrproject.org/latest/guides/porting/board_porting.html) as far as Zephyr™ is concerned. +Keyboards with onboard MCU chips are simply treated as the [board](https://docs.zephyrproject.org/2.3.0/guides/porting/board_porting.html) as far as Zephyr™ is concerned. Given the following: diff --git a/docs/docs/feature/underglow.md b/docs/docs/feature/underglow.md index 780845a..c6517ce 100644 --- a/docs/docs/feature/underglow.md +++ b/docs/docs/feature/underglow.md @@ -21,10 +21,12 @@ Here you can see the RGB underglow feature in action using WS2812 LEDs. ## Enabling RGB Underglow -To enable RGB underglow on your board or shield, simply enable the `ZMK_RGB_UNDERGLOW` configuration value in the `.conf` file of your user config directory as such: +To enable RGB underglow on your board or shield, simply enable the `ZMK_RGB_UNDERGLOW` and `X_STRIP` configuration values in the `.conf` file of your user config directory as such: ``` CONFIG_ZMK_RGB_UNDERGLOW=y +# Use the STRIP config specific to the LEDs you're using +CONFIG_WS2812_STRIP=y ``` If your board or shield does not have RGB underglow configured, refer to [Adding RGB Underglow to a Board](#adding-rgb-underglow-to-a-board). @@ -114,8 +116,10 @@ Once you have your `led_strip` properly defined you need to add it to the root d }; ``` -Finally you need to enable the `ZMK_RGB_UNDERGLOW` configuration value in the `.conf` file of your board (or set a default in the `Kconfig.defconfig`): +Finally you need to enable the `ZMK_RGB_UNDERGLOW` and `X_STRIP` configuration values in the `.conf` file of your board (or set a default in the `Kconfig.defconfig`): ``` CONFIG_ZMK_RGB_UNDERGLOW=y +# Use the STRIP config specific to the LEDs you're using +CONFIG_WS2812_STRIP=y ``` diff --git a/docs/docs/hardware.md b/docs/docs/hardware.md index 951cee0..9e6a956 100644 --- a/docs/docs/hardware.md +++ b/docs/docs/hardware.md @@ -17,6 +17,8 @@ That being said, there are currently only a few specific [boards](/docs/faq#what ## Boards - [nice!nano](https://docs.nicekeyboards.com/#/nice!nano/) (`nice_nano`) +- [nrfMicro](https://github.com/joric/nrfmicro) (`nrfmicro_13`, `nrfmicro_11`, `nrfmicro_11_flipped`) +- [BlueMicro840](https://store.jpconstantineau.com/#/group/bluemicro) (`bluemicro840_v1`) - [QMK Proton-C](https://qmk.fm/proton-c/) (`proton_c`) ## Keyboard Shields diff --git a/docs/sidebars.js b/docs/sidebars.js index 1bd0358..51313fc 100644 --- a/docs/sidebars.js +++ b/docs/sidebars.js @@ -1,6 +1,6 @@ module.exports = { someSidebar: { - "Getting Started": ["intro", "hardware", "faq", "user-setup"], + "Getting Started": ["intro", "hardware", "faq", "user-setup", "bond-reset"], Features: [ "feature/keymaps", "feature/displays", @@ -10,6 +10,9 @@ module.exports = { Behaviors: [ "behavior/key-press", "behavior/layers", + "behavior/misc", + "behavior/mod-tap", + "behavior/reset", "behavior/lighting", ], Development: [ diff --git a/docs/static/setup.sh b/docs/static/setup.sh index e75b529..4dc740a 100644 --- a/docs/static/setup.sh +++ b/docs/static/setup.sh @@ -11,7 +11,7 @@ title="ZMK Config Setup:" # TODO: Check for user.name and user.email git configs being set prompt="Pick an MCU board:" -options=("nice!nano" "QMK Proton-C") +options=("nice!nano" "QMK Proton-C" "BlueMicro840 (v1)") echo "$title" echo "" @@ -23,6 +23,7 @@ select opt in "${options[@]}" "Quit"; do 1 ) board="nice_nano"; break;; 2 ) board="proton_c"; break;; + 3 ) board="bluemicro840_v1"; break;; $(( ${#options[@]}+1 )) ) echo "Goodbye!"; exit;; *) echo "Invalid option. Try another one.";continue;; |
