Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[XAP Prereq] External IDs need to be defined in data/*.json #15597

Open
tzarc opened this issue Dec 27, 2021 · 2 comments
Open

[XAP Prereq] External IDs need to be defined in data/*.json #15597

tzarc opened this issue Dec 27, 2021 · 2 comments
Assignees

Comments

@tzarc
Copy link
Member

tzarc commented Dec 27, 2021

XAP Task Info

Original Issue
Original spec document
Current XAP Definitions
Current XAP Generated Docs
Placeholder PR

Description

Any work in this area needs to be discussed with QMK Collaborators first, and in this case primarily with @fauxpark due to their prior work in this area.

As a prerequisite of the XAP work, we need to shift all externally-visible QMK IDs into *.json files under data/, or some other "versionable" location.

This currently includes:

  • Keycode IDs
  • RGB Effects IDs

These IDs need to be versioned in lock-step with the XAP protocol version, such that they effectively are defined by the protocol, even when not running a XAP-enabled firmware.

Ideally these IDs should not change, such that newer firmwares are compatible with older host apps that do not have the newer keycode definitions; the firmware will gracefully communicate with existing known IDs. However, in more drastic scenarios, this also allows for reordering at will; if we need to reallocate ranges in order to be able to "clean up", then newer firmware builds can do so by increasing the version accordingly. It will be up to the host app to be able to determine if it can cope, and disable the dynamic keymap subsystem if not.

These IDs should also have a corresponding compile-time validation header, much like quantum/via_ensure_keycode.h so that anyone attempting to add new keycodes triggers a failure and thus needs to discuss with collaborators whether a new version is required.

NOTE: no mapping tables are to be generated and included in the firmware -- available flash space is already scarce, so the intention here is to shift the complexity out of the firmware and into host apps.

@tzarc tzarc added enhancement help wanted xap XAP-related issues/PRs labels Dec 27, 2021
@tzarc
Copy link
Member Author

tzarc commented Dec 27, 2021

Also required: the definitions need to be able to define how certain keycodes are "mixed" with others, such as C(S(KC_E)).

@zvecr zvecr self-assigned this Feb 22, 2022
@stale
Copy link

stale bot commented Jun 12, 2022

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs.
For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

@stale stale bot added the stale Issues or pull requests that have become inactive without resolution. label Jun 12, 2022
@stale stale bot removed the stale Issues or pull requests that have become inactive without resolution. label Jun 12, 2022
@tzarc tzarc added this to XAP MVP Sep 25, 2023
@tzarc tzarc moved this to In progress in XAP MVP Sep 25, 2023
@qmk qmk deleted a comment from MissBittu Oct 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In progress
Development

No branches or pull requests

2 participants