Custom lock behavior can now be defined and actively used in the
keyboard.
A lock is toggled by typing a key, containing reference to the root
variable definition (`compatible = "zmk,behavior-custom-lock.yaml"`).
In order to have "A pressed -> Lock pressed -> A released" behave
correctly, this commit introduces a queue for currently pressed keys.
A release of such a key would then release the previous used behavior,
instead of the behavior the current lock state would suggest.
The size of the queue can be adjusted with `ZMK_BHV_LOCK_KEY_MAX_HELD`
Signed-off-by: Sophie Tyalie <dev@flowerpot.me>
Previously the definition was copied almost 1:1 from the `none` behavior
in order to set up the important files and have a small running, but
featureless sample.
This change introduces a way to actually configure the custom lock
behavior, using the following syntax:
```
behaviors {
dead_lock_prevent {
compatible = "zmk,behavior-custom-lock";
// to define a key
dead: dead_key {
#binding-cells = <2>;
bindings = <&kp>, <&kp>;
}
// or to define a macro
deadm: dead_macro {
#binding-cells = <2>;
bindings = <¯o>, <&kp>;
}
}
}
```
Additionally, there's now no standard definition flying around (deletion
of `dts/behaviors/custom_lock.dtsi`)
Signed-off-by: Sophie Tyalie <dev@flowerpot.me>
This is the first commit introducing custom lock behavior. Currently
does nothing, except existing and that one can reference it in the
keyboard layout not dissimilar to e.g. `&none`.
The code is also orientated along the latter for right now, ready to be
extended.
Signed-off-by: Sophie Tyalie <dev@flowerpot.me>
* Update docs for mod-morph
* Add unit tests for mod-morph
* Add keep-mods to DT binding
Co-authored-by: Martin Aumüller <aumuell@reserv.at>
Co-authored-by: Cem Aksoylar <caksoylar@users.noreply.github.com>
* Update planck_rev6.keymap
Third layer was causing problems so i moved reset and bootloader to second layer
* BT_sel functions
A customer requested this so we added it
* Update crbn.keymap
Co-authored-by: Nick Winans <nick@winans.codes>
The bindings for the toggle-layer-on-tap/momentary-layer-on-hold example code were backwards, resulting in toggle-on-hold. This also made momentary unachievable.
All credit for this one goes to @xudongzheng (thanks for helping debug
this!). Should fix the issue where keyboards go unresponsive after their
host machine wakes from sleep due to the USB driver entering an error
state. I was able to both reliably reproduce the issue before the patch
goes in and confirmed it no longer occurs post patch.
The `USB_DC_RESUME` state indicates the host event has resumed the connection.
Adding it to the list of valid connection states to prevent the error
when waking from sleep.
Zephyr API Link:
https://docs.zephyrproject.org/apidoc/latest/group____usb__device__controller__api.html#gac09e3e0af1a2b41a5bfbad91f900baf7fixes#1372
* This is a very simple fix to a rather complicated issue. Essentially,
hold-taps will "release" (raise) their captured keys before actually
telling the event manager they have captured a key. This means the event
manager ends up assigning the `last_listener_index` to the hold-tap
subscription rather than the combo. So when the combo calls
`ZMK_EVENT_RELEASE` it raises after the hold-tap instead of after the
combo as the combo code expects.
* The corresponding test (which fails without this change) has also been added.
* An event can be captured and released in the same event handler, before
the last_listener_index would have been updated. This causes some handlers
to be triggered multiple times.
* The solution is to update the last_listener_index before calling the next
event handler, so capturing and releasing within an event handler is harmless.
* Also see discussion at https://github.com/zmkfirmware/zmk/pull/1401
* If our handler dedides our undedided hold-tap,
return early before continuing.
* Fix incorrect pointer logic, resulting in combo
candidate filtering leaving incorrect timeout details.
Co-authored-by: Andrew Rae <ajrae.nv@gmail.com>
Co-authored-by: okke <okke@formsma.nl>
