* Add two new compatibles for macros that
take one or two parameters when bound in
a keymap.
* Use `¯o_param_1to1`, `¯o_param_1to2`, `¯o_param_2to1`,
and `¯o_param_2to2` control entries in the bindings for the macro
to have the next binding entry have it's values substituted.
Co-authored-by: Cem Aksoylar <caksoylar@users.noreply.github.com>
* Refactor sensor events to include channel data,
necessary for prop split encoders, and avoiding duplicate calls,
to fetch channel data twice, etc.
* More consistent behavior driver API.
* Allow setting triggers per resolution at the behavior level optionally.
* Add new sensor behaviors that either take full bindings
add definition, or accept parameters when bound in the
keymap.
* Remove existing hard-coded key press sensor behavior
and instead leverage new generic sensor behaviors to
achieve the same functionality.
Co-authored-by: nick@conway.dev
Extended the virtual key position system from combos so that each sensor
also gets a virtual key position. This allows sensor behaviors to use
the behavior queue API.
Fixed an issue where the sticky key behavior would call
ZMK_EVENT_RAISE_AFTER(), which would free the provided event, but then
it would keep using that now-freed event data.
* Move away from DT_LABEL.
* Move to DEVICE_DT_GET for non-behavior device access.
* Move various drivers to `gpio_spec_dt` and `DT` related macros.
* Remove mcp23017 while at it, since better upstream driver is
available.
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.
* 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>
* 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>
* Allows removing multilib from docker images
* Run properly in aarch64 host docker
containers for testing on Rasberry Pi.
* Small sticky-keys fix to initialize w/ correct
constant for max uin32_t value.
If multiple sticky keys with quick release were nested, only the first one
was properly released. This fix makes sure all of them are released properly.
Fixes https://github.com/zmkfirmware/zmk/issues/1149
To combine multiple sticky modifiers, the sticky keys must ignore
other (sticky) modifier keypresses.
This behavior is important for "callum-style mods", where all modifiers
are sticky mods.
Fixes#829
* GATT characteristic allowing passng data + behavior
label to invoke the behavior on the peripheral side.
* Behaviors have a locality setting to specify where they run.
* Build reset/power/RGB on peripheral.
* Add optional `hold-trigger-key-positions` hold-tap configuration
* Leverage configuration for decision making around when to trigger
hold decision in hold-taps.
* Add docs for new configuration.
* Tests for the new config/decision logic.
A hold-tap timer event would be triggered too soon if the hold-tap
was delayed for longer than its tapping-term. This may cause
accidental hold behavior when the correct behavior would be tap.
By queuing the timer event instead of executing it immediately,
other delayed events get a chance to be processed properly.
Quick release for sticky keys failed for non-layer keys. The sticky key
was released just before the key that was supposed to be modified was
handled.
The issue was caused by an error in the sticky key logic, which released
the sticky key before handling the key up event.
Fixes#696.
