Added ZMK_MACRO_DEFAULT_WAIT_MS and ZMK_MACRO_DEFAULT_TAP_MS to set
global defaults for the wait-ms and tap-ms properties of macros.
Also reduced the default timings for macros, since it's been reported
many times that 100 ms is too slow.
* Add blackbill interconnect metadata.
* Add config/overlay for upstream blackpill boards to work with ZMK.
* Add pillbug board.
* Updated new shield docs.
Co-authored-by: Cem Aksoylar <caksoylar@users.noreply.github.com>
Added overlays to support building for the nRF5340 development kit.
Also added some documentation on how to build and flash ZMK for dual-
chip Bluetooth configurations, with an example for the nRF5340.
Lock state will be persistently stored on a per profile basis if
configured in keyboard dts (`persistence = "per-profile"`).
If per-profile is enabled the settings will store a state for USB and
the maximum allowed connection profiles.
Signed-off-by: Sophie Tyalie <dev@flowerpot.me>
Persistence of a custom lock is disabled by default, but it can now
be enabled in the dts keyboard config similar to this:
```
deadlock: deadlock {
compatible = "zmk,behavior-custom-lock";
label = "dead-key-toggle";
#binding-cells = <0>;
persistence = "enabled";
}
```
Currently the options are `disabled`, `enabled` and `per-profile`, where
the latter doesn't do anything different to `enabled` as of right now.
Signed-off-by: Sophie Tyalie <dev@flowerpot.me>
Using Zephyrs settings functionality, persist the lock state across
a device reset (e.g. power cycle).
Settings are stored as a bool in `bhv/lock/[lock-name]`, with the lock
name being the device name.
I've taken the liberty to add the custom lock behavior to the
`SYS_INIT` queue.
Signed-off-by: Sophie Tyalie <dev@flowerpot.me>
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>
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>
* add support for Spaceman Pancake
Co-authored-by: Pete Johanson <peter@peterjohanson.com>
Co-authored-by: Jason Hazel <jhazel@matrixmediaservices.com>
Co-authored-by: Pete Johanson <peter@peterjohanson.com>
