Make default layer size 16-bit

[drashna]

Description

Set the layer state to be 16-bit by default.

I would rather set this to 8-bit, but until the configurator can handle that without issue, ... it supports 16 layers, so this would work in the meanwhile.

And this allows for smaller compiled sizes.

Types of Changes

• Core
• Enhancement/optimization
• Documentation

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

[KarlK90]

LGTM and is a sane default.

[precondition]

I can already hear the unrest that would come from the havoc caused by all the biton32 in the wild no longer working. Other than that, I'm in favor of this.

[fauxpark]

That's why you're supposed to use get_highest_layer() instead ;)

[precondition]

Yes, indeed but I still see too many people on the QMK discord server posting code bits using biton32 instead of get_highest_layer :(

[precondition]

Speaking of biton32, shouldn't the ~265 user files calling the biton32 function in place of get_highest_layer get changed in this PR too? For example:

keyboards/bpiphany/kitten_paw/keymaps/ickerwx/keymap.c:135:    layer = biton32(layer_state);

[fauxpark]

We try to avoid changing user code en masse like that...
Core and default-ish keymaps are fair game though.

[drashna]

Yes, indeed but I still see too many people on the QMK discord server posting code bits using biton32 instead of get_highest_layer :(

That's because it in a lot of the default keymaps. And people copy and paste code.

But I've been flagging that in any new PRs, so more copy-paste code hasn't been incorrectly added.

Edit: I've updated the default keymaps, docs, and associated kb files to use get_highest_layer when appropriate, now.

[drashna]

Speaking of biton32, shouldn't the ~265 user files calling the biton32 function in place of get_highest_layer get changed in this PR too? For example:

keyboards/bpiphany/kitten_paw/keymaps/ickerwx/keymap.c:135:    layer = biton32(layer_state);

Also, some of the rational behind not changing all of the user files doing this (besides, "that's a lot of work"), is that using biton32 will work and "fail gracefully". So there is no harm in leaving it. But future examples and the default keymps should use the correct function.

[zvecr]

Also worth noting that the configurator currently supports more than 8 layers. And some keyboards also set DYNAMIC_KEYMAP_LAYER_COUNT greater than 8.

[drashna]

Also worth noting that the configurator currently supports more than 8 layers. And some keyboards also set DYNAMIC_KEYMAP_LAYER_COUNT greater than 8.

The dynamic keymap layer count is already taken into account, but github doesn't show a lot of context. Literally, right above:

https://github.com/qmk/qmk_firmware/blob/c76cfc2d36ead86a5ec9e4d5061a28987b0bca18/quantum/action_layer.h#L24-L41

However, the configurator is a good point, and this PR should wait to be merged until there is something in place to handle that.

[noroadsleft]

Merge conflicts.

[tzarc]

Seems to break the helix boards.

[tzarc]

Deferred to Q3 so helix can be fixed and verified.

[drashna]

Deferred to Q3 so helix can be fixed and verified.

How was this breaking the helix boards?

I do see one keymap that won't compile, but that's because it's doing some really weird stuff. All the rest compile. However, I don't have a board to test on.

[tzarc]

I don't remember, and at this stage I'm inclined to say "develop can break, we can fix over time if issues occur".