mirror of
https://github.com/zmkfirmware/zmk.git
synced 2026-03-19 20:45:18 -05:00
Compare commits
3 Commits
docs/prede
...
dependabot
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
079894e4fa | ||
|
|
75c9d5f6fd | ||
|
|
e742da8e47 |
@@ -1,22 +0,0 @@
|
||||
/*
|
||||
* Copyright (c) 2025 The ZMK Contributors
|
||||
*
|
||||
* SPDX-License-Identifier: MIT
|
||||
*/
|
||||
|
||||
#include <dt-bindings/zmk/behaviors.h>
|
||||
|
||||
/ {
|
||||
macros {
|
||||
#if ZMK_BEHAVIOR_OMIT(KTAP)
|
||||
/omit-if-no-ref/
|
||||
#endif
|
||||
ktap: key_tap {
|
||||
compatible = "zmk,behavior-macro-one-param";
|
||||
#binding-cells = <1>;
|
||||
display-name = "Key Tap";
|
||||
bindings = <¯o_param_1to1>, <&kp MACRO_PLACEHOLDER>;
|
||||
tap-ms = <30>;
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -16,25 +16,5 @@
|
||||
#binding-cells = <1>;
|
||||
display-name = "Key Toggle";
|
||||
};
|
||||
|
||||
#if ZMK_BEHAVIOR_OMIT(KT_ON)
|
||||
/omit-if-no-ref/
|
||||
#endif
|
||||
kt_on: key_toggle_on {
|
||||
compatible = "zmk,behavior-key-toggle";
|
||||
#binding-cells = <1>;
|
||||
display-name = "Key Toggle On";
|
||||
toggle-mode = "on";
|
||||
};
|
||||
|
||||
#if ZMK_BEHAVIOR_OMIT(KT_OFF)
|
||||
/omit-if-no-ref/
|
||||
#endif
|
||||
kt_off: key_toggle_off {
|
||||
compatible = "zmk,behavior-key-toggle";
|
||||
#binding-cells = <1>;
|
||||
display-name = "Key Toggle Off";
|
||||
toggle-mode = "off";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
@@ -17,25 +17,5 @@
|
||||
display-name = "Toggle Layer";
|
||||
locking;
|
||||
};
|
||||
|
||||
#if ZMK_BEHAVIOR_OMIT(TOG_ON)
|
||||
/omit-if-no-ref/
|
||||
#endif
|
||||
tog_on: toggle_layer_on {
|
||||
compatible = "zmk,behavior-toggle-layer";
|
||||
#binding-cells = <1>;
|
||||
display-name = "Toggle Layer On";
|
||||
toggle-mode = "on";
|
||||
};
|
||||
|
||||
#if ZMK_BEHAVIOR_OMIT(TOG_OFF)
|
||||
/omit-if-no-ref/
|
||||
#endif
|
||||
tog_off: toggle_layer_off {
|
||||
compatible = "zmk,behavior-toggle-layer";
|
||||
#binding-cells = <1>;
|
||||
display-name = "Toggle Layer Off";
|
||||
toggle-mode = "off";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
@@ -3,6 +3,16 @@
|
||||
#include <dt-bindings/zmk/kscan_mock.h>
|
||||
|
||||
/ {
|
||||
behaviors {
|
||||
tog_off: toggle_layer_off_only {
|
||||
compatible = "zmk,behavior-toggle-layer";
|
||||
#binding-cells = <1>;
|
||||
display-name = "Toggle Layer Off";
|
||||
toggle-mode = "off";
|
||||
locking;
|
||||
};
|
||||
};
|
||||
|
||||
keymap {
|
||||
compatible = "zmk,keymap";
|
||||
|
||||
|
||||
@@ -111,7 +111,7 @@ And other miscellaneous ones:
|
||||
- A `<keyboard_name>.zmk.yml` file containing [metadata](hardware-metadata-files.md) for the keyboard.
|
||||
|
||||
See Zephyr's [board porting guide](https://docs.zephyrproject.org/4.1.0/hardware/porting/board_porting.html) for information on creating a new board.
|
||||
Also see the [new keyboard shield guide](new-shield.mdx#shield-overlays) for information on parts of the devicetree specifically related to ZMK.
|
||||
See also our [new board guide](new-board.md) for information on creating a ZMK-compatible board variant.
|
||||
|
||||
[^1]:
|
||||
Parts of these files can live in separate `.dtsi` files (typically in the same directory) that are then `#include`d in the files, to reduce duplication or improve organization.
|
||||
|
||||
187
docs/docs/development/hardware-integration/new-board.md
Normal file
187
docs/docs/development/hardware-integration/new-board.md
Normal file
@@ -0,0 +1,187 @@
|
||||
---
|
||||
title: New Board
|
||||
---
|
||||
|
||||
This guide will walk through the necessary steps to write a [board](./index.mdx#boards--shields) suitable for use with ZMK. Boards used with ZMK fall into two categories:
|
||||
|
||||
- Boards with interconnects, such as `nice_nano` or `seeed_xiao`. Such boards will (active development of ZMK aside) always be used with a shield to create a keyboard.
|
||||
- Boards that are themselves keyboards, such as `bt75` or `ferris`.
|
||||
|
||||
Some keyboards are boards but also have interconnects for modular add-ons. These are considered as keyboard-boards for the purpose of this guide. Details on adding an interconnect for modular add-ons are considered out of scope.
|
||||
|
||||
## Boards Included in ZMK
|
||||
|
||||
Boards with interconnects can be considered for inclusion to the tree of ZMK. If this is your aim, it is vital that you read through our [clean room policy](../contributing/clean-room.md).
|
||||
|
||||
Boards with interconnects that are included with ZMK are generally:
|
||||
|
||||
- Reliably commercially available as individual units
|
||||
- In regular use across multiple shields (i.e. not niche)
|
||||
|
||||
Popular open source designs which are not being sold can also be considered for inclusion.
|
||||
|
||||
There also exist many boards in the tree of upstream Zephyr. We generally accept ZMK-variants of these boards into our tree as well.
|
||||
|
||||
## New ZMK Module Repository
|
||||
|
||||
Regardless of whether you aim to include the board in ZMK or not, you should first write the definition for it in a module. A new ZMK module repository can be created from a template.
|
||||
|
||||
:::note
|
||||
This guide assumes you already have a configured GitHub account. If you don't yet have one, go ahead and [sign up](https://github.com/join) before continuing.
|
||||
:::
|
||||
|
||||
Follow these steps to create your new repository:
|
||||
|
||||
- Visit https://github.com/zmkfirmware/unified-zmk-config-template
|
||||
- Click the green "Use this template" button
|
||||
- In the drop down that opens, click "Use this template".
|
||||
- In the following screen, provide the following information:
|
||||
- A repository name, e.g. `my-board-module`.
|
||||
- A brief description, e.g. `ZMK Support For MyBoard`.
|
||||
- Select Public or Private, depending on your preference.
|
||||
- Click the green "Create repository" button
|
||||
|
||||
The repository is a combination of the directories and files required of a ZMK config, and those required of a shield module.
|
||||
This enables the use of GitHub Actions to test that the shield is defined correctly.
|
||||
See also the page on [module creation](../module-creation.md) for a reference on exactly which file structure and files are required for a ZMK keyboard module.
|
||||
|
||||
We recommend that you take this moment to name your module according to our [convention](../module-creation.md), i.e. your `zephyr/module.yml` file should begin with
|
||||
|
||||
```yaml title="zephyr/module.yml"
|
||||
name: zmk-keyboard-<keyboard_name>
|
||||
```
|
||||
|
||||
if it is a keyboard, or
|
||||
|
||||
```yaml title="zephyr/module.yml"
|
||||
name: zmk-component-<board_name>
|
||||
```
|
||||
|
||||
if it is a board with an interconnect.
|
||||
|
||||
## Write a Zephyr Board Definition
|
||||
|
||||
Zephyr has a guide on writing a board [here](https://docs.zephyrproject.org/4.1.0/hardware/porting/board_porting.html). Follow this guide to create a Zephyr-compatible board. Use the `boards` folder of your ZMK module as a base.
|
||||
|
||||
Once your board definition has been written, we recommend flashing some [Zephyr samples](https://docs.zephyrproject.org/4.1.0/samples/basic/basic.html) to it, to verify that it is working.
|
||||
|
||||
Flashing Zephyr samples can also be very helpful when troubleshooting/testing the functionality of extra features such as LED ICs, Bluetooth, or various sensor ICs.
|
||||
|
||||
## Write a ZMK Variant of Zephyr Board
|
||||
|
||||
To make a board fully compatible with ZMK, you will be creating a ZMK variant of the Zephyr board you made in the previous step. Perform the below actions for each board you've defined, in the case of multi-board split keyboards.
|
||||
|
||||
### Add Variant to board.yml
|
||||
|
||||
Edit your existing `board.yml` file to add the variant:
|
||||
|
||||
```yaml title="board.yml"
|
||||
board:
|
||||
...
|
||||
socs:
|
||||
- name: <soc-1>
|
||||
variants:
|
||||
- name: zmk
|
||||
```
|
||||
|
||||
### Add Kconfig for ZMK Variant
|
||||
|
||||
Add a file to your board's folder called `<your-board>_zmk_defconfig`. This file will be used to set Kconfig flags specific to the ZMK variant.
|
||||
|
||||
:::warning
|
||||
Make sure you know what each Kconfig flag does before you enable it. Some flags may be incompatible with certain hardware, or have other adverse effects.
|
||||
:::
|
||||
|
||||
These flags are typically a subset of the following:
|
||||
|
||||
```yaml title="<your-board>_zmk_defconfig"
|
||||
# SPDX-License-Identifier: <your license>
|
||||
|
||||
# Enable MPU
|
||||
CONFIG_ARM_MPU=y
|
||||
|
||||
CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=125000000
|
||||
|
||||
# Enable reset by default
|
||||
CONFIG_RESET=y
|
||||
|
||||
# Enable clock control by default
|
||||
CONFIG_CLOCK_CONTROL=y
|
||||
|
||||
# Code partition needed to target the correct flash range
|
||||
CONFIG_USE_DT_CODE_PARTITION=y
|
||||
|
||||
# Output UF2 by default, native bootloader supports it.
|
||||
CONFIG_BUILD_OUTPUT_UF2=y
|
||||
|
||||
# USB HID
|
||||
CONFIG_ZMK_USB=y
|
||||
|
||||
# BLE HID
|
||||
CONFIG_ZMK_BLE=y
|
||||
|
||||
# Bootloader Support
|
||||
CONFIG_RETAINED_MEM=y
|
||||
CONFIG_RETENTION=y
|
||||
CONFIG_RETENTION_BOOT_MODE=y
|
||||
|
||||
# Settings Support
|
||||
CONFIG_MPU_ALLOW_FLASH_WRITE=y
|
||||
CONFIG_NVS=y
|
||||
CONFIG_SETTINGS_NVS=y
|
||||
CONFIG_FLASH=y
|
||||
CONFIG_FLASH_PAGE_LAYOUT=y
|
||||
CONFIG_FLASH_MAP=y
|
||||
|
||||
|
||||
# Enable HW stack protection
|
||||
CONFIG_HW_STACK_PROTECTION=y
|
||||
|
||||
# Enable GPIO
|
||||
CONFIG_GPIO=y
|
||||
|
||||
# Defaults for matrix scanning to avoid interrupt issues
|
||||
CONFIG_ZMK_KSCAN_MATRIX_POLLING=y
|
||||
```
|
||||
|
||||
Note that none of our in-tree boards have all of the above flags set. We recommend referencing the Kconfig flags from an existing in-tree board with the same SoC as the one you are using for your initial definition, making sure you understand what each flag does.
|
||||
|
||||
### Add Devicetree for ZMK Variant
|
||||
|
||||
```dts title="<your-board>_zmk.dts
|
||||
/*
|
||||
* Copyright (c) <year> <you>
|
||||
*
|
||||
* SPDX-License-Identifier: <your license>
|
||||
*/
|
||||
|
||||
// Include the base board definition
|
||||
#include <../boards/<vendor or you>/<board folder name>/<your board>.dts>
|
||||
// Include predefined boot mode settings, e.g.
|
||||
#include <arm/raspberrypi/rp2040-boot-mode-retention.dtsi>
|
||||
|
||||
// Disable UART nodes if they are not actively in use (wired split) as they increase power draw
|
||||
&uart0 { status = "disabled"; };
|
||||
|
||||
// Reduce the code partition section of the memory and add a storage partition to store ZMK Studio changes
|
||||
&code_partition {
|
||||
reg = <0x100 (DT_SIZE_M(2) - 0x100 - DT_SIZE_K(512))>;
|
||||
};
|
||||
&flash0 {
|
||||
reg = <0x10000000 DT_SIZE_M(2)>;
|
||||
partitions {
|
||||
storage_partition: partition@180000 {
|
||||
reg = <0x180000 DT_SIZE_K(512)>;
|
||||
read-only;
|
||||
};
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
See [here](./bootloader/index.mdx) for bootloader instructions for other SoCs. Depending on your SoC and design you may need to make further changes. Please refer to our in-tree boards with the same SoC as yours as examples.
|
||||
|
||||
## Next Steps
|
||||
|
||||
If your board is a keyboard, continue from [the `Kconfig.defconfig` step](https://zmk.dev/docs/development/hardware-integration/new-shield?keyboard-type=unibody#kconfigdefconfig) of the new shield guide. Use your ZMK variant's devicetree instead of the overlay file which would be used for a shield.
|
||||
|
||||
If your board is a board with an interconnect, your next step should be to write a [tester shield](../../troubleshooting/hardware-issues.mdx#identifying-issues). Such a shield should be the bare minimum shield to verify that your board works with ZMK.
|
||||
1
docs/docs/keymaps/_footnotes/macos-international.mdx
Normal file
1
docs/docs/keymaps/_footnotes/macos-international.mdx
Normal file
@@ -0,0 +1 @@
|
||||
On macOS in Japanese mode, `INTERNATIONAL1` is ろ (ro, bottom right on the Apple Japanese keyboard) and `INTERNATIONAL3` is ¥ (yen, top right).
|
||||
1
docs/docs/keymaps/_footnotes/macos-language.mdx
Normal file
1
docs/docs/keymaps/_footnotes/macos-language.mdx
Normal file
@@ -0,0 +1 @@
|
||||
On macOS in Japanese mode, `LANG1` is かな (kana, to turn on Japanese IME) and `LANG2` is 英数 (eisuu, to turn off the IME).
|
||||
@@ -11,18 +11,15 @@ Below is a summary of pre-defined behavior bindings and user-definable behaviors
|
||||
|
||||
## Key Press Behaviors
|
||||
|
||||
| Binding | Behavior | Description |
|
||||
| ------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `&kp` | [Key Press](key-press.md) | Send keycodes to the connected host when a key is pressed or released |
|
||||
| `&ktap` | [Key Tap](key-press.md#key-tap) | Send keycodes to the connected host when a key is pressed |
|
||||
| `&mt` | [Mod Tap](hold-tap.mdx#mod-tap) | Sends a different key press depending on whether a key is held or tapped |
|
||||
| `&kt` | [Key Toggle](key-toggle.md) | Toggles the press of a key. If the key is not currently pressed, key toggle will press it, holding it until the key toggle is pressed again or the key is released in some other way. If the key is currently pressed, key toggle will release it |
|
||||
| `&kt_on` | [Key Toggle](key-toggle.md#toggle-on-and-toggle-off) | Toggles on a key (sends keycode press event) on press |
|
||||
| `&kt_off` | [Key Toggle](key-toggle.md#toggle-on-and-toggle-off) | Toggles off a key (sends keycode release event) on press |
|
||||
| `&sk` | [Sticky Key](sticky-key.md) | Stays pressed until another key is pressed, then is released. It is often used for modifier keys like shift, which allows typing capital letters without holding it down |
|
||||
| `&gresc` | [Grave Escape](mod-morph.md#behavior-binding) | Sends Grave Accent `` ` `` keycode if shift or GUI is held, sends Escape keycode otherwise |
|
||||
| `&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 |
|
||||
| Binding | Behavior | Description |
|
||||
| ------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `&kp` | [Key Press](key-press.md) | Send keycodes to the connected host when a key is pressed |
|
||||
| `&mt` | [Mod Tap](hold-tap.mdx#mod-tap) | Sends a different key press depending on whether a key is held or tapped |
|
||||
| `&kt` | [Key Toggle](key-toggle.md) | Toggles the press of a key. If the key is not currently pressed, key toggle will press it, holding it until the key toggle is pressed again or the key is released in some other way. If the key is currently pressed, key toggle will release it |
|
||||
| `&sk` | [Sticky Key](sticky-key.md) | Stays pressed until another key is pressed, then is released. It is often used for modifier keys like shift, which allows typing capital letters without holding it down |
|
||||
| `&gresc` | [Grave Escape](mod-morph.md#behavior-binding) | Sends Grave Accent `` ` `` keycode if shift or GUI is held, sends Escape keycode otherwise |
|
||||
| `&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
|
||||
|
||||
@@ -33,15 +30,13 @@ Below is a summary of pre-defined behavior bindings and user-definable behaviors
|
||||
|
||||
## Layer Navigation Behaviors
|
||||
|
||||
| Binding | Behavior | Description |
|
||||
| ---------- | -------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
|
||||
| `&mo` | [Momentary Layer](layers.md#momentary-layer) | Enables a layer while a key is pressed |
|
||||
| `<` | [Layer-tap](layers.md#layer-tap) | Enables a layer when a key is held, and outputs a key press when the key is only tapped for a short time |
|
||||
| `&to` | [To Layer](layers.md#to-layer) | Enables a layer and disables all other layers except the default layer |
|
||||
| `&tog` | [Toggle Layer](layers.md#toggle-layer) | Enables a layer until the layer is manually disabled |
|
||||
| `&tog_on` | [Toggle Layer](layers.md#toggle-on-and-toggle-off) | Enables a layer even if the layer is already enabled |
|
||||
| `&tog_off` | [Toggle Layer](layers.md#toggle-on-and-toggle-off) | Disables a layer even if the layer is already disabled |
|
||||
| `&sl` | [Sticky Layer](sticky-layer.md) | Activates a layer until another key is pressed, then deactivates it |
|
||||
| Binding | Behavior | Description |
|
||||
| ------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
|
||||
| `&mo` | [Momentary Layer](layers.md#momentary-layer) | Enables a layer while a key is pressed |
|
||||
| `<` | [Layer-tap](layers.md#layer-tap) | Enables a layer when a key is held, and outputs a key press when the key is only tapped for a short time |
|
||||
| `&to` | [To Layer](layers.md#to-layer) | Enables a layer and disables all other layers except the default layer |
|
||||
| `&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
|
||||
|
||||
|
||||
@@ -47,32 +47,3 @@ Example:
|
||||
```dts
|
||||
&kp A
|
||||
```
|
||||
|
||||
## Key Tap
|
||||
|
||||
The "key tap" behavior will send a press followed by a release when you press the behavior, and will do nothing when you release the behavior.
|
||||
|
||||
### Behavior Binding
|
||||
|
||||
- Reference: `&ktap`
|
||||
- Parameter: The keycode usage ID from the usage page, e.g. `N4` or `A`
|
||||
|
||||
Example:
|
||||
|
||||
```dts
|
||||
&ktap A
|
||||
```
|
||||
|
||||
#### Configuration
|
||||
|
||||
You can adjust the tap duration, i.e. the time between press and release of the key, by changing the `tap-ms` property:
|
||||
|
||||
```dts
|
||||
&ktap {
|
||||
tap-ms = <30>; // This is the value already set by default
|
||||
};
|
||||
```
|
||||
|
||||
:::info
|
||||
Internally, the key tap behavior is a very simple [macro](./macros.md#defining-parameterized-macros).
|
||||
:::
|
||||
|
||||
@@ -25,11 +25,24 @@ Example:
|
||||
You can use any keycode that works for `&kp` as parameter to `&kt`, however, [modified keys](../modifiers.mdx#modifier-functions) such as `LA(A)` will be toggled based on the status of the base keycode (in this case `A`).
|
||||
In other words, modifiers are ignored when determining whether or not the key is currently pressed.
|
||||
|
||||
### Toggle On and Toggle Off
|
||||
### Configuration
|
||||
|
||||
For state-independent toggles, there exist two further behaviors:
|
||||
#### Toggle mode
|
||||
|
||||
- `&kt_on`: Toggles a keycode on, even if it is already on.
|
||||
- `&kt_off`: Toggles a keycode off, even if it is already off.
|
||||
If you wish to ensure that a key is pressed or released, rather than merely toggling, then you can do so with the `toggle-mode` property.
|
||||
Define a new behavior and assign `"on"` or `"off"` to `toggle-mode`:
|
||||
|
||||
Use these just as you would use `&kt`.
|
||||
```dts
|
||||
/ {
|
||||
behaviors {
|
||||
kt_on: key_toggle_on_only {
|
||||
compatible = "zmk,behavior-key-toggle";
|
||||
#binding-cells = <1>;
|
||||
display-name = "Key Toggle On";
|
||||
toggle-mode = "on";
|
||||
};
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
You can then use `&kt_on` in place of `&kt` whenever you wish to only toggle a key on, and not toggle it off. An `"off"` version of the behavior can be defined similarly.
|
||||
|
||||
@@ -67,14 +67,28 @@ Example:
|
||||
&tog 3
|
||||
```
|
||||
|
||||
### Toggle On and Toggle Off
|
||||
### Configuration
|
||||
|
||||
For state-independent toggles, there exist two further behaviors:
|
||||
#### Toggle mode
|
||||
|
||||
- `&tog_on`: Toggles a layer on, even if it is already on.
|
||||
- `&tog_off`: Toggles a layer off, even if it is already off.
|
||||
If you wish to ensure that a layer is toggled on or off specifically, rather than switching between the two states, then you can do so with the `toggle-mode` property.
|
||||
Define a new behavior and assign `"on"` or `"off"` to `toggle-mode`:
|
||||
|
||||
Use these just as you would use `&tog`.
|
||||
```dts
|
||||
/ {
|
||||
behaviors {
|
||||
tog_on: toggle_layer_on_only {
|
||||
compatible = "zmk,behavior-toggle-layer";
|
||||
#binding-cells = <1>;
|
||||
display-name = "Toggle Layer On";
|
||||
toggle-mode = "on";
|
||||
locking;
|
||||
};
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
You can then use `&tog_on` in place of `&tog` whenever you wish to only toggle a layer on, and not toggle it off. An `"off"` version of the behavior can be defined similarly.
|
||||
|
||||
## Layer Locking
|
||||
|
||||
@@ -82,13 +96,7 @@ When the behaviors `&to` and `&tog` toggle a layer on, they will "lock" the laye
|
||||
|
||||
In particular, if you activate a layer momentarily using e.g. `&mo 1`, tapping e.g. `&tog 1` as defined above will prevent the layer from deactivating after releasing `&mo 1`. You can then press `&tog 1` again to deactivate the layer.
|
||||
|
||||
You can remove the locking property from `&to` and `&tog` if you wanted them to be interruptable by `&mo`:
|
||||
|
||||
```dts
|
||||
&to {
|
||||
/delete-property/ locking;
|
||||
};
|
||||
```
|
||||
For custom toggle, to, and momentary layer behaviors, this can be enabled by giving your behavior the `locking;` property.
|
||||
|
||||
## Conditional Layers
|
||||
|
||||
|
||||
@@ -192,25 +192,6 @@ Parameterized macros must be defined using specific values for the `compatible`
|
||||
};
|
||||
```
|
||||
|
||||
An example of a simple parameterized macro is `&ktap`, which is defined as:
|
||||
|
||||
```dts
|
||||
/ {
|
||||
macros {
|
||||
ktap: key_tap {
|
||||
compatible = "zmk,behavior-macro-one-param";
|
||||
#binding-cells = <1>;
|
||||
display-name = "Key Tap";
|
||||
bindings = <¯o_param_1to1>, <&kp MACRO_PLACEHOLDER>;
|
||||
tap-ms = <30>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
```
|
||||
|
||||
This behavior is already pre-defined as `&ktap`, so you don't need to define it in your keymap to use it.
|
||||
|
||||
### Parameters, Bindings and Controls
|
||||
|
||||
There are special macro controls which must be used in order to forward received parameters to the macro's `bindings`. These controls are "one shot" and will determine how received parameters are used on the very next (non-macro control) behavior in the macro's `bindings` list.
|
||||
|
||||
6
docs/package-lock.json
generated
6
docs/package-lock.json
generated
@@ -18838,9 +18838,9 @@
|
||||
}
|
||||
},
|
||||
"node_modules/qs": {
|
||||
"version": "6.14.1",
|
||||
"resolved": "https://registry.npmjs.org/qs/-/qs-6.14.1.tgz",
|
||||
"integrity": "sha512-4EK3+xJl8Ts67nLYNwqw/dsFVnCf+qR7RgXSK9jEEm9unao3njwMDdmsdvoKBKHzxd7tCYz5e5M+SnMjdtXGQQ==",
|
||||
"version": "6.14.2",
|
||||
"resolved": "https://registry.npmjs.org/qs/-/qs-6.14.2.tgz",
|
||||
"integrity": "sha512-V/yCWTTF7VJ9hIh18Ugr2zhJMP01MY7c5kh4J870L7imm6/DIzBsNLTXzMwUA3yZ5b/KBqLx8Kp3uRvd7xSe3Q==",
|
||||
"license": "BSD-3-Clause",
|
||||
"dependencies": {
|
||||
"side-channel": "^1.1.0"
|
||||
|
||||
@@ -158,6 +158,7 @@ module.exports = {
|
||||
"development/hardware-integration/encoders",
|
||||
"development/hardware-integration/soft-off-setup",
|
||||
"development/hardware-integration/pointing",
|
||||
"development/hardware-integration/new-board",
|
||||
"development/hardware-integration/battery",
|
||||
{
|
||||
type: "category",
|
||||
|
||||
@@ -4,6 +4,8 @@
|
||||
* SPDX-License-Identifier: CC-BY-NC-SA-4.0
|
||||
*/
|
||||
|
||||
import macosLanguage from "@site/docs/keymaps/_footnotes/macos-language.mdx";
|
||||
import macosInternational from "@site/docs/keymaps/_footnotes/macos-international.mdx";
|
||||
import example from "@site/docs/keymaps/_footnotes/example.mdx";
|
||||
import iosApplication from "@site/docs/keymaps/_footnotes/ios-application.mdx";
|
||||
import iosPower from "@site/docs/keymaps/_footnotes/ios-power.mdx";
|
||||
@@ -13,6 +15,8 @@ import macosUndoRedo from "@site/docs/keymaps/_footnotes/macos-undo-redo.mdx";
|
||||
import globe from "@site/docs/keymaps/_footnotes/globe.mdx";
|
||||
|
||||
export default {
|
||||
macosLanguage,
|
||||
macosInternational,
|
||||
example,
|
||||
iosApplication,
|
||||
iosPower,
|
||||
|
||||
@@ -3396,10 +3396,12 @@ export default [
|
||||
windows: false,
|
||||
linux: true,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
footnotes: {
|
||||
macos: ["macosInternational"],
|
||||
},
|
||||
},
|
||||
{
|
||||
names: ["INTERNATIONAL_2", "INT2", "INT_KATAKANAHIRAGANA", "INT_KANA"],
|
||||
@@ -3417,7 +3419,7 @@ export default [
|
||||
windows: false,
|
||||
linux: true,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
@@ -3438,10 +3440,12 @@ export default [
|
||||
windows: false,
|
||||
linux: true,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
footnotes: {
|
||||
macos: ["macosInternational"],
|
||||
},
|
||||
},
|
||||
{
|
||||
names: ["INTERNATIONAL_4", "INT4", "INT_HENKAN"],
|
||||
@@ -3459,7 +3463,7 @@ export default [
|
||||
windows: false,
|
||||
linux: true,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
@@ -3480,7 +3484,7 @@ export default [
|
||||
windows: false,
|
||||
linux: true,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
@@ -3501,7 +3505,7 @@ export default [
|
||||
windows: false,
|
||||
linux: true,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
@@ -3522,7 +3526,7 @@ export default [
|
||||
windows: null,
|
||||
linux: false,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
@@ -3543,7 +3547,7 @@ export default [
|
||||
windows: null,
|
||||
linux: false,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
@@ -3564,7 +3568,7 @@ export default [
|
||||
windows: null,
|
||||
linux: false,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
@@ -3585,10 +3589,12 @@ export default [
|
||||
windows: true,
|
||||
linux: true,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
footnotes: {
|
||||
macos: ["macosLanguage"],
|
||||
},
|
||||
},
|
||||
{
|
||||
names: ["LANGUAGE_2", "LANG2", "LANG_HANJA"],
|
||||
@@ -3606,10 +3612,12 @@ export default [
|
||||
windows: true,
|
||||
linux: true,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
footnotes: {
|
||||
macos: ["macosLanguage"],
|
||||
},
|
||||
},
|
||||
{
|
||||
names: ["LANGUAGE_3", "LANG3", "LANG_KATAKANA"],
|
||||
@@ -3627,7 +3635,7 @@ export default [
|
||||
windows: false,
|
||||
linux: true,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
@@ -3648,7 +3656,7 @@ export default [
|
||||
windows: false,
|
||||
linux: true,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
@@ -3669,7 +3677,7 @@ export default [
|
||||
windows: false,
|
||||
linux: true,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
@@ -3690,7 +3698,7 @@ export default [
|
||||
windows: null,
|
||||
linux: false,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
@@ -3711,7 +3719,7 @@ export default [
|
||||
windows: null,
|
||||
linux: false,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
@@ -3732,7 +3740,7 @@ export default [
|
||||
windows: null,
|
||||
linux: false,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
@@ -3753,7 +3761,7 @@ export default [
|
||||
windows: null,
|
||||
linux: false,
|
||||
android: false,
|
||||
macos: null,
|
||||
macos: true,
|
||||
ios: null,
|
||||
},
|
||||
footnotes: {},
|
||||
|
||||
Reference in New Issue
Block a user