feat(endpoints): add "no endpoint" value
This adds ZMK_TRANSPORT_NONE, which can be set as the preferred
endpoint transport if you wish to prevent the keyboard from sending any
output. More usefully, it also is used to indicate that the preferred
endpoint is not available and it could not fall back to an available
one. To go along with this, many endpoint functions are renamed for
consistency, and a few new functions are added:
- zmk_endpoint_get_preferred_transport() returns the value that was set
with zmk_endpoint_set_preferred_transport().
- zmk_endpoint_get_preferred() returns the endpoint that will be used
if it is available. This endpoint always has the same transport as
zmk_endpoint_get_preferred_transport().
- zmk_endpoint_is_connected() is a shortcut to check if the keyboard is
actually connected to an endpoint.
This change is based on #2572 but without the option to disable endpoint
fallback. It does refactor code to allow adding that feature later.
fix(endpoints): Add endpoint setting upgrade
Adding ZMK_TRANSPORT_NONE at the start of enum zmk_transport results in
the preferred transport setting no longer representing the same values
when it is saved with earlier firmware and loaded with newer firmware.
To fix this, the "endpoints/preferred" setting is now deprecated and
replaced by "endpoints/preferred2". If the old setting is present, it
is interpreted as the old enum type, upgraded to the new type, and saved
immediately to the new setting. The old setting is then deleted.
To avoid this happening again in the future, enum zmk_transport now has
explicit values assigned to identifier, and a comment is also added to
explain that existing values must not be changed.
fix: Set default transport according to enabled transports
The default value for preferred_transport is now set to USB only if
CONFIG_ZMK_USB is enabled. If not, it falls back to BLE if
CONFIG_ZMK_BLE is enabled, then to "none" if nothing is enabled.
* 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.
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 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.
* Use lesser-known DT features to skip behaviors not referenced
in the user keymap
* Update the behaviors to skip code if no nodes found.
* Remove some empty config/data structs where unused in
behaviors.
