refactor(Kconfig): Extracted designer defaults out into new files #2537
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an alternative approach to #1886, with the same end goal. All of the "designer configurable" defaults are extracted out to separate files named
Kconfig.defaults
. The definitions stay in the sameKconfig
file, only the defaults move. The defaults are imported after the keyboard config options, allowing them to be overridden by designers.I used my own judgement to decide whether an option should be treated as "designer configurable". In general:
Specific additional options are made available to designers, such as USB vendor ID -- companies who have their own VID may want to override this one.There are also some options that are listed in the docs, which I don't think should be listed in the docs as I don't understand why either designers or users should have any business touching them. For example:CONFIG_ZMK_USB_INIT_PRIORITY
CONFIG_ZMK_BLE_INIT_PRIORITY
I have included such flags where I was uncertain as "designer configurable" out of caution.While at it, I added a name to the
EC11
trigger mode choice, and updated some values listed in the docs to be accurate.Hopefully this more explicit approach is more "palatable" than #1886 and can get merged easier...