Keymap config ram

[osamuaoki]

Provide an optional feature to keymap_config data to be non-persistent.

This means keyboard always turn on to its default map without surprize of swapped keys but you still retain capability to swap via quantum keycode.

Description

This is an implementation of my comment posted as
#18353 (comment)

Instead of storing the keymap_config struct in eeprom, this enables user to select storing it in RAM if KEYMAP_CONFIG_RAM is defined.

The QMK behavior doesn't change for existing keyboards.

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

No more surprise for some swapped keys. At least, power-on reset them all.

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).

[sigprof]

You need to select develop as the base branch when opening a PR based on develop. It is possible to edit it after the fact (I did it for this PR), but getting things right from the start would be better (e.g., no confusing label changes).

[osamuaoki]

sigprof: sorry.

I just rebased to the latest develop.

[drashna]

This might be better in the eeconfig_(read/update)_keymap function itself, since there are other places that these functions are called (bootmagic used to be one place, but the steno keycode in the planck, for instance).

[drashna]

If the magic.c declaration isn't changed, this will error out on complication, I think.

[osamuaoki]

After good night sleep, I realized the changes to keycode_config.c is not needed for this PR purpose. (Though I still think it is redundant.)

I will force squashed patch for easier review.

[osamuaoki]

This is now a single file patch with 4 lines:
https://github.com/qmk/qmk_firmware/compare/develop..14d07cee64c4d905de1d627c4587e8531bf882aa

[sigprof]

Unfortunately, just removing the EEPROM operations from process_magic() does not fix the problem completely, because keymap_config also contains flags used by other features, and some other code also can call eeconfig_update_keymap():

• autocorrect_enable(), autocorrect_disable(), autocorrect_toggle();
• oneshot_set(), oneshot_enable(), oneshot_disable(), oneshot_toggle().

Also keeping the nkro flag persistent could be useful.

So if the intent here is “force the power-on state of the magic keycode modifications to be off”, this may need to be done inside eeconfig_read_keymap() and eeconfig_update_keymap() instead (if we keep the current EEPROM layout).

[github-actions]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[github-actions]

Thank you for your contribution!
This pull request has been automatically closed because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, or re-open when it's ready.
// [stale-action-closed]