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.