VIA Protocol 12

[wilba]

This PR contains the changes to VIA code in QMK to match with the VIA V12 protocol (functionality and keycodes).

It pairs with the-via/app#104 which will contain a link to the webapp that uses these changes (i.e. the next version of https://usevia.app).

The intent of this PR is to remove VIA-specific keycodes/handling, such that VIA's keycode dictionary can work entirely from QMK's JSON definition of keycodes.

• Added QK_USER_0 .. QK_USER_31 keycodes based on existing QK_USER range.
• Added QK_KB_0 .. QK_KB_31 keycodes based on existing QK_KB range.
• Added range SAFE_RANGE as QK_KB_0 value overlaps with previous SAFE_RANGE value.
• Removed the VIA specific MACRO00..MACRO15, converted uses to QK_MACRO_0..QK_MACRO_15 etc.
• Removed the VIA specific USER00..USER15, converted uses to QK_KB_0..QK_KB_15
• Refactored the VIA specific FN_MO13, FN_MO23 keycodes/handling into a generalized simple tri-layer feature
• Refactored WT RGB keycodes to be user keycodes, which map to "generalized" custom keycodes in VIA.

Also:

• Support more than 16 macros
• Make switch matrix tester work with large switch matrices using multiple queries to get state.
• Fix device indication (i.e. flash backlight) when active keyboard changes in VIA

Regarding the tri-layer feature:

The intent of adding this to core is to refactor it out of via.c and remove the VIA-specific keycodes. A long time ago, when generalizing my keyboard-level code into VIA code, I decided it was useful enough to be added there, so that everyone using VIA could have access to the ability to access three layers with only two keys, without requiring every keyboard achieve this with custom keycodes and duplicated implementation code. I still believe it's a great feature that everyone should be able to use easily in QMK even when not using VIA. I am open to suggestions regarding changing the keycode names, adding aliases, etc.

Update: Tri-layer feature refactored in #19795

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

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

[zvecr]

Personally I would like to see this broken up so that the tri-layer feature isnt coupled to keycode related changes which are also not coupled to via.

[wilba]

Unit tests fail because qmk generate-keycodes --version 0.0.2 -o quantum/keycodes.h doesn't merge in SAFE_RANGE from keycodes_0.0.1.hjson, not sure why, the ranges get merged.

[zvecr]

SAFE_RANGE wasnt declared as a range, it was a single keycode that is now being overwritten. To replicate the old behaviour you would have to add it as an alias to the new definition of 0x7E00. However it might be better to add the following to keycodes_0.0.2.hjson

{
    "ranges": {
        "0x7E00/0x01FF": {
            "define": "SAFE_RANGE"
        }
    }
}

As ranges are currently not checked for overlapping values.

Also, you cant add 0.0.1 files, they would be

keycodes_0.0.1_kb.hjson -> keycodes_0.0.2_kb.hjson
keycodes_0.0.1_user.hjson -> keycodes_0.0.2_user.hjson

[wilba]

Thanks.

Adding SAFE_RANGE to keycodes_0.0.2.hjson didn't work, since it's a duplicate value of QK_KB_0 and so it fails on the merge. It works as an alias of QK_KB_0.

[zvecr]

Sounds like you added it as a key rather than range?

Ive update the suggestion, to further clarify what I meant. If its working then thats probably good enough while we work through the reset of the PRs content.

[wilba]

Yep, my bad, thanks.

[drashna]

As I'm sure you're aware, the preference for PRs is to contain a single isolated change to simplify reviews. This PR could quite easily be broken up into smaller parts.
The tri-layer code is a prime example -- though in its current form it's fairly restrictive and could be expanded upon, into its own feature. To that end, I've created PR #19795, which already includes unit tests, which would certainly be required for any lower-level code that modifies layer functionality, in an effort to expedite things.
If you could, take a look at that PR, as we would appreciate your feedback on it.

[wilba]

#19795 looks good to me. When it's merged to develop, I'll update this PR and remove the tri-layer feature. I'd prefer to replace FN_MO13 FN_MO23 keycodes with TL_LOWR TL_UPPR in keymaps rather than maintain more legacy aliases.

[drashna]

#19795 looks good to me. When it's merged to develop, I'll update this PR and remove the tri-layer feature. I'd prefer to replace FN_MO13 FN_MO23 keycodes with TL_LOWR TL_UPPR in keymaps rather than maintain more legacy aliases.

It's merged.

[drashna]

util/regen.sh should fix the keycode regen warnings

[wilba]

@tzarc merged develop

[tzarc]

Just a heads-up, the merge target was changed to a staging branch so some cleanup from our side can occur.
We'll get it into develop when practical.