From 308d6bce6eb338f387a454c7366d0bcb07463d7b Mon Sep 17 00:00:00 2001 From: Nicolas Munnich <98408764+Nick-Munnich@users.noreply.github.com> Date: Sun, 2 Jun 2024 06:51:08 +0200 Subject: [PATCH 1/3] feat(docs): Improve the toolchain setup page (#2272) Split the toolchain setup into separate docker and native pages and improve instructions to better refer to Zephyr docs in certain steps. Also refactor to improve consistency and add virtualenv instructions. --------- Co-authored-by: KemoNine Co-authored-by: Cem Aksoylar --- docs/blog/2020-08-12-zmk-sotf-1.md | 2 +- docs/blog/2021-07-17-zephyr-2-5.md | 2 +- docs/blog/2022-04-02-zephyr-3-0.md | 2 +- docs/blog/2022-04-10-zmk-sotf-5.md | 2 +- docs/blog/2023-04-06-zephyr-3-2.md | 2 +- docs/blog/2024-02-09-zephyr-3-5.md | 2 +- docs/docs/behaviors/index.mdx | 8 +- docs/docs/customization.md | 2 +- docs/docs/development/new-shield.mdx | 4 +- docs/docs/development/setup.mdx | 322 ---------------------- docs/docs/development/setup/docker.md | 53 ++++ docs/docs/development/setup/index.md | 20 ++ docs/docs/development/setup/native.mdx | 353 +++++++++++++++++++++++++ docs/docs/troubleshooting.md | 2 +- docs/docusaurus.config.js | 3 +- docs/sidebars.js | 11 +- docs/src/css/custom.css | 4 + 17 files changed, 456 insertions(+), 338 deletions(-) delete mode 100644 docs/docs/development/setup.mdx create mode 100644 docs/docs/development/setup/docker.md create mode 100644 docs/docs/development/setup/index.md create mode 100644 docs/docs/development/setup/native.mdx diff --git a/docs/blog/2020-08-12-zmk-sotf-1.md b/docs/blog/2020-08-12-zmk-sotf-1.md index afa03405a70..89cfffabe65 100644 --- a/docs/blog/2020-08-12-zmk-sotf-1.md +++ b/docs/blog/2020-08-12-zmk-sotf-1.md @@ -19,7 +19,7 @@ There's been lots of various activity in ZMK land! - Tons of [documentation](/docs) work. - Refactoring ([#73](https://github.com/zmkfirmware/zmk/pull/73), [#74](https://github.com/zmkfirmware/zmk/pull/74)) of [keymaps](/docs/features/keymaps) to make them simpler for users. - Mod-Tap Behavior (docs coming!) is much improved ([#69](https://github.com/zmkfirmware/zmk/pull/69)) and usable now. -- An initial [`setup.sh`](http://localhost:3000/docs/user-setup#user-config-setup-script) script was created, allowing users to quickly bootstrap a "user config" setup and push it to GitHub, where GitHub Actions will build the firmware for you. +- An initial [`setup.sh`](/docs/user-setup#user-config-setup-script) script was created, allowing users to quickly bootstrap a "user config" setup and push it to GitHub, where GitHub Actions will build the firmware for you. - Corne shield ([#80](https://github.com/zmkfirmware/zmk/pull/80)) shield definition was added. - Initial [encoder](/docs/features/encoders) support ([#61](https://github.com/zmkfirmware/zmk/pull/61)) was added. diff --git a/docs/blog/2021-07-17-zephyr-2-5.md b/docs/blog/2021-07-17-zephyr-2-5.md index 153027bb4cd..789a644caee 100644 --- a/docs/blog/2021-07-17-zephyr-2-5.md +++ b/docs/blog/2021-07-17-zephyr-2-5.md @@ -61,7 +61,7 @@ Once the container has rebuilt, VS Code will be running the 2.5 Docker image. The following steps will get you building ZMK locally against Zephyr 2.5: -- Run the updated [toolchain installation](/docs/development/setup#toolchain-installation) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work) +- Run the updated [toolchain installation](/docs/development/setup) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work) - pull the latest ZMK `main` with `git pull` for your ZMK checkout - run `west update` to pull the updated Zephyr version and its dependencies diff --git a/docs/blog/2022-04-02-zephyr-3-0.md b/docs/blog/2022-04-02-zephyr-3-0.md index 3b16b87ea78..92e8b33bc1c 100644 --- a/docs/blog/2022-04-02-zephyr-3-0.md +++ b/docs/blog/2022-04-02-zephyr-3-0.md @@ -62,7 +62,7 @@ Once the container has rebuilt, VS Code will be running the 3.0 Docker image. The following steps will get you building ZMK locally against Zephyr 3.0: -- Run the updated [toolchain installation](/docs/development/setup#toolchain-installation) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work) +- Run the updated [toolchain installation](/docs/development/setup) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work) - pull the latest ZMK `main` with `git pull` for your ZMK checkout - run `west update` to pull the updated Zephyr version and its dependencies diff --git a/docs/blog/2022-04-10-zmk-sotf-5.md b/docs/blog/2022-04-10-zmk-sotf-5.md index 43cb4e67209..1a0ea270c8d 100644 --- a/docs/blog/2022-04-10-zmk-sotf-5.md +++ b/docs/blog/2022-04-10-zmk-sotf-5.md @@ -132,7 +132,7 @@ Another persistent bug that Apple users experienced was related to crashes and p The long awaited locality enhancement was finally merged by [petejohanson] in [#547](https://github.com/zmkfirmware/zmk/pull/547), allowing more fine grained control of where certain behaviors are invoked. Some key improvements thanks to the changes: - [RGB Underglow](/docs/features/underglow) behaviors now run globally, so enabling/disabling RGB, changing the color, animation, etc. applies to both sides of a split properly. -- [Reset](/docs/behaviors/reset#reset)/[Bootloader](/docs/behaviors/reset#bootloader) behaviors now run wherever the key was pressed. For example, adding a `&bootloader` reference to the peripheral side of a split will now put that side of the split into the bootloader when pressed. +- [Reset](/docs/behaviors/reset#reset)/[Bootloader](/docs/behaviors/reset#bootloader-reset) behaviors now run wherever the key was pressed. For example, adding a `&bootloader` reference to the peripheral side of a split will now put that side of the split into the bootloader when pressed. #### Split Connections diff --git a/docs/blog/2023-04-06-zephyr-3-2.md b/docs/blog/2023-04-06-zephyr-3-2.md index 4bb21999422..21058ca9544 100644 --- a/docs/blog/2023-04-06-zephyr-3-2.md +++ b/docs/blog/2023-04-06-zephyr-3-2.md @@ -87,7 +87,7 @@ Once the container has rebuilt, VS Code will be running the 3.2 Docker image. The following steps will get you building ZMK locally against Zephyr 3.2: -- Run the updated [toolchain installation](/docs/development/setup#toolchain-installation) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work) +- Run the updated [toolchain installation](/docs/development/setup) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work) - Install the latest version of `west` by running `pip3 install --user --update west`. - pull the latest ZMK `main` with `git pull` for your ZMK checkout - run `west update` to pull the updated Zephyr version and its dependencies diff --git a/docs/blog/2024-02-09-zephyr-3-5.md b/docs/blog/2024-02-09-zephyr-3-5.md index b3fec6cbda2..738f22daa81 100644 --- a/docs/blog/2024-02-09-zephyr-3-5.md +++ b/docs/blog/2024-02-09-zephyr-3-5.md @@ -70,7 +70,7 @@ Once the container has rebuilt, VS Code will be running the 3.5 Docker image. The following steps will get you building ZMK locally against Zephyr 3.5: -- Run the updated [toolchain installation](/docs/development/setup#toolchain-installation) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work) +- Run the updated [toolchain installation](/docs/development/setup) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work) - Install the latest version of `west` by running `pip3 install --user --update west`. - Pull the latest ZMK `main` with `git pull` for your ZMK checkout - Run `west update` to pull the updated Zephyr version and its dependencies diff --git a/docs/docs/behaviors/index.mdx b/docs/docs/behaviors/index.mdx index 4a05f5653a0..7cd82d3e4b8 100644 --- a/docs/docs/behaviors/index.mdx +++ b/docs/docs/behaviors/index.mdx @@ -46,10 +46,10 @@ Below is a summary of pre-defined behavior bindings and user-definable behaviors ## Reset behaviors -| Binding | Behavior | Description | -| ------------- | --------------------------------- | ---------------------------------------------------------------------------------------- | -| `&sys_reset` | [Reset](reset.md#reset) | Resets the keyboard and re-runs the firmware flashed to the device | -| `&bootloader` | [Bootloader](reset.md#bootloader) | Resets the keyboard and puts it into bootloader mode, allowing you to flash new firmware | +| Binding | Behavior | Description | +| ------------- | --------------------------------------- | ---------------------------------------------------------------------------------------- | +| `&sys_reset` | [Reset](reset.md#reset) | Resets the keyboard and re-runs the firmware flashed to the device | +| `&bootloader` | [Bootloader](reset.md#bootloader-reset) | Resets the keyboard and puts it into bootloader mode, allowing you to flash new firmware | ## Output selection behaviors diff --git a/docs/docs/customization.md b/docs/docs/customization.md index 46427b9e2f9..96b5e4ea9a0 100644 --- a/docs/docs/customization.md +++ b/docs/docs/customization.md @@ -40,7 +40,7 @@ If you need to, a review of [Learn The Basics Of Git In Under 10 Minutes](https: ::: :::note -It is also possible to build firmware locally on your computer by following the [toolchain setup](development/setup.mdx) and +It is also possible to build firmware locally on your computer by following the [toolchain setup](development/setup/index.md) and [building instructions](development/build-flash.mdx), which includes pointers to [building using your `zmk-config` folder](development/build-flash.mdx#building-from-zmk-config-folder). ::: diff --git a/docs/docs/development/new-shield.mdx b/docs/docs/development/new-shield.mdx index a542fc84995..d48e0d1de97 100644 --- a/docs/docs/development/new-shield.mdx +++ b/docs/docs/development/new-shield.mdx @@ -554,7 +554,7 @@ Add additional bindings as necessary to match the default number of encoders on ### GitHub Actions -Using GitHub Actions to build your new firmware can save you from doing any local [development setup](./setup.mdx), +Using GitHub Actions to build your new firmware can save you from doing any local [development setup](./setup/index.md), at the expense of a longer feedback loop if there are issues. To push your changes and trigger a build: - Add all your pending changes with `git add .` @@ -566,7 +566,7 @@ Once pushed, click on the "Actions" tab of the repo you created in the first ste ### Local Build :::note -To build locally, be sure you've followed the [development setup](./setup.mdx) guide first. +To build locally, be sure you've followed the [development setup](./setup/index.md) guide first. ::: Once you've fully created the new keyboard shield definition, diff --git a/docs/docs/development/setup.mdx b/docs/docs/development/setup.mdx deleted file mode 100644 index bc275804cf7..00000000000 --- a/docs/docs/development/setup.mdx +++ /dev/null @@ -1,322 +0,0 @@ ---- -title: Toolchain Setup -sidebar_label: Toolchain Setup ---- - -import Tabs from "@theme/Tabs"; -import TabItem from "@theme/TabItem"; - -export const OsTabs = (props) => ( - - {/* eslint-disable-next-line */} - {props.children} - -); - -This guide will show you how to set up a development environment for building ZMK locally. - -## Install Dependencies - -Click the operating system you are using. (The VS Code & Docker option can be used on any OS.) - - - - -This option use the same [Docker image which is used by the GitHub action](https://github.com/zmkfirmware/zmk-docker) for local development. Beyond the benefits of [dev/prod parity](https://12factor.net/dev-prod-parity), this approach is also the easiest to set up. No toolchain or dependencies are necessary when using Docker; the container image you'll be using already has the toolchain installed and set up to use. - -1. Install [Docker Desktop](https://www.docker.com/products/docker-desktop) for your operating system. -2. Install [Visual Studio Code](https://code.visualstudio.com/) -3. Install the [Remote - Containers extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) - -:::info -The docker container already includes `west`. Skip past the following section to [Get Source Code](#get-source-code). -::: - - - - -Open Zephyr's [Getting Started Guide](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html) and follow the instructions under these sections: - -- [Select and Update OS](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#select-and-update-os) -- [Install Dependencies](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#install-dependencies) -- [Install Zephyr SDK](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#install-zephyr-sdk) - -Return to this guide once you are finished with each section. - - - - -Open Zephyr's [Getting Started Guide](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html) and follow the instructions under these sections: - -- [Select and Update OS](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#select-and-update-os) -- [Install Dependencies](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#install-dependencies) -- [Install Zephyr SDK](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#install-zephyr-sdk) - -Return to this guide once you are finished with each section. - -`dfu-util` is required to flash devices that use DFU, but there is currently no maintained package for it on Chocolatey. [QMK Toolbox](https://github.com/qmk/qmk_toolbox) contains a working version of it though. - - - - -Open Zephyr's [Getting Started Guide](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html) and follow the instructions under these sections: - -- [Select and Update OS](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#select-and-update-os) -- [Install Dependencies](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#install-dependencies) -- [Install Zephyr SDK](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#install-zephyr-sdk) - -Return to this guide once you are finished with each section. - - - - -#### Install Base Dependencies - -Open Zephyr's [Getting Started Guide](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html) and follow the instructions for Ubuntu under these sections: - -- [Select and Update OS](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#select-and-update-os) -- [Install Dependencies](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#install-dependencies) - -Return to this guide once you are finished with each section. - -#### Install Cross-Compile Toolchain - -Because Raspberry OS runs on the same architecture (but different ABI) as ARM keyboard MCUs, the operating system's installed [cross compilers](https://docs.zephyrproject.org/3.5.0/develop/toolchains/other_x_compilers.html) can be used to target the different ABI. Building for non-ARM MCUs has not been tested. - -First, the cross compiler should be installed: - -```sh -sudo apt install gcc-arm-none-eabi -``` - -Next, we'll configure Zephyr with some [environment variables](https://docs.zephyrproject.org/3.5.0/develop/env_vars.html#env-vars) needed to find the cross compiler. Create a file named `~/.zephyrrc` if it doesn't exist, and add these lines to it: - -```sh -export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile -export CROSS_COMPILE=/usr/bin/arm-none-eabi- -``` - - - - -Follow Zephyr's [Install Linux Host Dependencies](https://docs.zephyrproject.org/3.5.0/develop/getting_started/installation_linux.html) documentation for Fedora. - - - - -### Install West - -`west` is the [Zephyr® Project's meta-tool](https://docs.zephyrproject.org/3.5.0/develop/west/index.html) used to configure and build Zephyr OS applications. - -West can be installed by using the `pip` python package manager. The [Zephyr™ instructions](https://docs.zephyrproject.org/3.5.0/develop/west/install.html) are summarized here: - - - - -Install west: - -```sh -pip3 install --user -U west -``` - -Verify that west is installed: - -```sh -west --version -``` - -This should print a message like "West version: v0.14.0". If it prints an error instead, make sure `~/.local/bin` is on your `PATH` environment variable. You can add it with these commands: - -```sh -echo 'export PATH=~/.local/bin:"$PATH"' >> ~/.bashrc -source ~/.bashrc -``` - - - - -Install west: - -```sh -pip3 install -U west -``` - -Verify that west is installed: - -```sh -west --version -``` - -This should print a message like "West version: v0.14.0". If it prints an error instead, make sure that the Python scripts directory is on your `PATH` environment variable. You can add it by opening a PowerShell window and running the following commands: - -```powershell -$Scripts = python -c "import sysconfig; print(sysconfig.get_path('scripts'))" -$Path = [Environment]::GetEnvironmentVariable('PATH', 'User') -[Environment]::SetEnvironmentVariable('PATH', "$Path;$Scripts", 'User') -$env:PATH += ";$Scripts" -``` - - - - -Install west: - -```sh -pip3 install -U west -``` - - - - -## Get Source Code - -Next, you'll need to clone the ZMK source repository if you haven't already. Navigate to the folder you would like to place your `zmk` directory in and run the following command: - -``` -git clone https://github.com/zmkfirmware/zmk.git -``` - -## Initialize & Update Zephyr Workspace - -Since ZMK is built as a Zephyr™ application, the next step is -to use `west` to initialize and update your workspace. The ZMK -Zephyr™ application is in the `app/` source directory: - -### Step into the repository - - - - -```sh -cd zmk -``` - - - - -```sh -cd zmk -``` - - - - -```sh -cd zmk -``` - - - - -```sh -cd zmk -``` - - - - -```sh -cd zmk -``` - - - - - -Open the `zmk` checkout folder in VS Code. The repository includes a configuration for containerized development, so an alert will pop up: - -![VS Code Dev Container Configuration Alert](../assets/dev-setup/vscode_devcontainer.png) - -Click `Reopen in Container` in order to reopen the VS Code with the running container. - -The first time you do this on your machine, it will pull the docker image down from the registry and build the container. Subsequent launches are much faster! - -:::warning -All subsequent steps must be performed from the VS Code terminal _inside_ the container. -::: - - - - -### Initialize the Application - -```sh -west init -l app/ -``` - -### Update to Fetch Modules - -```sh -west update -``` - -:::tip -This step pulls down quite a bit of tooling. Go grab a cup of coffee, it can take 10-15 minutes even on a good internet connection! -::: - -:::info -If you're using Docker, you're done with setup! You must restart the container at this point. The easiest way to do so is to close the VS Code window, verify that the container has stopped in Docker Dashboard, and reopen the container with VS Code. - -Once your container is restarted, proceed to [Building and Flashing](development/build-flash.mdx). -::: - -### Export Zephyr CMake package - -This allows CMake to load the code needed to build ZMK. - -```sh -west zephyr-export -``` - -### Install Zephyr Python Dependencies - -Some additional Python dependencies are listed in Zephyr's `scripts/requirements.txt` file. - - - - -```sh -pip3 install --user -r zephyr/scripts/requirements.txt -``` - - - - -```sh -pip3 install -r zephyr/scripts/requirements.txt -``` - - - - -```sh -pip3 install -r zephyr/scripts/requirements.txt -``` - - - diff --git a/docs/docs/development/setup/docker.md b/docs/docs/development/setup/docker.md new file mode 100644 index 00000000000..767331e409f --- /dev/null +++ b/docs/docs/development/setup/docker.md @@ -0,0 +1,53 @@ +--- +title: Docker +sidebar_label: Docker +--- + +:::note +Currently the Docker approach is only documented for [VS Code](https://github.com/microsoft/vscode) (not [Code OSS](https://github.com/microsoft/vscode/wiki/Differences-between-the-repository-and-Visual-Studio-Code)). While it can be replicated using [devcontainers](https://containers.dev/) this is not documented yet - contributions are welcome! +::: + +### Source Code + +First, you'll need to clone the ZMK source repository if you haven't already. Open a terminal and navigate to the folder you would like to place your `zmk` directory in, then run the following command: + +```sh +git clone https://github.com/zmkfirmware/zmk.git +``` + +### Installing Development Tools + +1. Install [Docker Desktop](https://www.docker.com/products/docker-desktop) for your operating system. +2. Install [VS Code](https://code.visualstudio.com/). +3. Install the [Remote - Containers extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers). + +### Initialize & Update Zephyr Workspace + +Open the `zmk` checkout folder in VS Code. The repository includes a configuration for containerized development, so an alert will pop up: + +![VS Code Dev Container Configuration Alert](../../assets/dev-setup/vscode_devcontainer.png) + +Click `Reopen in Container` in order to reopen the VS Code with the running container. If the alert fails to pop up or you accidentally close it, you can perform the same action by pressing `ctrl+shift+p` and selecting `Remote: Show Remote Menu`. + +The first time you do this on your machine, it will pull the docker image down from the registry and build the container. Subsequent launches are much faster! + +:::caution +The following step and any future [build commands](../build-flash.mdx) must be executed from the VS Code terminal _inside_ the container. +::: + +Initialize the application and update to fetch modules, including Zephyr: + +```sh +west init -l app/ +west update +``` + +:::tip +This step pulls down quite a bit of tooling, be patient! +::: + +:::info +You must restart the container at this point. The easiest way to do so is to close the VS Code window, verify that the container has stopped in Docker Dashboard, and reopen the container with VS Code. + +Your setup is complete once your container has restarted. +::: diff --git a/docs/docs/development/setup/index.md b/docs/docs/development/setup/index.md new file mode 100644 index 00000000000..5c795fa22c7 --- /dev/null +++ b/docs/docs/development/setup/index.md @@ -0,0 +1,20 @@ +--- +title: Getting Started +sidebar_label: Getting Started +--- + +:::tip +We recommend reading through the setup process before following it step by step, to ensure that you are happy with installing the required dependencies. +::: + +## Environment Setup + +There are two ways to set up the ZMK development environment: + +- [Docker](/docs/development/setup/docker): \ + A self-contained development environment. It uses the same [Docker image which is used by the GitHub action](https://github.com/zmkfirmware/zmk-docker) for local development. Beyond the benefits of [dev/prod parity](https://12factor.net/dev-prod-parity), this approach may be easier to set up for some operating systems. No toolchain or dependencies are necessary when using Docker; the container image has the toolchain installed and set up to use. + +- [Native](/docs/development/setup/native):\ + This uses your operating system directly. Usually runs slightly faster than the Docker approach, and can be preferable for users who already have the dependencies on their system. + +Please see the [Docker](/docs/development/setup/docker) instructions or [native](/docs/development/setup/native) instructions to continue setup. diff --git a/docs/docs/development/setup/native.mdx b/docs/docs/development/setup/native.mdx new file mode 100644 index 00000000000..d077d7d1d7d --- /dev/null +++ b/docs/docs/development/setup/native.mdx @@ -0,0 +1,353 @@ +--- +title: Native Setup +sidebar_label: Native +--- + +import Tabs from "@theme/Tabs"; +import TabItem from "@theme/TabItem"; + +export const OsTabs = (props) => ( + + {/* eslint-disable-next-line */} + {props.children} + + +); + +export const OsNoteTabs = (props) => ( + + {/* eslint-disable-next-line */} + {props.children} + + +); + +export const EnvTabs = (props) => ( + + {/* eslint-disable-next-line */} + {props.children} + + +); + +export const WinTermTabs = (props) => ( + + {/* eslint-disable-next-line */} + {props.children} + + +); + +## 1. Install Zephyr Dependencies + +Open Zephyr's [Getting Started Guide](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html) and follow the instructions under these sections: + +- [Select and Update OS](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#select-and-update-os) +- [Install Dependencies](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#install-dependencies) + +:::info +Zephyr's [Install Linux Host Dependencies](https://docs.zephyrproject.org/3.5.0/develop/getting_started/installation_linux.html) page may be of use for users of Linux distributions which are not based on Ubuntu. +::: + +## 2. Source Code + +Next, you'll need to clone the ZMK source repository if you haven't already. Open a terminal and navigate to the folder you would like to place your `zmk` directory in, then run the following command: + +```sh +git clone https://github.com/zmkfirmware/zmk.git +``` + +Then step into the repository. + +```sh +cd zmk +``` + +## 3. Get Zephyr and install Python dependencies + +:::note +These steps are very similar to Zephyr's [Get Zephyr and install Python dependencies](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#get-zephyr-and-install-python-dependencies) instructions, but specialized for ZMK. +::: + + + + + + +1. Use `apt` to install Python `venv` package: + +```sh +sudo apt install python3-venv +``` + +2. Create a new virtual environment and activate it: + +```sh +python3 -m venv .venv +source .venv/bin/activate +``` + + + + +1. Create a new virtual environment: + +```sh +python -m venv .venv +``` + +2. Activate the virtual environment: + + + + +```sh +.venv\Scripts\activate.bat +``` + + + + + +```powershell +.venv\Scripts\Activate.ps1 +``` + + + + + + + + +1. Create a new virtual environment: + +```sh +python3 -m venv .venv +``` + +2. Activate the virtual environment: + +```sh +source .venv/bin/activate +``` + + + + +Once activated your shell will be prefixed with `(.venv)`. The virtual environment can be deactivated at any time by running `deactivate`. + +:::note +Remember to activate the virtual environment every time you start working. +::: + +4. Install west: + +```sh +pip install west +``` + +5. Initialize the application and update to fetch modules, including Zephyr: + +```sh +west init -l app/ +west update +``` + +:::tip +This step pulls down quite a bit of tooling, be patient! +::: + +6. Export a [Zephyr CMake package](https://docs.zephyrproject.org/3.5.0/build/zephyr_cmake_package.html#cmake-pkg). This allows CMake to automatically load boilerplate code required for building Zephyr applications. + +```sh +west zephyr-export +``` + +7. Install the additional dependencies found in Zephyr's `requirements-base.txt`: + +```sh +pip install -r zephyr/scripts/requirements-base.txt +``` + + + + + +1. Install `west`: + +```sh +pip3 install --user -U west +``` + +:::note +You need `~/.local/bin` to be on your `PATH` environment variable; verify that it is by running + +```sh +west --version +``` + +If this prints an error rather than a `west` version number, then add `~/.local/bin` to your `PATH`: + +```sh +echo 'export PATH=~/.local/bin:"$PATH"' >> ~/.bashrc +source ~/.bashrc +``` + +::: + + + + +1. Install `west`: + +```sh +pip install -U west +``` + +:::note +You need the Python scripts directory to be on your PATH environment variable; verify that it is by running + +```sh +west --version +``` + +If this prints an error rather than a `west` version number, then add said directory to your `PATH` with PowerShell: + +```powershell +$Scripts = python -c "import sysconfig; print(sysconfig.get_path('scripts'))" +$Path = [Environment]::GetEnvironmentVariable('PATH', 'User') +[Environment]::SetEnvironmentVariable('PATH', "$Path;$Scripts", 'User') +$env:PATH += ";$Scripts" +``` + +::: + + + + + +1. Install `west`: + +```sh +pip3 install -U west +``` + + + + +2. Initialize the application and update to fetch modules, including Zephyr: + +```sh +west init -l app/ +west update +``` + +:::tip +This step pulls down quite a bit of tooling, be patient! +::: + +3. Export a [Zephyr CMake package](https://docs.zephyrproject.org/3.5.0/build/zephyr_cmake_package.html#cmake-pkg). This allows CMake to automatically load boilerplate code required for building Zephyr applications. + +```sh +west zephyr-export +``` + + + + +4. Install the additional dependencies found in Zephyr's `requirements-base.txt`: + +```sh +pip3 install --user -r zephyr/scripts/requirements-base.txt +``` + + + + + +4. Install the additional dependencies found in Zephyr's `requirements-base.txt`: + +```sh +pip install -r zephyr/scripts/requirements-base.txt +``` + + + + +4. Install the additional dependencies found in Zephyr's `requirements-base.txt`. + +```sh +pip3 install -r zephyr/scripts/requirements-base.txt +``` + + + + + + +## 4. Install Zephyr SDK + +Return to Zephyr's Getting Started Guide and [Install Zephyr SDK](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#install-zephyr-sdk). + +### OS specific notes + + + + `dfu-util` is required to flash devices that use DFU, but there is currently + no maintained package for it on Chocolatey. [QMK + Toolbox](https://github.com/qmk/qmk_toolbox) contains a working version of it + though. + + + +#### Install Cross-Compile Toolchain + +Because Raspberry OS runs on the same architecture (but different ABI) as ARM keyboard MCUs, the operating system's installed [cross compilers](https://docs.zephyrproject.org/3.5.0/develop/toolchains/other_x_compilers.html) can be used to target the different ABI. Building for non-ARM MCUs has not been tested. + +First, the cross compiler should be installed: + +```sh +sudo apt install gcc-arm-none-eabi +``` + +Next, we'll configure Zephyr with some [environment variables](https://docs.zephyrproject.org/3.5.0/develop/env_vars.html#env-vars) needed to find the cross compiler. Create a file named `~/.zephyrrc` if it doesn't exist, and add these lines to it: + +```sh +export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile +export CROSS_COMPILE=/usr/bin/arm-none-eabi- +``` + + + + +Your setup is now complete. diff --git a/docs/docs/troubleshooting.md b/docs/docs/troubleshooting.md index 09efdecf770..876cbb9b4d2 100644 --- a/docs/docs/troubleshooting.md +++ b/docs/docs/troubleshooting.md @@ -34,7 +34,7 @@ macOS 14.x (Sonoma) Finder may report an "Error code -36" when copying ` Date: Sun, 9 Jun 2024 21:32:26 -0700 Subject: [PATCH 2/3] refactor(docs): Split up troubleshooting page into a section --- docs/blog/2023-10-05-zmk-sotf-6.md | 2 +- docs/docs/customization.md | 2 +- docs/docs/features/bluetooth.md | 50 +----- docs/docs/troubleshooting.md | 143 ------------------ docs/docs/troubleshooting/building-issues.md | 54 +++++++ .../troubleshooting/connection-issues.mdx | 140 +++++++++++++++++ docs/docs/troubleshooting/flashing-issues.md | 29 ++++ docs/docs/troubleshooting/index.mdx | 10 ++ docs/docs/user-setup.mdx | 2 +- docs/sidebars.js | 15 +- 10 files changed, 251 insertions(+), 196 deletions(-) delete mode 100644 docs/docs/troubleshooting.md create mode 100644 docs/docs/troubleshooting/building-issues.md create mode 100644 docs/docs/troubleshooting/connection-issues.mdx create mode 100644 docs/docs/troubleshooting/flashing-issues.md create mode 100644 docs/docs/troubleshooting/index.mdx diff --git a/docs/blog/2023-10-05-zmk-sotf-6.md b/docs/blog/2023-10-05-zmk-sotf-6.md index fb8dc131d21..bd818cf67dc 100644 --- a/docs/blog/2023-10-05-zmk-sotf-6.md +++ b/docs/blog/2023-10-05-zmk-sotf-6.md @@ -105,7 +105,7 @@ Note that documentation is still lacking for utilizing more than one peripheral [petejohanson] contributed a fix to release held keys on peripheral disconnect [#1340](https://github.com/zmkfirmware/zmk/pull/1340), which makes scenarios where a split disconnects unexpectedly less painful. -[petejohanson] also improved [the `settings_reset` shield](/docs/troubleshooting#split-keyboard-halves-unable-to-pair) by making it clear bonds more reliably, and allow it to build for all boards in [#1879](https://github.com/zmkfirmware/zmk/pull/1879). +[petejohanson] also improved [the `settings_reset` shield](/docs/troubleshooting/connection-issues#split-keyboard-halves-unable-to-pair) by making it clear bonds more reliably, and allow it to build for all boards in [#1879](https://github.com/zmkfirmware/zmk/pull/1879). [petejohanson] and [xudongzheng] contributed additional split connectivity improvements, via using directed advertising in [#1913](https://github.com/zmkfirmware/zmk/pull/1913) and improving the robustness of central scanning in [#1912](https://github.com/zmkfirmware/zmk/pull/1912). diff --git a/docs/docs/customization.md b/docs/docs/customization.md index 96b5e4ea9a0..87d78a22b1c 100644 --- a/docs/docs/customization.md +++ b/docs/docs/customization.md @@ -50,7 +50,7 @@ It is also possible to build firmware locally on your computer by following the For normal keyboards, follow the same flashing instructions as before to flash your updated firmware. For split keyboards, only the central (left) side will need to be reflashed if you are just updating your keymap. -More troubleshooting information for split keyboards can be found [here](troubleshooting.md#split-keyboard-halves-unable-to-pair). +More troubleshooting information for split keyboards can be found [here](troubleshooting/connection-issues.mdx#split-keyboard-halves-unable-to-pair). ## Building Additional Keyboards diff --git a/docs/docs/features/bluetooth.md b/docs/docs/features/bluetooth.md index 28ba21367d1..d148acd82db 100644 --- a/docs/docs/features/bluetooth.md +++ b/docs/docs/features/bluetooth.md @@ -47,52 +47,4 @@ Firmware changes that would modify the descriptor include the following: While the descriptor refresh happens on boot for USB, hosts will frequently cache this descriptor for BLE devices. In order to refresh this cache, you need to remove the keyboard from the host device, clear the profile associated with the host on the keyboard, then pair again. -For Windows systems you might need to follow the instructions in [this troubleshooting section](#windows-connected-but-not-working) below. - -## Troubleshooting - -### Connectivity Issues - -Some users may experience a poor connection between the keyboard and the host. This might be due to poor quality BLE hardware, a metal enclosure on the keyboard or host, or the distance between them. Increasing the transmit power of the keyboard's BLE radio may reduce the severity of this problem. To do this, set the `CONFIG_BT_CTLR_TX_PWR_PLUS_8` configuration value in the `.conf` file of your user config directory as such: - -```ini -CONFIG_BT_CTLR_TX_PWR_PLUS_8=y -``` - -For the `nRF52840`, the value `PLUS_8` can be set to any multiple of four between `MINUS_20` and `PLUS_8`. The default value for this config is `0`, but if you are having connection issues it is recommended to set it to `PLUS_8` because the power consumption difference is negligible. For more information on changing the transmit power of your BLE device, please refer to [the Zephyr docs.](https://docs.zephyrproject.org/3.5.0/kconfig.html#CONFIG_BT_CTLR_TX_PWR) - -:::info -This setting can also improve the connection strength between the keyboard halves for split keyboards. -::: - -### Using bluetooth output with USB power - -If you want to test bluetooth output on your keyboard and are powering it through the USB connection rather than a battery, you will be able to pair with a host device but may not see keystrokes sent. In this case you need to use the [output selection behavior](../behaviors/outputs.md) to prefer sending keystrokes over bluetooth rather than USB. This might be necessary even if you are not powering from a device capable of receiving USB inputs, such as a USB charger. - -### Issues with dual boot setups - -Since ZMK associates pairing/bond keys with hardware addresses of hosts, you cannot pair to two different operating systems in a dual boot system at the same time. -While you can find [documented workarounds](https://wiki.archlinux.org/title/bluetooth#Dual_boot_pairing) that involve copying pairing keys across operating systems and use both OS with a single profile, they can be fairly involved and should be followed with caution. - -### macOS Connected But Not Working - -If you attempt to pair a ZMK keyboard from macOS in a way that causes a bonding issue, macOS may report the keyboard as connected, but fail to actually work. If this occurs: - -1. Remove the keyboard from macOS using the Bluetooth control panel. -1. Invoke `&bt BT_CLR` on the keyboard while the profile associated with the macOS device is active, by pressing the correct keys for your particular keymap. -1. Try connecting again from macOS. - -### Windows Connected But Not Working - -Occasionally pairing the keyboard to a Windows device might result in a state where the keyboard is connected but does not send any key strokes. -If this occurs: - -1. Remove the keyboard from Windows using the Bluetooth settings. -1. Invoke `&bt BT_CLR` on the keyboard while the profile associated with the Windows device is active, by pressing the correct keys for your particular keymap. -1. Turn off Bluetooth from Windows settings, then turn it back on. -1. Pair the keyboard to the Windows device. - -If this doesn't help, try following the procedure above but replace step 3 with one of the following: - -- Restart the Windows device -- Open "Device Manager," turn on "Show hidden devices" from the "View" menu, then find and delete the keyboard under the "Bluetooth" item +For Windows systems you might need to follow the additional instructions in [the section on troubleshooting connection issues](troubleshooting/connection-issues.mdx#windows-connected-but-not-working). diff --git a/docs/docs/troubleshooting.md b/docs/docs/troubleshooting.md deleted file mode 100644 index 876cbb9b4d2..00000000000 --- a/docs/docs/troubleshooting.md +++ /dev/null @@ -1,143 +0,0 @@ ---- -title: Troubleshooting -sidebar_title: Troubleshooting ---- - -The following page provides suggestions for common errors that may occur during firmware compilation or other issues with keyboard usage. If the information provided is insufficient to resolve the issue, feel free to seek out help from the [ZMK Discord](https://zmk.dev/community/discord/invite). - -Please also see [the troubleshooting section](features/bluetooth.md#troubleshooting) under the Bluetooth feature page for issues related to bluetooth. - -### File Transfer Error - -Variations of the warnings shown below occur when flashing the `.uf2` onto the microcontroller. This is because the microcontroller resets itself before the OS receives confirmation that the file transfer is complete. Errors like this are normal and can generally be ignored. Verification of a functional board can be done by attempting to pair your newly flashed keyboard to your computer via Bluetooth or plugging in a USB cable if `ZMK_USB` is enabled in your Kconfig.defconfig. - -| ![Example Error Screen](../docs/assets/troubleshooting/filetransfer/windows.png) | -| :------------------------------------------------------------------------------: | -| An example of the file transfer error on Windows 10 | - -| ![Example Error Screen](../docs/assets/troubleshooting/filetransfer/linux.png) | -| :----------------------------------------------------------------------------: | -| An example of the file transfer error on Linux | - -| ![Example Error Screen](../docs/assets/troubleshooting/filetransfer/mac.png) | -| :--------------------------------------------------------------------------: | -| An example of the file transfer error on macOS | - -### macOS Ventura error - -macOS 13.0 (Ventura) Finder may report an error code 100093 when copying `.uf2` files into microcontrollers. This bug is limited to the operating system's Finder. You can work around it by copying on Terminal command line or use a third party file manager. Issue is fixed in macOS version 13.1. - -### macOS Sonoma error - -macOS 14.x (Sonoma) Finder may report an "Error code -36" when copying `.uf2` files into microcontrollers. A similar "fcopyfile failed: Input/output error" will also be reported when copying is performed using Terminal command line. These errors can be ignored because they are reported when the bootloader disconnects automatically after the uf2 file is copied successfully. - -### CMake Error - -An error along the lines of `CMake Error at (zmk directory)/zephyr/cmake/generic_toolchain.cmake:64 (include): include could not find load file:` during firmware compilation indicates that the Zephyr Environment Variables are not properly defined. -For more information, see [Zephyr's CMake Package](https://docs.zephyrproject.org/3.5.0/build/zephyr_cmake_package.html). - -### West Build Errors - -West build errors usually indicate syntax problems in the `.keymap` file during the compilation process. The following are some examples and root causes. - -:::note -If you are reviewing these errors in the GitHub Actions tab, they can be found in the `West Build` step of the build process. -::: - -#### Keymap error - -If you get an error stating `Keymap node not found, check a keymap is available and is has compatible = "zmk,keymap" set` this is an indication that the build process cannot find the keymap. Double check that the `.keymap` file is present and has been discovered by the build process. This can be checked by looking for a line in the build log stating `-- Using keymap file: /path/to/keymap/file/.keymap`. Inside the keymap file ensure the keymap node has `compatible = zmk,keymap` and it's not misspelled. For more information see the [Keymap](features/keymaps.mdx) and [Config](config/index.md) documentation. - -#### Devicetree errors - -A `devicetree error` followed by a reference to the line number on `.keymap` refers to an issue at the exact line position in that file. For example, below error message indicates a missing `;` at line 109 of the `cradio.keymap` file: - -``` -devicetree error: /__w/zmk-config/zmk-config/config/cradio.keymap:109 (column 4): parse error: expected ';' or ',' -``` - -A `devicetree error` followed by an `empty_file.c` reference with `lacks #binding-cells` string indicates possible problems with improper parameters for specific bindings: - -``` -devicetree error: lacks #binding-cells -``` - -This error can be triggered by incorrect binding syntax such as `&kp BT_SEL 0` instead of `&bt BT_SEL 0`. - -A `devicetree_generated.h` error that follows with an "undeclared here" string indicates a problem with key bindings, like behavior nodes (e.g. `&kp` or `&mt`) with incorrect number of parameters: - -``` -/__w/zmk-config/zmk-config/build/zephyr/include/generated/devicetree_generated.h:3756:145: error: 'DT_N_S_keymap_S_symbol_layer_P_bindings_IDX_12_PH_P_label' undeclared here (not in a function); did you mean 'DT_N_S_keymap_S_symbol_layer_P_bindings_IDX_16_PH'? -``` - -In this example, the error string `DT_N_S_keymap_S_symbol_layer_P_bindings_IDX_12_PH_P_label` indicates a problem with the key binding in position `12` in the `symbol_layer` of the keymap. - -:::info -Key positions are numbered starting from `0` at the top left key on the keymap, incrementing horizontally, row by row. -::: - -:::tip -A common mistake that leads to this error is to use [key press keycodes](behaviors/key-press.md) without the leading `&kp` binding. That is, having entries such as `SPACE` that should have been `&kp SPACE`. -::: - -### Split Keyboard Halves Unable to Pair - -Split keyboard halves will automatically pair with one another, but there are some cases where this breaks, and the pairing needs to be reset, for example: - -- Switching which halves are the central/peripheral. -- Replacing the controller for one of the halves. - -These issues can be resolved by flashing a settings reset firmware to both controllers. - -:::warning - -This procedure will erase all settings, such as Bluetooth profiles, output selection, RGB underglow color, etc. - -::: - -First, acquire the reset UF2 image file with one of the following options: - -#### Option 1: Build Reset UF2 in 'zmk-config' - -Find the `build.yaml` file in your `zmk-config` folder and add an additional settings reset build for the board used by your split keyboard. For example assuming that the config repo is setup for nice!nano v2 with Corne, append the `settings_reset` shield to the `build.yaml` file as follows: - -```yml -include: - - board: nice_nano_v2 - shield: corne_left - - board: nice_nano_v2 - shield: corne_right - - board: nice_nano_v2 - shield: settings_reset -``` - -Save the file, commit the changes and push them to GitHub. Download the new firmware zip file build by the latest GitHub Actions job. In it you will find an additional `settings_reset` UF2 image file. - -#### Option 2: Download Reset UF2 from ZMK's Workflow - -1. [Open the GitHub `Actions` tab and select the `Build` workflow](https://github.com/zmkfirmware/zmk/actions?query=workflow%3ABuild+branch%3Amain+event%3Apush). -1. Find one of the 'results' for which the core-coverage job was successfully run, indicated by a green checkmark in the core-coverage bubble like the image example below. -1. From the next page under "Artifacts", download and unzip the `-settings_reset-zmk` zip file for the UF2 image. - -| ![Successful core-coverage Job](../docs/assets/troubleshooting/splitpairing/corecoverage.png) | -| :-------------------------------------------------------------------------------------------: | -| An example of a successful core-coverage job which will produce a settings_reset firmware. | - -#### Reset Split Keyboard Procedure - -Perform the following steps to reset both halves of your split keyboard: - -1. Put each half of the split keyboard into bootloader mode. -1. Flash one of the halves of the split with the downloaded settings reset UF2 image. -1. Repeat step 2 with the other half of the split keyboard. -1. Flash the actual image for each half of the split keyboard (e.g `my_board_left.uf2` to the left half, `my_board_right.uf2` to the right half). - -After completing these steps, pair the halves of the split keyboard together by resetting them at the same time. Most commonly, this is done by grounding the reset pins for each of your keyboard's microcontrollers or pressing the reset buttons at the same time. - -Once this is done, you can remove/forget the keyboard on each host device and pair it again. - -:::info - -The settings reset firmware has Bluetooth disabled to prevent the two sides from automatically re-pairing until you are done resetting them both. You will not be able to pair your keyboard or see it in any Bluetooth device lists until you have flashed the normal firmware again. - -::: diff --git a/docs/docs/troubleshooting/building-issues.md b/docs/docs/troubleshooting/building-issues.md new file mode 100644 index 00000000000..e37d3934d79 --- /dev/null +++ b/docs/docs/troubleshooting/building-issues.md @@ -0,0 +1,54 @@ +--- +title: Building Issues +sidebar_label: Building Issues +description: Troubleshooting issues when compiling ZMK firmware. +--- + +## CMake Error + +An error along the lines of `CMake Error at (zmk directory)/zephyr/cmake/generic_toolchain.cmake:64 (include): include could not find load file:` during firmware compilation indicates that the Zephyr Environment Variables are not properly defined. +For more information, see [Zephyr's CMake Package](https://docs.zephyrproject.org/3.5.0/build/zephyr_cmake_package.html). + +## West Build Errors + +West build errors usually indicate syntax problems in the `.keymap` file during the compilation process. The following are some examples and root causes. + +:::note +If you are reviewing these errors in the GitHub Actions tab, they can be found in the `West Build` step of the build process. +::: + +### Keymap Error + +If you get an error stating `Keymap node not found, check a keymap is available and is has compatible = "zmk,keymap" set` this is an indication that the build process cannot find the keymap. Double check that the `.keymap` file is present and has been discovered by the build process. This can be checked by looking for a line in the build log stating `-- Using keymap file: /path/to/keymap/file/.keymap`. Inside the keymap file ensure the keymap node has `compatible = zmk,keymap` and it's not misspelled. For more information see the [Keymap](features/keymaps.mdx) and [Config](config/index.md) documentation. + +### Devicetree Errors + +A `devicetree error` followed by a reference to the line number on `.keymap` refers to an issue at the exact line position in that file. For example, below error message indicates a missing `;` at line 109 of the `cradio.keymap` file: + +``` +devicetree error: /__w/zmk-config/zmk-config/config/cradio.keymap:109 (column 4): parse error: expected ';' or ',' +``` + +A `devicetree error` followed by an `empty_file.c` reference with `lacks #binding-cells` string indicates possible problems with improper parameters for specific bindings: + +``` +devicetree error: lacks #binding-cells +``` + +This error can be triggered by incorrect binding syntax such as `&kp BT_SEL 0` instead of `&bt BT_SEL 0`. + +A `devicetree_generated.h` error that follows with an "undeclared here" string indicates a problem with key bindings, like behavior nodes (e.g. `&kp` or `&mt`) with incorrect number of parameters: + +``` +/__w/zmk-config/zmk-config/build/zephyr/include/generated/devicetree_generated.h:3756:145: error: 'DT_N_S_keymap_S_symbol_layer_P_bindings_IDX_12_PH_P_label' undeclared here (not in a function); did you mean 'DT_N_S_keymap_S_symbol_layer_P_bindings_IDX_16_PH'? +``` + +In this example, the error string `DT_N_S_keymap_S_symbol_layer_P_bindings_IDX_12_PH_P_label` indicates a problem with the key binding in position `12` in the `symbol_layer` of the keymap. + +:::info +Key positions are numbered starting from `0` at the top left key on the keymap, incrementing horizontally, row by row. +::: + +:::tip +A common mistake that leads to this error is to use [key press keycodes](behaviors/key-press.md) without the leading `&kp` binding. That is, having entries such as `SPACE` that should have been `&kp SPACE`. +::: diff --git a/docs/docs/troubleshooting/connection-issues.mdx b/docs/docs/troubleshooting/connection-issues.mdx new file mode 100644 index 00000000000..59a6a20811d --- /dev/null +++ b/docs/docs/troubleshooting/connection-issues.mdx @@ -0,0 +1,140 @@ +--- +title: Connection Issues +sidebar_label: Connection Issues +description: Troubleshooting wireless connection issues of ZMK devices. +--- + +import Tabs from "@theme/Tabs"; +import TabItem from "@theme/TabItem"; + +export const Uf2Tabs = (props) => ( + + {/* eslint-disable-next-line */} + {props.children} + + +); + +## Split Keyboard Halves Unable to Pair + +Split keyboard halves will automatically pair with one another, but there are some cases where this breaks, and the pairing needs to be reset, for example: + +- Switching which halves are the central/peripheral. +- Replacing the controller for one of the halves. + +These issues can be resolved by flashing a settings reset firmware to both controllers. + +:::warning + +This procedure will erase all settings, such as Bluetooth profiles, output selection, RGB underglow color, etc. + +::: + +### Acquiring a Reset UF2 + +First, acquire the reset UF2 image file with one of the following options: + + + + +Find the `build.yaml` file in your `zmk-config` folder and add an additional settings reset build for the board used by your split keyboard. For example assuming that the config repo is setup for nice!nano v2 with Corne, append the `settings_reset` shield to the `build.yaml` file as follows: + +```yml +include: + - board: nice_nano_v2 + shield: corne_left + - board: nice_nano_v2 + shield: corne_right + - board: nice_nano_v2 + shield: settings_reset +``` + +Save the file, commit the changes and push them to GitHub. Download the new firmware zip file build by the latest GitHub Actions job. In it you will find an additional `settings_reset` UF2 image file. + + + + +1. [Open the GitHub `Actions` tab and select the `Build` workflow](https://github.com/zmkfirmware/zmk/actions?query=workflow%3ABuild+branch%3Amain+event%3Apush). +1. Find one of the 'results' for which the core-coverage job was successfully run, indicated by a green checkmark in the core-coverage bubble like the image example below. +1. From the next page under "Artifacts", download and unzip the `-settings_reset-zmk` zip file for the UF2 image. + +| ![Successful core-coverage Job](../../docs/assets/troubleshooting/splitpairing/corecoverage.png) | +| :----------------------------------------------------------------------------------------------: | +| An example of a successful core-coverage job which will produce a settings_reset firmware. | + + + + +### Reset Split Keyboard Procedure + +Perform the following steps to reset **_both_** halves of your split keyboard: + +1. Put each half of the split keyboard into bootloader mode. +1. Flash one of the halves of the split with the downloaded settings reset UF2 image. +1. Repeat step 2 with the other half of the split keyboard. +1. Flash the actual image for each half of the split keyboard (e.g `my_board_left.uf2` to the left half, `my_board_right.uf2` to the right half). + +After completing these steps, pair the halves of the split keyboard together by resetting them at the same time. Most commonly, this is done by grounding the reset pins for each of your keyboard's microcontrollers or pressing the reset buttons at the same time. + +Once this is done, you can remove/forget the keyboard on each host device and pair it again. + +:::info + +The settings reset firmware has Bluetooth disabled to prevent the two sides from automatically re-pairing until you are done resetting them both. You will not be able to pair your keyboard or see it in any Bluetooth device lists until you have flashed the normal firmware again. + +::: + +## Issues While Connected + +### Unreliable/Weak Connection + +Some users may experience a poor connection between the keyboard and the host. This might be due to poor quality BLE hardware, a metal enclosure on the keyboard or host, or the distance between them. Increasing the transmit power of the keyboard's BLE radio may reduce the severity of this problem. To do this, set the `CONFIG_BT_CTLR_TX_PWR_PLUS_8` configuration value in the `.conf` file of your user config directory as such: + +```ini +CONFIG_BT_CTLR_TX_PWR_PLUS_8=y +``` + +For the `nRF52840`, the value `PLUS_8` can be set to any multiple of four between `MINUS_20` and `PLUS_8`. The default value for this config is `0`, but if you are having connection issues it is recommended to set it to `PLUS_8` because the power consumption difference is negligible. For more information on changing the transmit power of your BLE device, please refer to [the Zephyr docs.](https://docs.zephyrproject.org/3.5.0/kconfig.html#CONFIG_BT_CTLR_TX_PWR) + +:::info +This setting can also improve the connection strength between the keyboard halves for split keyboards. +::: + +### Using Bluetooth Output With USB Power + +If you want to test Bluetooth output on your keyboard and are powering it through the USB connection rather than a battery, you will be able to pair with a host device but may not see keystrokes sent. In this case you need to use the [output selection behavior](../behaviors/outputs.md) to prefer sending keystrokes over Bluetooth rather than USB. This might be necessary even if you are not powering from a device capable of receiving USB inputs, such as a USB charger. + +### Issues With Dual Boot Setups + +Since ZMK associates pairing/bond keys with hardware addresses of hosts, you cannot pair to two different operating systems in a dual boot system at the same time. +While you can find [documented workarounds](https://wiki.archlinux.org/title/bluetooth#Dual_boot_pairing) that involve copying pairing keys across operating systems and use both OS with a single profile, they can be fairly involved and should be followed with caution. + +### macOS Connected but Not Working + +If you attempt to pair a ZMK keyboard from macOS in a way that causes a bonding issue, macOS may report the keyboard as connected, but fail to actually work. If this occurs: + +1. Remove the keyboard from macOS using the Bluetooth control panel. +1. Invoke `&bt BT_CLR` on the keyboard while the profile associated with the macOS device is active, by pressing the correct keys for your particular keymap. +1. Try connecting again from macOS. + +### Windows Connected but Not Working + +Occasionally pairing the keyboard to a Windows device might result in a state where the keyboard is connected but does not send any key strokes. +If this occurs: + +1. Remove the keyboard from Windows using the Bluetooth settings. +1. Invoke `&bt BT_CLR` on the keyboard while the profile associated with the Windows device is active, by pressing the correct keys for your particular keymap. +1. Turn off Bluetooth from Windows settings, then turn it back on. +1. Pair the keyboard to the Windows device. + +If this doesn't help, try following the procedure above but replace step 3 with one of the following: + +- Restart the Windows device +- Open "Device Manager," turn on "Show hidden devices" from the "View" menu, then find and delete the keyboard under the "Bluetooth" item diff --git a/docs/docs/troubleshooting/flashing-issues.md b/docs/docs/troubleshooting/flashing-issues.md new file mode 100644 index 00000000000..699555d5f92 --- /dev/null +++ b/docs/docs/troubleshooting/flashing-issues.md @@ -0,0 +1,29 @@ +--- +title: Flashing Issues +sidebar_label: Flashing Issues +description: Troubleshooting issues when flashing ZMK firmware to devices. +--- + +## File Transfer Error + +Variations of the warnings shown below occur when flashing the `.uf2` onto the microcontroller. This is because the microcontroller resets itself before the OS receives confirmation that the file transfer is complete. Errors like this are normal and can generally be ignored. Verification of a functional board can be done by attempting to pair your newly flashed keyboard to your computer via Bluetooth or plugging in a USB cable if `ZMK_USB` is enabled in your Kconfig.defconfig. + +| ![Example Error Screen](../../docs/assets/troubleshooting/filetransfer/windows.png) | +| :---------------------------------------------------------------------------------: | +| An example of the file transfer error on Windows 10 | + +| ![Example Error Screen](../../docs/assets/troubleshooting/filetransfer/linux.png) | +| :-------------------------------------------------------------------------------: | +| An example of the file transfer error on Linux | + +| ![Example Error Screen](../../docs/assets/troubleshooting/filetransfer/mac.png) | +| :-----------------------------------------------------------------------------: | +| An example of the file transfer error on macOS | + +## macOS Ventura Error + +macOS 13.0 (Ventura) Finder may report an error code 100093 when copying `.uf2` files into microcontrollers. This bug is limited to the operating system's Finder. You can work around it by copying on Terminal command line or use a third party file manager. Issue is fixed in macOS version 13.1. + +## macOS Sonoma Error + +macOS 14.x (Sonoma) Finder may report an "Error code -36" when copying `.uf2` files into microcontrollers. A similar "fcopyfile failed: Input/output error" will also be reported when copying is performed using Terminal command line. These errors can be ignored because they are reported when the bootloader disconnects automatically after the uf2 file is copied successfully. diff --git a/docs/docs/troubleshooting/index.mdx b/docs/docs/troubleshooting/index.mdx new file mode 100644 index 00000000000..45a93191b16 --- /dev/null +++ b/docs/docs/troubleshooting/index.mdx @@ -0,0 +1,10 @@ +--- +title: Troubleshooting +sidebar_label: Troubleshooting +--- + +import DocCardList from "@theme/DocCardList"; + +The following pages provide suggestions for common errors that may occur while setting up or using devices running ZMK. If the information provided is insufficient to resolve an issue, feel free to seek out additional help from the [ZMK Discord](https://zmk.dev/community/discord/invite). + + diff --git a/docs/docs/user-setup.mdx b/docs/docs/user-setup.mdx index 355fc51d5e2..78d4362857e 100644 --- a/docs/docs/user-setup.mdx +++ b/docs/docs/user-setup.mdx @@ -225,7 +225,7 @@ For split keyboards, after flashing each half individually you can connect them :::note If you have issues connecting the halves, make sure that both sides are getting powered properly through USB or batteries, then follow the -[recommended troubleshooting procedure](troubleshooting.md#split-keyboard-halves-unable-to-pair). This is typically necessary if you +[recommended troubleshooting procedure](troubleshooting/connection-issues.mdx#split-keyboard-halves-unable-to-pair). This is typically necessary if you swapped firmware sides between controllers, like flashing left side firmware to the same controller after flashing the right, or vice versa. ::: diff --git a/docs/sidebars.js b/docs/sidebars.js index a3b4ea2ce74..e8c715c8c76 100644 --- a/docs/sidebars.js +++ b/docs/sidebars.js @@ -6,7 +6,20 @@ module.exports = { "faq", "user-setup", "customization", - "troubleshooting", + { + type: "category", + label: "Troubleshooting", + link: { + type: "doc", + id: "troubleshooting/index", + }, + collapsed: true, + items: [ + "troubleshooting/building-issues", + "troubleshooting/flashing-issues", + "troubleshooting/connection-issues", + ], + }, ], Features: [ "features/keymaps", From 7c09eb217e8ef8e667db15bf71efa3748a010c16 Mon Sep 17 00:00:00 2001 From: Cem Aksoylar Date: Sun, 9 Jun 2024 21:35:10 -0700 Subject: [PATCH 3/3] refactor(docs): Document and enforce header casing conventions --- docs/docs/behaviors/caps-word.md | 4 ++-- docs/docs/behaviors/hold-tap.mdx | 2 +- docs/docs/behaviors/index.mdx | 18 ++++++++-------- docs/docs/behaviors/key-repeat.md | 2 +- docs/docs/behaviors/layers.md | 4 ++-- docs/docs/behaviors/macros.md | 4 ++-- docs/docs/behaviors/mod-morph.md | 2 +- docs/docs/behaviors/soft-off.md | 2 +- docs/docs/behaviors/sticky-key.md | 2 +- docs/docs/behaviors/sticky-layer.md | 2 +- docs/docs/config/battery.md | 2 +- docs/docs/config/encoders.md | 4 ++-- docs/docs/development/build-flash.mdx | 2 +- docs/docs/development/documentation.md | 8 ++++++- docs/docs/development/ide-integration.mdx | 4 ++-- docs/docs/development/new-behavior.mdx | 26 +++++++++++------------ docs/docs/development/setup/native.mdx | 4 ++-- docs/docs/features/backlight.mdx | 4 ++-- docs/docs/features/beta-testing.mdx | 2 +- docs/docs/features/combos.md | 2 +- docs/docs/features/debouncing.md | 2 +- docs/docs/features/keymaps.mdx | 2 +- docs/docs/features/soft-off.md | 4 ++-- docs/docs/features/underglow.md | 6 +++--- docs/docs/intro.md | 2 +- docs/docs/user-setup.mdx | 4 ++-- 26 files changed, 63 insertions(+), 57 deletions(-) diff --git a/docs/docs/behaviors/caps-word.md b/docs/docs/behaviors/caps-word.md index 4551884dd50..c79ebae01a6 100644 --- a/docs/docs/behaviors/caps-word.md +++ b/docs/docs/behaviors/caps-word.md @@ -21,7 +21,7 @@ Example: ### Configuration -#### Continue List +#### Continue list By default, the caps word will remain active when any alphanumeric character or underscore (`UNDERSCORE`), backspace (`BACKSPACE`), or delete (`DELETE`) characters are pressed. Any other non-modifier keycode sent will turn off caps word. If you would like to override this, you can set a new array of keys in the `continue-list` property in your keymap: @@ -37,7 +37,7 @@ By default, the caps word will remain active when any alphanumeric character or }; ``` -#### Applied Modifier(s) +#### Applied modifier(s) In addition, if you would like _multiple_ modifiers, instead of just `MOD_LSFT`, you can override the `mods` property: diff --git a/docs/docs/behaviors/hold-tap.mdx b/docs/docs/behaviors/hold-tap.mdx index 5217cf79e29..20aaf810a8c 100644 --- a/docs/docs/behaviors/hold-tap.mdx +++ b/docs/docs/behaviors/hold-tap.mdx @@ -35,7 +35,7 @@ When the hold-tap key is released and the hold behavior has not been triggered, ![Hold-tap comparison](../assets/hold-tap/comparison.svg) -### Basic usage +### Basic Usage For basic usage, please see the [mod-tap](mod-tap.md) and [layer-tap](layers.md#layer-tap) pages. diff --git a/docs/docs/behaviors/index.mdx b/docs/docs/behaviors/index.mdx index 7cd82d3e4b8..bdacc209ad7 100644 --- a/docs/docs/behaviors/index.mdx +++ b/docs/docs/behaviors/index.mdx @@ -9,7 +9,7 @@ sidebar_label: Overview Below is a summary of pre-defined behavior bindings and user-definable behaviors available in ZMK, with references to documentation pages describing them. -## Key press behaviors +## Key Press Behaviors | Binding | Behavior | Description | | ------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -21,14 +21,14 @@ Below is a summary of pre-defined behavior bindings and user-definable behaviors | `&caps_word` | [Caps Word](caps-word.md) | Behaves similar to caps lock, but automatically deactivates when any key not in a continue list is pressed, or if the caps word key is pressed again | | `&key_repeat` | [Key Repeat](key-repeat.md) | Sends again whatever keycode was last sent | -## Miscellaneous behaviors +## Miscellaneous Behaviors | Binding | Behavior | Description | | -------- | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | `&trans` | [Transparent](misc.md#transparent) | Passes the key press down to the next active layer in the stack for processing | | `&none` | [None](misc.md#none) | Swallows and stops the key press, no keycode will be sent nor will the key press be passed down to the next active layer in the stack | -## Layer navigation behaviors +## Layer Navigation Behaviors | Binding | Behavior | Description | | ------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------- | @@ -38,41 +38,41 @@ Below is a summary of pre-defined behavior bindings and user-definable behaviors | `&tog` | [Toggle Layer](layers.md#toggle-layer) | Enables a layer until the layer is manually disabled | | `&sl` | [Sticky Layer](sticky-layer.md) | Activates a layer until another key is pressed, then deactivates it | -## Mouse emulation behaviors +## Mouse Emulation Behaviors | Binding | Behavior | Description | | ------- | ----------------------------------------------------------- | ------------------------------- | | `&mkp` | [Mouse Button Press](mouse-emulation.md#mouse-button-press) | Emulates pressing mouse buttons | -## Reset behaviors +## Reset Behaviors | Binding | Behavior | Description | | ------------- | --------------------------------------- | ---------------------------------------------------------------------------------------- | | `&sys_reset` | [Reset](reset.md#reset) | Resets the keyboard and re-runs the firmware flashed to the device | | `&bootloader` | [Bootloader](reset.md#bootloader-reset) | Resets the keyboard and puts it into bootloader mode, allowing you to flash new firmware | -## Output selection behaviors +## Output Selection Behaviors | Binding | Behavior | Description | | ------- | -------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | `&bt` | [Bluetooth](bluetooth.md#bluetooth-behavior) | Completes a bluetooth action given on press, for example switching between devices | | `&out` | [Output Selection](outputs.md#output-selection-behavior) | Allows selecting whether output is sent to the USB or bluetooth connection when both are connected | -## Lighting behaviors +## Lighting Behaviors | Binding | Behavior | Description | | --------- | ---------------------------------------------- | ---------------------------------------------------------------------------- | | `&rgb_ug` | [RGB Underglow](underglow.md#behavior-binding) | Controls the RGB underglow, usually placed underneath the keyboard | | `&bl` | [Backlight](backlight.md#behavior-binding) | Controls the keyboard backlighting, usually placed through or under switches | -## Power management behaviors +## Power Management Behaviors | Binding | Behavior | Description | | ------------ | --------------------------------------------- | --------------------------------------------------------------- | | `&ext_power` | [Power management](power.md#behavior-binding) | Allows enabling or disabling the VCC power output to save power | | `&soft_off` | [Soft off](soft-off.md#behavior-binding) | Turns the keyboard off. | -## User-defined behaviors +## User-Defined Behaviors | Behavior | Description | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | diff --git a/docs/docs/behaviors/key-repeat.md b/docs/docs/behaviors/key-repeat.md index 9772fdb4e0a..2187008417a 100644 --- a/docs/docs/behaviors/key-repeat.md +++ b/docs/docs/behaviors/key-repeat.md @@ -19,7 +19,7 @@ Example: ### Configuration -#### Usage Pages +#### Usage pages By default, the key repeat will only track the last pressed key from the HID "Key" usage page, and ignore events from other usages, e.g. Consumer page. diff --git a/docs/docs/behaviors/layers.md b/docs/docs/behaviors/layers.md index 7cfb4df7e00..511fbe08b7a 100644 --- a/docs/docs/behaviors/layers.md +++ b/docs/docs/behaviors/layers.md @@ -8,7 +8,7 @@ sidebar_label: Layers Often, you may want a certain key position to alter which layers are enabled, change the default layer, etc. Some of those behaviors are still in the works; the ones that are working now are documented here. -## Defines To Refer To Layers +## Defines to Refer to Layers When working with layers, you may have several different key positions with bindings that enable/disable those layers. To make it easier to refer to those layers in your key bindings, and to change which layers are where later, you can @@ -41,7 +41,7 @@ Example: &mo LOWER ``` -## Layer-tap +## Layer-Tap The "layer-tap" behavior enables a layer when a key is held, and outputs a [keypress](key-press.md) when the key is only tapped for a short time. diff --git a/docs/docs/behaviors/macros.md b/docs/docs/behaviors/macros.md index 37ca80ffbb5..50c8945eb80 100644 --- a/docs/docs/behaviors/macros.md +++ b/docs/docs/behaviors/macros.md @@ -223,7 +223,7 @@ Common examples are enabling one or more modifiers when the layer is active, or To achieve this, a combination of a 0ms wait time and splitting the press and release between a `¯o_pause_for_release` is used: -#### Layer + Modifier +#### Layer + modifier ```dts /** @@ -256,7 +256,7 @@ lm: lm { }; ``` -#### Layer + Underglow Color +#### Layer + underglow color To trigger a different underglow when the macro is pressed, and when it is released, we use the macro "press" activation mode whenever triggering the `&rgb_ug` behavior: diff --git a/docs/docs/behaviors/mod-morph.md b/docs/docs/behaviors/mod-morph.md index 7ecb9ab8983..8949ec2c788 100644 --- a/docs/docs/behaviors/mod-morph.md +++ b/docs/docs/behaviors/mod-morph.md @@ -65,7 +65,7 @@ Example: mods = <(MOD_LGUI|MOD_LSFT|MOD_RGUI|MOD_RSFT)>; ``` -### Advanced configuration +### Advanced Configuration `keep-mods` diff --git a/docs/docs/behaviors/soft-off.md b/docs/docs/behaviors/soft-off.md index 14b5f36aee7..086b5d75d75 100644 --- a/docs/docs/behaviors/soft-off.md +++ b/docs/docs/behaviors/soft-off.md @@ -23,7 +23,7 @@ Example: ### Configuration -#### Hold Time +#### Hold time By default, the keyboard will be turned off as soon as the key bound to the behavior is released, even if the key is only tapped briefly. If you would prefer that the key need be held a certain amount of time before releasing, you can set the `hold-time-ms` to a non-zero value in your keymap: diff --git a/docs/docs/behaviors/sticky-key.md b/docs/docs/behaviors/sticky-key.md index 8c3962f5450..30345882a66 100644 --- a/docs/docs/behaviors/sticky-key.md +++ b/docs/docs/behaviors/sticky-key.md @@ -81,7 +81,7 @@ This configuration would apply to all sticky keys. This may not be appropriate i }; ``` -### Advanced usage +### Advanced Usage Sticky keys can be combined; if you tap `&sk LCTRL` and then `&sk LSHIFT` and then `&kp A`, the output will be ctrl+shift+a. diff --git a/docs/docs/behaviors/sticky-layer.md b/docs/docs/behaviors/sticky-layer.md index 41c2ccf55d7..6a231f08995 100644 --- a/docs/docs/behaviors/sticky-layer.md +++ b/docs/docs/behaviors/sticky-layer.md @@ -36,7 +36,7 @@ You can configure a different `release-after-ms` in your keymap: }; ``` -### Advanced usage +### Advanced Usage Sticky layers behave slightly different from sticky keys. They are configured to `quick-release`. This means that the layer is released immediately when another key is pressed. "Normal" sticky keys are not `quick-release`; they are released when the next key is released. This makes it possible to combine sticky layers and sticky keys as such: tap `&sl 1`, tap `&sk LSHIFT` on layer 1, tap `&kp A` on base layer to output shift+A. diff --git a/docs/docs/config/battery.md b/docs/docs/config/battery.md index c95e78841e8..4596395b806 100644 --- a/docs/docs/config/battery.md +++ b/docs/docs/config/battery.md @@ -28,7 +28,7 @@ On macOS the BLE battery reporting packets can cause the computer to wakeup from ::: -### Peripheral battery monitoring +### Peripheral Battery Monitoring You can [configure ZMK to allow support for peripheral battery monitoring over BLE](system.md#split-keyboards) (e.g. when having a split keyboard with two independent and wirelessly connected sides). If you want to report the battery levels of both sides of a split keyboard, you should have both `CONFIG_ZMK_SPLIT_BLE_CENTRAL_BATTERY_LEVEL_PROXY` and `CONFIG_ZMK_SPLIT_BLE_CENTRAL_BATTERY_LEVEL_FETCHING` set to `y`. diff --git a/docs/docs/config/encoders.md b/docs/docs/config/encoders.md index b242f49b5ba..c8966846efb 100644 --- a/docs/docs/config/encoders.md +++ b/docs/docs/config/encoders.md @@ -29,7 +29,7 @@ If `CONFIG_EC11` is enabled, exactly one of the following options must be set to ### Devicetree -#### Keymap Sensor Config +#### Keymap sensor config For shields/boards that export a `sensors` node configuration label, both global and per-sensor settings can be set by overriding the properties there. @@ -69,7 +69,7 @@ Definition file: [zmk/app/drivers/zephyr/dts/bindings/zmk,keymap-sensors.yaml](h | ----------------------- | ---- | --------------------------------------------------------------- | ------- | | `triggers-per-rotation` | int | Number of times to trigger the bound behavior per full rotation | | -#### EC11 Nodes +#### EC11 nodes Applies to: `compatible = "alps,ec11"` diff --git a/docs/docs/development/build-flash.mdx b/docs/docs/development/build-flash.mdx index 2cbcf5b82ef..20e9e20a34c 100644 --- a/docs/docs/development/build-flash.mdx +++ b/docs/docs/development/build-flash.mdx @@ -77,7 +77,7 @@ This produces `left` and `right` subfolders under the `build` directory and two Build times can be significantly reduced after the initial build by omitting all build arguments except the build directory, e.g. `west build -d build/left`. The additional options and intermediate build outputs from your initial build are cached and reused for unchanged files. ::: -### Building with external modules +### Building With External Modules ZMK supports loading additional boards, shields, code, etc. from [external Zephyr modules](https://docs.zephyrproject.org/3.5.0/develop/modules.html), facilitating out-of-tree management and versioning independent of the ZMK repository. To build with any additional modules, use the `ZMK_EXTRA_MODULES` define added to your `west build` command. diff --git a/docs/docs/development/documentation.md b/docs/docs/development/documentation.md index 56c4d27699b..169642ba714 100644 --- a/docs/docs/development/documentation.md +++ b/docs/docs/development/documentation.md @@ -5,7 +5,7 @@ sidebar_label: Documentation This document outlines how to test your documentation changes locally and prepare the changes for a pull request. -The documentation is written with [Docusaurus](https://docusaurus.io/). The ZMK source code has all of the necessary Docusaurus dependencies included but referencing their documentation can be helpful at times. +The documentation is written with [Docusaurus](https://docusaurus.io/). The ZMK source code has all of the necessary Docusaurus dependencies included, but referencing their documentation can be helpful at times. The general process for updating the ZMK documentation is: @@ -52,6 +52,12 @@ The check commands can be run with the following procedure in a terminal that's If any of the above steps throw an error, they need to be addressed and all of the checks re-run prior to submitting a pull request. ::: +:::note +The documentation uses American English spelling and grammar conventions. Title case is used for the first three heading levels, with sentence case used beyond that. + +Please make sure your changes conform to these conventions - prettier and lint are unfortunately unable to do this automatically. +::: + ## Submitting a Pull Request Once the above sections are complete the documentation updates are ready to submit as a pull request. diff --git a/docs/docs/development/ide-integration.mdx b/docs/docs/development/ide-integration.mdx index 87a5a4caf55..cee12f4b3bf 100644 --- a/docs/docs/development/ide-integration.mdx +++ b/docs/docs/development/ide-integration.mdx @@ -51,7 +51,7 @@ Change these options: If you are developing inside a Docker container, set the IntelliSense mode to `linux-gcc-arm` regardless of the host operating system. -#### Compiler Path +#### Compiler path Open VS Code's integrated terminal and run the following command: @@ -79,7 +79,7 @@ If you are building for an platform other than ARM, replace `/arm-zephyr-eabi/bi /home/marvin/.local/zephyr-sdk-0.15.2/riscv64-zephyr-elf/bin/riscv64-zephyr-elf-gcc ``` -#### Compiler Commands Path +#### Compiler commands path When building with all default options, the path to the compilation database file is `${workspaceFolder}/app/build/compile_commands.json` as shown in the table above, diff --git a/docs/docs/development/new-behavior.mdx b/docs/docs/development/new-behavior.mdx index 914abf52063..dca19288dc0 100644 --- a/docs/docs/development/new-behavior.mdx +++ b/docs/docs/development/new-behavior.mdx @@ -35,7 +35,7 @@ The following resources are provided for those seeking further understanding: ## Creating the Behavior -### Creating the devicetree binding (`.yaml`) +### Creating the Devicetree Binding (`.yaml`) The properties of the behavior are listed in the behavior's devicetree binding, which comes in the form of a `.yaml` file. Devicetree bindings are stored in the directory `app/dts/bindings/behaviors/` and are labelled in lowercase, beginning with the prefix `zmk,behavior-`, and ending with the behavior's name, using dashes to separate multiple words. For example, the directory for the hold-tap's devicetree binding would be located at `app/dts/bindings/behaviors/zmk,behavior-hold-tap.yaml`, which is shown below as a reference: @@ -119,7 +119,7 @@ These are additional variables required to configure a particular instance of a For more information on additional `properties`, refer to [Zephyr's documentation on Devicetree bindings](https://docs.zephyrproject.org/3.5.0/build/dts/bindings-syntax.html#properties). ::: -### Creating the driver (`.c`) +### Creating the Driver (`.c`) :::info Developing drivers for behaviors in ZMK makes extensive use of the Zephyr Devicetree API and Device Driver Model. Links to the Zephyr Project Documentation for both of these concepts can be found below: @@ -203,7 +203,7 @@ The dependencies required for any ZMK behavior are: Other common dependencies include `zmk/keymap.h`, which allows behaviors to access layer information and extract behavior bindings from keymaps, and `zmk/event_manager.h` which is detailed below. -##### ZMK Event Manager +##### ZMK event manager Including `zmk/event_manager.h` is required for the following dependencies to function properly. @@ -213,7 +213,7 @@ Including `zmk/event_manager.h` is required for the following dependencies to fu Events can be used similarly to hardware interrupts, through the use of [listeners](#listeners-and-subscriptions). -###### Listeners and Subscriptions +###### Listeners and subscriptions The condensed form of lines 192-225 of the tap-dance driver, shown below, does an excellent job of showcasing the function of listeners and subscriptions with respect to the [ZMK Event Manager](#zmk-event-manager). @@ -279,11 +279,11 @@ Note that in the hold-tap example, the instance number, `0`, has been replaced b Behaviors also require the following parameters of `BEHAVIOR_DT_INST_DEFINE` to be changed: -##### Initialization Function +##### Initialization function Comes in the form `static int _init(const struct device *dev)`. Initialization functions preconfigure any data, like resetting timers and position for hold-taps and tap-dances. All initialization functions `return 0;` once complete. -##### API Structure +##### API structure Comes in the form `static const struct behavior_driver_api _driver_api)`. Common items to include in the API Structure are: @@ -297,7 +297,7 @@ Comes in the form `static const struct behavior_driver_api _drive For unibody keyboards, all locality values perform the same as `BEHAVIOR_LOCALITY_GLOBAL`. ::: -##### Data Pointers (Optional) +##### Data pointers (optional) The data `struct` stores additional data required for **each new instance** of the behavior. Regardless of the instance number, `n`, `behavior__data_##n` is typically initialized as an empty `struct`. The data respective to each instance of the behavior can be accessed in functions like [`on__binding_pressed(struct zmk_behavior_binding *binding, struct zmk_behavior_binding_event event)`](#dependencies) by extracting the behavior device from the keybind like so: @@ -310,7 +310,7 @@ The variables stored inside the data `struct`, `data`, can be then modified as n The fourth cell of `BEHAVIOR_DT_INST_DEFINE` can be set to `NULL` instead if instance-specific data is not required. -##### Configuration Pointers (Optional) +##### Configuration pointers (optional) The configuration `struct` stores the properties declared from the behavior's `.yaml` for **each new instance** of the behavior. As seen in the `#define KP_INST(n)` of the hold-tap example, the configuration `struct`, `behavior__config_##n`, for each instance number, `n`, can be initialized using the [Zephyr Devicetree Instance-based APIs](https://docs.zephyrproject.org/3.5.0/build/dts/api/api.html#instance-based-apis), which extract the values from the `properties` of each instance of the [devicetree binding](#creating-the-devicetree-binding-yaml) from a user's keymap or [predefined use-case `.dtsi` files](#defining-common-use-cases-for-the-behavior-dtsi-optional) stored in `app/dts/behaviors/`. We illustrate this further by comparing the [`#define KP_INST(n)` from the hold-tap driver](#behavior_dt_inst_define) and the [`properties` of the hold-tap devicetree binding.](#creating-the-devicetree-binding-yaml) @@ -320,7 +320,7 @@ The fifth cell of `BEHAVIOR_DT_INST_DEFINE` can be set to `NULL` instead if inst Remember that `.c` files should be formatted according to `clang-format` to ensure that checks run smoothly once the pull request is submitted. ::: -### Updating `app/CmakeLists.txt` to include the new driver +### Updating `app/CmakeLists.txt` to Include the New Driver Most behavior drivers' are invoked according to the central half's [locality](#api-structure), and are therefore stored after the line `if ((NOT CONFIG_ZMK_SPLIT) OR CONFIG_ZMK_SPLIT_ROLE_CENTRAL)` in the form, `target_sources(app PRIVATE src/behaviors/.c)`, as shown below. @@ -353,7 +353,7 @@ For behaviors that do not require central locality, the following options for up - Behavior applies to _only_ peripheral half of split keyboard: place `target_sources(app PRIVATE .c)` after `if (CONFIG_ZMK_SPLIT AND (NOT CONFIG_ZMK_SPLIT_ROLE_CENTRAL))` - Behavior requires certain condition in a keyboard's `.conf` file to be met: use `target_sources_ifdef(CONFIG_ app PRIVATE .c)` instead of `target_sources(.c)` -### Defining common use-cases for the behavior (`.dtsi`) (Optional) +### Defining Common Use-Cases for the Behavior (`.dtsi`) (Optional) `.dtsi` files, found in the directory `app/dts/behaviors/`, are only necessary for behaviors with more common use-cases. A common example is the mod-tap (`&mt`), which is a predefined type of hold-tap that takes a modifier key as the hold parameter and another key as the tap parameter. @@ -422,7 +422,7 @@ After creating the `.dtsi` from above, update `app/dts/behaviors.dtsi` to includ #include ``` -## Testing changes locally +## Testing Changes Locally Create a new folder in `app/tests/` to develop virtual test sets for all common use cases of the behavior. Behaviors should be tested thoroughly on both virtual testing environments using `west test` and real hardware. @@ -437,7 +437,7 @@ Zephyr currently does not support logging over Bluetooth, so any use of the seri ::: -## Documenting behavior functionality +## Documenting Behavior Functionality Consider the following prompts when writing documentation for new behaviors: @@ -453,7 +453,7 @@ Consider also including visual aids alongside written documentation if it adds c See [Documentation](documentation.md) for more information on writing, testing, and formatting ZMK documentation. ::: -## Submitting a pull request +## Submitting a Pull Request Once the above sections are complete, the behavior is almost ready to submit as a pull request. New [devicetree bindings](#creating-the-devicetree-binding-yaml), new [drivers](#creating-the-driver-c), and [predefined use-cases](#defining-common-use-cases-for-the-behavior-dtsi-optional) of the new behavior must contain the appropriate copyright headers, which can be copied and pasted from the tabs below. diff --git a/docs/docs/development/setup/native.mdx b/docs/docs/development/setup/native.mdx index d077d7d1d7d..40c1bbed6ee 100644 --- a/docs/docs/development/setup/native.mdx +++ b/docs/docs/development/setup/native.mdx @@ -319,7 +319,7 @@ pip3 install -r zephyr/scripts/requirements-base.txt Return to Zephyr's Getting Started Guide and [Install Zephyr SDK](https://docs.zephyrproject.org/3.5.0/develop/getting_started/index.html#install-zephyr-sdk). -### OS specific notes +### OS-Specific Notes @@ -330,7 +330,7 @@ Return to Zephyr's Getting Started Guide and [Install Zephyr SDK](https://docs.z -#### Install Cross-Compile Toolchain +#### Install cross-compile toolchain Because Raspberry OS runs on the same architecture (but different ABI) as ARM keyboard MCUs, the operating system's installed [cross compilers](https://docs.zephyrproject.org/3.5.0/develop/toolchains/other_x_compilers.html) can be used to target the different ABI. Building for non-ARM MCUs has not been tested. diff --git a/docs/docs/features/backlight.mdx b/docs/docs/features/backlight.mdx index 674e8633014..5debc375010 100644 --- a/docs/docs/features/backlight.mdx +++ b/docs/docs/features/backlight.mdx @@ -34,7 +34,7 @@ There are various Kconfig options used to configure the backlight feature. These | `CONFIG_ZMK_BACKLIGHT_AUTO_OFF_IDLE` | Turn off backlight when keyboard goes into idle state | n | | `CONFIG_ZMK_BACKLIGHT_AUTO_OFF_USB` | Turn off backlight when USB is disconnected | n | -## Adding Backlight to a board or a shield +## Adding Backlight to a Board or a Shield -### Multiple backlight LEDs +### Multiple Backlight LEDs It is possible to control multiple backlight LEDs at the same time. This is useful if, for example, you have a Caps Lock LED connected to a different pin and you want it to be part of the backlight. diff --git a/docs/docs/features/beta-testing.mdx b/docs/docs/features/beta-testing.mdx index 148005cea67..1a8d28633cb 100644 --- a/docs/docs/features/beta-testing.mdx +++ b/docs/docs/features/beta-testing.mdx @@ -28,7 +28,7 @@ branch and create the pull request. ![Repository URL](../assets/features/beta-testing/repo-branch.png) -## Testing features +## Testing Features Testing features will require you to modify the `west.yml` file. You will need to add a new remote for the pull request you would like to test, and change the selected remote and revision (or branch) for the `zmk` project. diff --git a/docs/docs/features/combos.md b/docs/docs/features/combos.md index 32f09c1c61e..63c57c38cc3 100644 --- a/docs/docs/features/combos.md +++ b/docs/docs/features/combos.md @@ -38,7 +38,7 @@ Key positions are numbered like the keys in your keymap, starting at 0. So, if t ::: -### Advanced usage +### Advanced Usage - Partially overlapping combos like `0 1` and `0 2` are supported. - Fully overlapping combos like `0 1` and `0 1 2` are supported. diff --git a/docs/docs/features/debouncing.md b/docs/docs/features/debouncing.md index 7d194efa061..31e00843211 100644 --- a/docs/docs/features/debouncing.md +++ b/docs/docs/features/debouncing.md @@ -40,7 +40,7 @@ CONFIG_ZMK_KSCAN_DEBOUNCE_PRESS_MS=3 CONFIG_ZMK_KSCAN_DEBOUNCE_RELEASE_MS=3 ``` -### Per-driver Options +### Per-Driver Options You can add these Devicetree properties to a kscan node to control debouncing for that instance of the driver. Values must be `<= 16383`. diff --git a/docs/docs/features/keymaps.mdx b/docs/docs/features/keymaps.mdx index 105ca794ab4..95df3e86842 100644 --- a/docs/docs/features/keymaps.mdx +++ b/docs/docs/features/keymaps.mdx @@ -96,7 +96,7 @@ The first defines the nodes for all the available behaviors in ZMK, which will b The second include brings in the defines for all the keycodes (e.g. `A`, `N1`, `C_PLAY`) and the modifiers (e.g. `LSHIFT`) used for various behavior bindings. -### Root devicetree Node +### Root Devicetree Node All the remaining keymap nodes will be nested inside of the root devicetree node, like so: diff --git a/docs/docs/features/soft-off.md b/docs/docs/features/soft-off.md index bd631f1b42e..7018afa08f2 100644 --- a/docs/docs/features/soft-off.md +++ b/docs/docs/features/soft-off.md @@ -101,7 +101,7 @@ To use the [soft off behavior](../behaviors/soft-off.md) outside of a keymap, ad The kscan sideband behavior driver will be used to trigger the [soft off behavior](../behaviors/soft-off.md) "out of band" from the normal keymap processing. To do so, it will decorate/wrap an underlying kscan driver. What kscan driver will vary for simple direct pin vs. matrix-integrated hardware combo. -#### Simple Direct Pin +#### Simple direct pin With a simple direct pin setup, the The [direct kscan](../config/kscan.md) driver can be used with a GPIO key, to make a small "side matrix": @@ -148,7 +148,7 @@ Here are the properties for the node: - The `compatible` property for the node must be `zmk,soft-off-wakeup-sources`. - The `wakeup-sources` property is a [phandle array](../config/index.md#devicetree-property-types) pointing to all the devices that should be enabled during the shutdown process to be sure they can later wake the keyboard. -#### Matrix-Integrated Hardware Combo +#### Matrix-integrated hardware combo For this case, you will supplement the existing kscan matrix, by adding the additional pin as another entry in the `row-gpios`/`col-gpios` for whichever pins are used to read the matrix state. For example, for an existing matrix like: diff --git a/docs/docs/features/underglow.md b/docs/docs/features/underglow.md index a32306caa0d..ba6c0092340 100644 --- a/docs/docs/features/underglow.md +++ b/docs/docs/features/underglow.md @@ -39,7 +39,7 @@ use Kconfig. 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). -### Modifying the number of LEDs +### Modifying the Number of LEDs A common issue when enabling underglow is that some of the installed LEDs do not illuminate. This can happen when a board's default underglow configuration accounts only for either the downward facing LEDs or the upward facing LEDs under each key. On a split keyboard, a good sign that this may be the problem is that the unilluminated LEDs on each half are symmetrical. @@ -64,7 +64,7 @@ If you have a shield with RGB underglow, you must add a `boards/` directory with Inside the `boards/` folder, you define a `.overlay` for each different board. For example, the Kyria shield has a `boards/nice_nano.overlay` file that defines the RGB underglow for the `nice_nano` board specifically. -### nRF52-based boards +### nRF52-Based Boards With nRF52 boards, you can just use `&spi3` and define the pins you want to use. @@ -128,7 +128,7 @@ If your board/shield uses LEDs that require the data sent in a different order, ::: -### Other boards +### Other Boards For other boards, you must select an SPI definition that has the `MOSI` pin as your data pin going to your LED strip. diff --git a/docs/docs/intro.md b/docs/docs/intro.md index da01e8297e7..e11eda71f02 100644 --- a/docs/docs/intro.md +++ b/docs/docs/intro.md @@ -46,7 +46,7 @@ ZMK is currently missing some features found in other popular firmware. This tab [^2]: Tap-Dances are limited to single and double-tap on BlueMicro [^1]: OLEDs are currently proof of concept in ZMK. -## Code Of Conduct +## Code of Conduct Please note that this project is released with a [Contributor Code of Conduct](https://www.contributor-covenant.org/version/2/0/code_of_conduct/). diff --git a/docs/docs/user-setup.mdx b/docs/docs/user-setup.mdx index 78d4362857e..f6cb5eb2717 100644 --- a/docs/docs/user-setup.mdx +++ b/docs/docs/user-setup.mdx @@ -177,9 +177,9 @@ push the initial commit. ::: -## Installing The Firmware +## Installing the Firmware -### Download The Archive +### Download the Archive Once the setup script is complete and the new user config repository has been pushed, GitHub will automatically run the action to build your keyboard firmware files. You can view the actions by clicking on the "Actions" tab on your GitHub repository.