Combo RAM and Kconfig reduction #2849

petejohanson · 2025-02-27T22:39:05Z

Keeping this draft for now, but this is a collection of improvements to remove a few combo Kconfig flags that are instead auto-calculated at build time, and reduce the RAM usage on more constrained devices.

A Le Chiffre STM32 Build on main:

[198/198] Linking C executable zephyr/zmk.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       42636 B       128 KB     32.53%
             RAM:        8120 B        15 KB     52.86%
     RetainedMem:          0 GB          1 B      0.00%
        IDT_LIST:          0 GB         2 KB      0.00%

Same keymap with this PR:

❯ west build -d build/lc_stm32_tap_dance
[7/7] Linking C executable zephyr/zmk.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       42732 B       128 KB     32.60%
             RAM:        7736 B        15 KB     50.36%
     RetainedMem:          0 GB          1 B      0.00%
        IDT_LIST:          0 GB         2 KB      0.00%

For a savings of 384 bytes.

Needs some more cleanup, and there's room for some performance improvements for the access to the new bit fields, but this should be ready for early testing.

PR check-list

Branch has a clean commit history
Additional tests are included, if changing behaviors/core code that is testable.
Proper Copyright + License headers added to applicable files (Generally, we stick to "The ZMK Contributors" for copyrights to help avoid churn when files get edited)
Pre-commit used to check formatting of files, commit messages, etc.
Includes any necessary documentation changes.

Determine the max keys per combo automatically from the devicetree, so we remove the ZMK_COMBO_MAX_KEYS_PER_COMBO Kconfig symbol.

Reference combos by index, not 32-bit pointers, and store bitfields instead of arrays in several places, to bring down our flash/RAM usage.

Use bit field to track candidate combos, to avoid needing an explicit `ZMK_COMBO_MAX_COMBOS_PER_KEY` setting.

caksoylar · 2025-02-27T23:28:20Z

app/src/combo.c

+#define COMBO_CONFIGS_WITH_MATCHING_POSITIONS_LEN(positions, _ignore)                              \
+    DT_INST_FOREACH_CHILD_VARGS(0, COMBO_INST, positions)
+static const struct combo_cfg combos[] = {
+    LISTIFY(10, COMBO_CONFIGS_WITH_MATCHING_POSITIONS_LEN, (), 0)};


Should 10 be MAX_COMBO_KEYS instead? I have 30% confidence that I understand what this is doing, but it sounds like it is iterating over possible key_positions lengths.

This deserved a comment: MAX_COMBO_KEYS is not a pre-processor constant, but a C union trick, so can't be used as a parameter to LISTIFY, so we basically pick an arbitrary high value that won't tax the pre-processor too much. I picked 10, since it's unlikely for someone to combo with more fingers than they have.

I guess it doesn't hurt to set this to a high number, so maybe we go 'til 255 (devicetree limit, IIRC)? Unless you think preprocessor can slow down the build by a significant amount.

I guess it doesn't hurt to set this to a high number, so maybe we go 'til 255 (devicetree limit, IIRC)? Unless you think preprocessor can slow down the build by a significant amount.

It might, and honestly, this is iterating by key-positions length, so I'm having a hard time imagining we need to support a combo triggered by 256 different key positions?

Right, just thought it was perhaps a number with lesser-magic involved than 10, it's fine to keep that too (perhaps with a comment and noting the limitation in docs).

Nick-Munnich · 2025-02-27T23:44:53Z

app/Kconfig

+    int
+    default 0
+    help
+      Deprecated: Storage for combos is now determined automatically


I don't think these should be deprecated. Rather I think we should take the max of the automatic determination and whatever this value is set to, for future Studio use.

When we have future studio use, we'll likely "pre-allocate" things by setting placeholders up in the devicetree, like we do with reserved layers, so our auto-calculation will still be usable there as well.

Closer inspection, seems doable for MAX_COMBOS_PER_KEY, but less so for vice-versa: what if DT has only 2 and 3 key combos, and then someone wants to set up a 5 key one in Studio?

app/Kconfig

app/src/combo.c

Nick-Munnich · 2025-02-28T00:58:04Z

app/src/combo.c

    return 0;
 }

 static bool combo_active_on_layer(const struct combo_cfg *combo, uint8_t layer) {
-    if (combo->layers[0] == -1) {
-        // -1 in the first layer position is global layer scope
+    if (!combo->layer_mask) {


I wonder if the layer mask might be nicer as an inverted mask, i.e. 0s as true and 1s as false.

Nick-Munnich · 2025-02-28T01:07:27Z

app/src/combo.c

+    for (int i = 0; i < ARRAY_SIZE(combos); i++) {
+        if (sys_bitfield_test_bit((mem_addr_t)&candidates, i)) {
+            const struct combo_cfg *candidate = &combos[i];
+            bool found = false;
+            for (int kp = 0; kp < candidate->key_position_len; kp++) {
+                if (candidate->key_positions[kp] == position) {
+                    matches++;
+                    found = true;
+                    break;
+                }
+            }
+
+            if (!found) {
+                sys_bitfield_clear_bit((mem_addr_t)&candidates, i);
+            }


Shouldn't we be able to just & the candidates and the combo lookup bitfields with one another?

Indeed, with some tweaks for counting remaining bits.

app/src/combo.c

Nick-Munnich · 2025-02-28T11:54:18Z

Joel had an interesting comment here that might also apply to this PR.

…o indexes

petejohanson · 2025-03-04T06:53:31Z

Joel had an interesting comment here that might also apply to this PR.

Moved to uint32_t type for the bit fields to avoid alignment issues.

Nick-Munnich · 2025-03-04T09:55:43Z

app/src/combo.c

@@ -105,17 +105,17 @@ static const struct combo_cfg combos[] = {
 #define COMBO_CHILDREN_COUNT (0 DT_INST_FOREACH_CHILD(0, COMBO_ONE))

 // We need at least 4 bytes to avoid alignment issues
-#define BYTES_FOR_COMBOS_MASK MAX(4, DIV_ROUND_UP(COMBO_CHILDREN_COUNT, 8))
+#define BYTES_FOR_COMBOS_MASK MAX(4, DIV_ROUND_UP(COMBO_CHILDREN_COUNT, 32))


Do we still need this to be a minimum of 4 now that everything is uint32_t?

Nick-Munnich · 2025-03-04T10:38:00Z

app/src/combo.c

+static uint8_t number_of_set_bits(uint32_t field) {
+    uint8_t count = 0;
+    while (field) {
+        field &= (field - 1);
+        count++;
    }
-    // clear unmatched candidates
-    for (int i = matches; i < CONFIG_ZMK_COMBO_MAX_COMBOS_PER_KEY; i++) {
-        candidates[i].combo = NULL;
+
+    return count;
+}


I don't think we actually need to calculate the total number of set bits. We only care if it's 0, 1, or more.

Something like

if (value == 0) { return 0; } if ((value & (value - 1)) == 0) { return 1; } return 2;

petejohanson added 4 commits February 27, 2025 00:56

refactor: Remove ZMK_COMBO_MAX_KEYS_PER_COMBO

d4f76d2

Determine the max keys per combo automatically from the devicetree, so we remove the ZMK_COMBO_MAX_KEYS_PER_COMBO Kconfig symbol.

refactor(combos): Reduce RAM usage with bitfields, combo indexes

7ebe3d0

Reference combos by index, not 32-bit pointers, and store bitfields instead of arrays in several places, to bring down our flash/RAM usage.

refactor(combos): Remove ZMK_COMBO_MAX_COMBOS_PER_KEY

9ba1f48

Use bit field to track candidate combos, to avoid needing an explicit `ZMK_COMBO_MAX_COMBOS_PER_KEY` setting.

fixup! refactor(combos): Reduce RAM usage with bitfields, combo indexes

2feeeaa

petejohanson added refactor combos labels Feb 27, 2025

petejohanson self-assigned this Feb 27, 2025

caksoylar reviewed Feb 27, 2025

View reviewed changes

fixup! refactor(combos): Remove ZMK_COMBO_MAX_COMBOS_PER_KEY

66c8b3a

Nick-Munnich reviewed Feb 28, 2025

View reviewed changes

amacleod mentioned this pull request Feb 28, 2025

Check for combos exceeding CONFIG_ZMK_COMBO_MAX_COMBOS_PER_KEY at compile time. #2551

Open

fixup! refactor(combos): Reduce RAM usage with bitfields, combo indexes

f2c8b61

fixup! fixup! refactor(combos): Reduce RAM usage with bitfields, comb…

efc5b45

…o indexes

Nick-Munnich reviewed Mar 4, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Combo RAM and Kconfig reduction #2849

Combo RAM and Kconfig reduction #2849

petejohanson commented Feb 27, 2025

caksoylar Feb 27, 2025

petejohanson Feb 27, 2025

caksoylar Feb 27, 2025 •

edited

Loading

petejohanson Feb 27, 2025

caksoylar Feb 27, 2025

Nick-Munnich Feb 27, 2025

petejohanson Feb 28, 2025

Nick-Munnich Feb 28, 2025

Nick-Munnich Feb 28, 2025

Nick-Munnich Feb 28, 2025

petejohanson Mar 4, 2025

Nick-Munnich commented Feb 28, 2025

petejohanson commented Mar 4, 2025

Nick-Munnich Mar 4, 2025

Nick-Munnich Mar 4, 2025

Combo RAM and Kconfig reduction #2849

Are you sure you want to change the base?

Combo RAM and Kconfig reduction #2849

Conversation

petejohanson commented Feb 27, 2025

PR check-list

Choose a reason for hiding this comment

Choose a reason for hiding this comment

caksoylar Feb 27, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nick-Munnich commented Feb 28, 2025

petejohanson commented Mar 4, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

caksoylar Feb 27, 2025 •

edited

Loading