This is a generalization of the existing concept of tri-layer support
that's already well known. Essentially, a conditional-layer
configuration activates a particular layer (the then-layer) when one or
more other layers (the if-layers) are activated.
This is commonly used on ortho keyboards to activate a third "adjust"
layer while the primary two layers ("lower" and "raise") are active.
* 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.
Switched the GPIO matrix driver to debouncing using a simple integrator
algorithm. Whenever a key is pressed, we now scan at a rate controlled
by debounce-scan-period-ms (default 1 ms) until all keys are released,
then return to either waiting for an interrupt or polling more slowly.
The timers for key press and release can now be controlled separately,
so debounce-period is deprecated in favor of debounce-press-ms and
debounce-release-ms. Global Kconfig options
ZMK_KSCAN_DEBOUNCE_PRESS_MS and ZMK_KSCAN_DEBOUNCE_RELEASE_MS are also
added to make these easier to set.
Added documentation for debouncing options.
Recent refactoring of the font handling seems to have broken the display
of the last symbol of the output status widget. From my analysis the
last symbol is truncated because the buffer simply is too small.
Increasing the buffer size to 9 fits all three possible symbols.
* Add ZMK_HID_CONSUMER_REPORT_USAGES choice to allow choosing
between full consumer usage range, with poor OS compat,
or basic consumer usage range, with broader compat.
* Add new Kconfig settingsx to allow selecting system or dedicated
work queue for performing UI updates.
* Allow UI updates to not block other system tasks when display is
updating, especially important for e-ink displays.
* Workaround for ensuring macOS pairing happens early enough,
for their stack, we require encryption for the hids report map and
report ref characteristics as well, to trigger pairing ealier in the
connection process for macOS.
For split keyboards using an IO expander over TRRS/i2c, if the
right half isn't connected, we should be able to gracefully
fallback to the left side still working.
toddmok