* Studio will use stable layer IDs to refer to layers, so that
layer reordering doesn't affect behavior bindings, so update to match.
* Fix a few layer metadata entries that missed being refactored.
* For upcoming ZMK studio work, make a set of rich metadata available
to provide a friendly name for a behavior, and allow super flexible
descriptions of the parameters the behaviors take.
* Add ability to validate a zmk_behavior_binding against
the behavior metadata available.
* Better naming for gpio-key behavior triggers.
* Tweaks to scanned behavior trigger to avoid bad semaphore use,
and reduce chance of issues with slowly scanned matrixes.
* Various code cleanups of style issues.
* Move to local/stack allocated event API that doesn't require
dynamic allocation/freeing.
* Disable heap, we no longer use alloc/free unless using LVGL.
* Tons of refactors all over to account for the new event approach.
Removed the label property from built-in behaviors, custom behaviors
defined in a few keymaps, and macros generated with ZMK_MACRO().
Now that node names are used to identify behaviors, and names only need
to be unique within the set of behaviors, the names of all behaviors
have been shortened to be similar to their original labels.
This means that any keymaps which reference behavior nodes by name
instead of by label will need to be updated. Keymaps typically use the
labels though, so most keymaps should be unaffected by this change.
Added BEHAVIOR_DT_DEFINE() and BEHAVIOR_DT_INST_DEFINE(), which work
exactly like the DEVICE_*_DEFINE() macros, except they also register the
device as a behavior by adding a pointer to it to a memory section.
Added zmk_behavior_get_binding(), which works like device_get_binding()
except that it only searches the devices that have been registered as
behaviors. This ensures that behaviors cannot have name collisions with
other devices defined by the SoC, which will be important when we remove
the label property from behaviors so they are given their node names.
As an added benefit, this is faster since it searches a smaller list.
Some basic benchmark code I wrote indicates it takes 30-70% as long,
depending on where the behavior is in the list and whether the name
string is an exact pointer match.
From now on, behaviors should use BEHAVIOR_*_DEFINe() instead of
DEVICE_*_DEFINE(), and any code that looks up a behavior by name should
use zmk_behavior_get_binding() instead of device_get_binding().
Changed all code (except for layer names) which used the label property
to use DEVICE_DT_NAME() instead, which uses the label if set or falls
back to the full node name. This matches how Zephyr determines the node
names used with device_get_binding() and allows us to start removing the
deprecated label property from things.
Adds new functionality and a behavior to disconnect an active BLE connection.
The motivation for this is that for some devices like phones, the presence of an
active BLE connection results in the onscreen keyboard being selected.
* Add HID report/descriptor for a new report with mouse buttons,
and x/y/wheel deltas.
* New mouse key press behavior for press/release of mouse keys.
* Add constants for HID main item values (e.g. data/array/absolute)
* Define and use constants for our HID report IDs.
Detaching the global-quick-tap functionality from the quick-tap term.
This makes way for two improvements:
1. This functionality can be added to combos under a unified name
'global-quick-tap-ms'.
2. This allows users to set a lower term for the 'global-quick-tap'
(typically ~100ms), and a higher term for the regular
quick-tap (typically ~200ms)
This deprecates the global-quick-tap option, however if it is set, the
quick-tap-ms value will be copied to global-quick-tap-ms.
Changed the endpoints code to rename the existing endpoint types to
"transport" and add the concept of "endpoint instances". A transport is
the method by which data is sent, while instances allow describing
multiple endpoints that use the same transport (e.g. bluetooth profiles)
Also added new APIs to get the total number of possible endpoint
instances and assign each instance a unique index, which can be used
for tracking separate state for each endpoint in other code files.
* 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>
