* To be able to use the Zephyr `voltage-divider` driver,
add a mode for fetching raw voltage from the sensor
and do state of charge calculation outside of the driver.
* Add a dedicated settings reset on start init priority and default
it to lower priority (high number) than default FLASH_INIT_PRIORITY
to be sure flash is initialized before we open the area.
Updated the section for troubleshooting split halves unable to pair now
that the settings_reset shield resets all settings and explicitly
disables CONFIG_ZMK_BLE:
- Added a note that all settings will be reset.
- Removed the section about immediately putting the halves into
bootloader mode to prevent pairing, as this is not necessary anymore.
- Added a note that you will not be able to see or pair the Bluetooth
keyboard until you have flashed regular firmware again.
- Added a sentence to clarify that you will need to re-pair the
keyboard to all host devices.
Also added some text describing common scenarios where this procedure
might be needed.
Added a new CONFIG_ZMK_SETTINGS_RESET_ON_START option which enables init
code to call zmk_settings_erase(), and changed the settings_reset shield
to use it instead of CONFIG_ZMK_BLE_CLEAR_BONDS_ON_START, so it now
resets all settings instead of just clearing BLE bonds.
CONFIG_ZMK_BLE_CLEAR_BONDS_ON_START is left in place for now in case
someone still needs it. It may be replaced in the future once we find a
better way to repair a broken split connection.
Added a zmk_settings_erase() function to clear all saved settings. This
does not go through Zephyr's settings subsystem, but instead directly
clears the data from the setting storage backend, so a reboot is needed
for it to take effect.
* Handle board keymap location for boards with Zephyr
board revisions included.
* Includes bare non-revision file and a revision specific keymap
in case newer revision changes the layout/key positions.
Because global behaviors have to exist on both the central and split
regardless if the user references them in their keymap, we can't omit
the behavior declaration if the user doen't reference it and decide to
compile it later based on the existence of the behavior declaration. The
best option seems to be to decide whether to compile those behaviors
based on the feature Kconfig flag. This also means that the two reset
behaviors will always be compiled into both sides.
Added a warning to the shield section explaining that Kconfig does
not ignore whitespaces on function calls and therefore adding whitespaces
after the comma will break functionality.
