Add BOOTMAGIC_ENABLE=both which combines lite and full mode

[dkjer]

Add BOOTMAGIC_ENABLE = both which combines lite and full mode

Description

Currently BOOTMAGIC_ENABLE can either be 'lite' ('yes') or 'full'. VIA currently forces 'lite' mode when enabled, presumably to have a method for clearing eeprom and entering bootloader mode that isn't reliant on a particular set of keys being available on layer 0 (which VIA may change).

This change allows for both 'full' mode and 'lite' mode to be enabled at the same time. VIA still defaults to enabling 'lite' mode, but will allow for 'both' mode if bootmagic 'full' functionally is also desired.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[tzarc]

You'll need a via_eeprom_reset() call somewhere as per bootmagic lite.

[dkjer]

You'll need a via_eeprom_reset() call somewhere as per bootmagic lite.

Is there a reason bootmagic full's eeconfig_init() won't work for this purpose?

[dkjer]

I have updated the PR to allow for both lite mode and full mode, so that there is always a 'failsafe' method to call via_eeprom_reset()

[zvecr]

As full bootmagic is on the list of things that might be removed in the near future, could you go into some detail behind the use case for this change (and maybe touch on why the magic keycodes wont suffice).

[dkjer]

As full bootmagic is on the list of things that might be removed in the near future, could you go into some detail behind the use case for this change (and maybe touch on why the magic keycodes wont suffice).

I honestly don't have a strong use case for bootmagic full, and if its on the list of things to be removed then we can just close this PR.

The main thing I liked keeping it enabled for is having the toggling of debug flags actually being written to eeprom via eeconfig_update_debug, as opposed to using MAGIC_KEY_DEBUG_* which doesn't update eeprom. Obviously someone could add their own functionality to suite their preferences, but it was convenient to have a built-in way to choose whether or not to have your debug settings be 'sticky' when iterating on firmware changes.

[drashna]

You'll need a via_eeprom_reset() call somewhere as per bootmagic lite.

Is there a reason bootmagic full's eeconfig_init() won't work for this purpose?

Because VIA doesn't properly hook into eeconfig_init. It's an oversight that I have a PR open to fix.
#13243

[drashna]

The main thing I liked keeping it enabled for is having the toggling of debug flags actually being written to eeprom via eeconfig_update_debug, as opposed to using MAGIC_KEY_DEBUG_* which doesn't update eeprom. Obviously someone could add their own functionality to suite their preferences, but it was convenient to have a built-in way to choose whether or not to have your debug settings be 'sticky' when iterating on firmware changes.

Well, bootmagic_lite can be overwritten to do more than just the reset, so ... that may be the better way to go.

[noroadsleft]

As full bootmagic is on the list of things that might be removed in the near future, could you go into some detail behind the use case for this change (and maybe touch on why the magic keycodes wont suffice).

Full Bootmagic's removal was actually placed on the agenda for QMK back in early March, and this develop cycle is scheduled to remove Full Bootmagic as a feature.

https://docs.qmk.fm/#/ChangeLog/20210529?id=bootmagic-deprecation-and-refactor