Silences the following build warning ...
../src/ble.c:407:13: warning: 'auth_passkey_display' defined but not used [-Wunused-function]
407 | static void auth_passkey_display(struct bt_conn *conn, unsigned int passkey) {
fix: clang-format and setting state variable
fix: Fix startup settings configuration
fix(ext_power): Add static to state
fix(ext_power): Set default settings value
Use driver data status instead of global file state
The application usage used by report 1 is `HID_USAGE_GD_KEYBOARD`. Moreover, the `keys` usage page (0x07) that primarily feeds into this report is predominantly keyboard codes. The rest of the system should align with this naming convention.
Key release events released keys on the wrong layer if the 'top layer'
was not &trans above the &mo key.
base <&mo 1>
layer 1 <&kp B>
This was caused by overwriting
`zmk_keymap_active_behavior_layer[position]` after the &mo key was
handled.
Added a new setting to remember the user's preferred endpoint. When both USB and
BLE are connected, the preferred endpoint will be used.
Added a new behavior to control this setting. It supports commands:
&end END_USB - Prefer USB output
&end END_BLE - Prefer BLE output
&end END_TOG - Toggle between USB and BLE
Added zmk_ble_active_profile_is_connected() to allow code outside ble.c to check
the status of the active profile, and changed the ble_active_profile_changed
event to also notify when the active profile connects or disconnects.
Changed endpoint selection to to also update when the active profile changes,
connects, or disconnects.
This prevents stuck keys when switching endpoints by clearing
everything in the HID report and sending one last report before
switching to the new endpoint.
Added some utility functions and an event for tracking the state of the
USB connection.
Updated endpoints.c to select a single endpoint to send HID reports to
based on the status of the USB and BLE connections. Partially fixes#206.
Future commits will add a user setting to control which endpoint is used if
both USB and BLE are ready.
This is necessary for testing a large number of events (e.g. every key code) within a single build/pass.
The u8_t limitation became apparent during end-to-end testing of #21.
Pete Johanson