Allow 32 total User Defined Custom Keycodes

[mrnoisytiger]

The previous limit of 16 custom user keycodes was a little bit limiting. This change increases the allowable total number of user defined custom keycodes up to 32.

I, personally, think 32 is enough, but it is trivial to increase this number to ___ super easily. I just stopped at 32 because I didn't see too much of a reason to go higher. I suppose that was probably the reason for the initial 16, but I'm going to be exceeding that.

Completes issue #42.

[drashna]

This would have to be supported by the firmware, and have some way to check the number of keycodes, as well.

[mrnoisytiger]

This would have to be supported by the firmware, and have some way to check the number of keycodes, as well.

I actually have been testing up to USER18 just fine on the current QMK develop branch.

You can see below the total of 18 keycodes testing locally on this pull request's changes.

The white window is MIDI Monitor showing the keycode working. The keycode is defined in the keymap.c as

        case F_X:
            if (record->event.pressed) {
                midi_send_cc(&midi_device, midi_config.channel, 85, MIDI_CC_ON);
            } else {
                midi_send_cc(&midi_device, midi_config.channel, 85, MIDI_CC_OFF);
            }
            return true;

and was enumerated in the keymap.c as well:

enum custom_keycodes {
    A_CW = USER00,
    A_CCW,
    B_CW,
    B_CCW,
...
    F_X,
};

Given my successes with USER18 already based on the (admittedly) develop branch of QMK (see the encoder map support), I see no reason it would not work for up to 32. If desired, I can make 32 total keycodes and provide proof that it's working as well. I can also attach the QMK files for the firmware that I'm currently playing with as a testbed.

[mrnoisytiger]

have some way to check the number of keycodes, as well.

I don't see why this is necessary. The enum custom_keycodes{} seems to allow an arbitrary enumeration and does not limit it in QMK natively. Rather, it seems inherently limited to only the microcontroller's memory footprint, which would fill up as you increase the number of keycodes.

VIA would simply need to just allow an "arbitrary" number as best, but upping it to some arbitrary number like the PR changes I requested does the trick as well. VIA is already more-or-less able to interface with them, and it knows how to use em based on the screenshots I sent of it working fine with 18.

I don't think there needs to be some kind of feedback mechanism to know how many custom keycodes there are (as there already isn't). VIA is simply displaying all the keycodes defined in the customKeycodes property of the VIA JSON:

{
  "name": "Damapad",
  ...
  "customKeycodes": [
    { "name": "A_CW", "title": "A_CW", "shortName": "A_CW" },
    { "name": "A_CCW", "title": "A_CCW", "shortName": "A_CC" },
    { "name": "B_CW", "title": "B_CW", "shortName": "B_CW" },
    { "name": "B_CCW", "title": "B_CCW", "shortName": "B_CC" },
...
    { "name": "B_X", "title": "B_X", "shortName": "B_X" },
    { "name": "C_X", "title": "C_X", "shortName": "C_X" },
    { "name": "D_X", "title": "D_X", "shortName": "D_X" },
    { "name": "E_X", "title": "E_X", "shortName": "E_X" },
    { "name": "F_X", "title": "F_X", "shortName": "F_X" }
  ],
  "layouts": {
    "labels": [["Bottom Left","WKL","Space"]],
    "keymap": [

In short, I think this PR should be merge-able as-is without any QMK changes (besides what was in develop, I did not test main). Let me know if I'm missing something, since this has seemed to work fine.

[Jpe230]

Is there a reason why VIA needs to limit the number of custom keycodes? With QMK's newest support for RP2040s boards (With up to 16Mb in flash storage) having hundreds of macros is a possibility now, so limiting the number is more of a software restriction rather than a hardware restriction.

In my quest to enable more than 16 custom keycodes I managed create a way to enable up to 41,087 custom keycodes (0xFFFF - 0x5F80 (USER00)), by basically moving the upper limit to the max. allowed in QMK: (There are more changes in my branch to fix some stuff that broke by removing the limit)

export function isUserKeycodeByte(byte: number) {
  return byte >= basicKeyToByte.USER00 && byte <= 0xffff;
}

[drashna]

I don't see why this is necessary

Okay, so how does via know how many are available? using the customKeycodes property in the json isn't 100% reliable. having a definitive answer from the firmware itself would be much more reliable.

Is there a reason why VIA needs to limit the number of custom keycodes? With QMK's newest support for RP2040s boards (With up to 16Mb in flash storage) having hundreds of macros is a possibility now, so limiting the number is more of a software restriction rather than a hardware restriction.

QMK has only about 500 "slots" left for keycodes. The rest are used/reserved for different features. Eg, after SAFE_RANGE, there is only about 500 numbers/values that can be used. After that, there are no more unpopulated ranges.

It's not a matter of storage, but a limitation of using a 16bit variable. And changing it to 32 bit is non-trivial, and probably prevent a majority of avr based boards from having enough space.

Edit: Changing to 32 bit keycodes is pretty trivial, it turns out. However, this change causes the required eeprom amount for VIA to exceed the available size on a vast majority of AVR based boards.

[mrnoisytiger]

Okay, so how does via know how many are available? using the customKeycodes property in the json isn't 100% reliable.

I guess my confusion stems from why VIA even needs to know. In current form, VIA does not expose any user key codes unless they are defined in customKeycodes.

Even if you then defined perfectly in QMK, they will not show up in VIA’s interface at all apart from those it learned about in the customKeycodes property. You can still access them through the “Any” keycode feature by typing USER** or the corresponding hex code for them.

So, no matter how unreliable VIA using the customKeycodes property in JSON actually is, it’s the only way it currently does it anyways. Any right now, even at 16 codes, there is no reporting of the number and VIA doesn’t care if there is 1, 2, or 16.

Certainly having some reporting feature (and maybe defining shortCode, etc…) in QMK would be best but it’s certainly not required. The current value was 16 was just an arbitrary choice (from what it seems) and there is no reason it can’t be increased to 32 or 87 or 118 or any other random number.

[yoichiro]

Actually, in current implementation of VIA in the QMK Firmware side, key codes over USER15 can work as USER**. However, I wonder whether we can recognize that the USER** range is from 0x5F80 to 0xFFFF. That is, current implementation of QMK Firmware allows the wide range, but it is only a behavior of current logic, and this behavior is different from a concern of what is a specification.

As my understanding, you guys opinions are different like the following:

• @mrnoisytiger: The current implementation does not have any limitation of the range for USER**. Therefore, we can recognize that the USER** key code range is from 0x5F80 to 0xFFFF as a specification.

• @drashna: We must not use whole remaining range for USER**, because the remaining range is not wide and there may be key codes for other purposes. That is, there must be a limitation of the range for USER** key codes as a specification. The behavior of the current implementation of QMK Firmware does not become a reason to use key codes from 0x5F80 to 0xFFFF for USER**.

At least, as my idea, I almost agree the drashna's idea. I think a concrete range should be necessary for USER** as a specification. A specification and an implementation are different concerns. Of course, the number of current USER** might be little, and I agree that we increase the number from 16 to 32. But, I disagree that the number of USER** becomes "Any" numbers as a specification.

[mrnoisytiger]

@yoichiro I mostly agree with what you said here. I think "any"/unlimited number of keycodes is a bad idea, because mayebe QMK will release future features which need additional keycodes. Instead, I absolutely suggest that we do some kind of a range, even if it is 32, or 100, or similiar. That way, we still have room for future keycodes.

However, because the developer that creates the VIA file and the QMK file is typically the same person. That same person should know the number of supported custom keycodes and would likely define it themselves anyways. So "reporting" between QMK and VIA should not be necessary.

[drashna]

The last user available code is 0x6000. Above that is in use.

[Silther]

is there any news about this?
if you have a macropad with 16 keys and 4 layers, for example, a selection of macros from 32 to 64 would be very useful.