-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
feat(modularisation/docs) New hardware metadata version #2396
Conversation
* Other drivers properly disconnect/de-config pins now, so we need to be sure the wakeup trigger connects the wake pin as input.
* Clean up composite kscan to allow multiple instances properly. * Implement PM hook and properly suspend/resume the child devices. Fixes: zmkfirmware#2388
It would be cool to add some physical layout definitions for keyboards. For example, QMK uses a KLE-like JSON format. We could add some common presets like ANSI60, ANSI104, ISO60, ISO105, etc. Then, we might allow the xxx+x approach for ergonomic boards (e.g., 23332+2 is a Hummingbird layout). Additionally, we could use a KLE-like JSON for custom layouts. Usage examples:
|
That information is already now possible to set in the devicetree with the new physics layouts refactor so it's available in firmware for the upcoming ZMK Studio work. It would be a net negative to duplicate that in the metadata, IMHO. |
I think the broad strokes of this organization makes sense. A separate repo where PRs can go into to add "references" from which tooling can discover things is a sensible approach. One small suggestion I'd have for now would be to have I think there are a few things that warrant further discussion. I am not listing these because I necessarily have an opinion on them but discussion around them would be good to have.
Footnotes
|
Great idea, I'll make this change.
The reason for this is specifically a security/malicious actor concern. By specifying a commit, we can prevent harmful images/code/etc from being present in the version of the module that we recommend (unless it is missed on review). I think SHA-1 should suffice here, though cybersecurity/cryptography isn't my specialty.
I think I'll change it so that the
I was quite torn on whether to include or remove it. I'll remove it.
My thinking was that we could write a tool that goes through all of the modules in a Ideally we could have it auto-accept particular changes (ex. adding |
I like that a bit better, and you may be right on the versioning.
That makes sense to me. |
I have been thinking a bit about maintenance costs. Zephyr has a policy in place which only allows changes to modules as mergeable PRs and strictly forbids force-pushes to the main branch. Something similar could help reduce the review burden for the ZMK team. On the flipside, to reduce maintenance costs for module maintainers, I'd second that some form of ZMK version system (with infrequent api-breaking changes) would be desirable. Even if not strictly necessary, forcing maintainers to check compatibility for every ZMK commit is a huge burden. Moreover, if modules aren't synchronized, which seems inevitable in a large ecosystem without proper upstream versioning, then the burden ultimately gets passed on to end-users: To update their firmware, they will need to:
|
Something similar would be an excellent policy to have in You raise a good point and argument for versioning as well. If we introduced a versioning system, then the module:
url: https://github.com/module-owner/module-repo-name
version:
- 2-1-3: 093dj09sdapasdlkd09285c585e08pjonkjn7y8798
- 1-0-12: c43a0365183c58f74c285c585e0cbc1ea99f8a12 That would allow tools like zmk-cli to completely remove the burden you described. |
* UART and BLE/GATT transports for a protobuf encoded RPC request/response protocol. * Custom framing protocol is used to frame a give message. * Requests/responses are divided into major "subsystems" which handle requests and create response messages. * Notification support, including mapping local events to RPC notifications by a given subsystem. * Meta responses for "no response" and "unlock needed". * Initial basic lock state support in a new core section, and allow specifying if a given RPC callback requires unlocked state or not. * Add behavior subsystem with full metadata support and examples of using callback to serialize a repeated field without extra stack space needed. Co-authored-by: Cem Aksoylar <[email protected]>
* Add an easy snippet for enabling USB UART added to the `zephyr_udc0` standard node.
* New behavior allows unlocking the keyboard to allow ZMK Studio to make changes. Co-authored-by: Cem Aksoylar <[email protected]>
* Cover stm32, RP2040, and nRF52 builds.
* Reduce RAM usage, no need for heap any more in ZMK. * Don't attempt to enable FPU that's not present.
If I'm understanding this correctly, with this proposal, in order to add or update a module, you would need to manually copy all the .zmk.yml files from the module into the central repository, then update each one to include the module repo's URL and the specific commit from which the data was pulled. Failing to do this correctly could lead to the data in the central repo not matching that of the module repo. It seems to me like it would be a lot easier to maintain if the central repo contained only module URLs and commit hashes. Then to update a module, you would only need to update the commit hash in one file. This would mean you could not search the central repo directly for specific keyboards/behaviors/etc., but it would be possible to set up a website which is generated by collecting data from every module into a searchable database. |
On keyboard geometry, that's such a topic - e.g. with Xx+Y notation, how do you describe something like Hillside? Even my current "key count, columns, rows, and extra keys" format doesn't quite work because an extra index finger column and an extra pinky column serve different purposes. |
The docs from #2268 found here describe the physical layout system nicely. The current plan is to add tags to each key such as "PINKY_HOME" at some point in the future. |
Closing this for the time being. While I do still feel like an update to the metadata would be nice, I no longer feel that it is necessary for the module ecosystem to mature. It would be better to revisit this topic at a much later stage and see what would be useful. |
This is an initial rough draft for a version 2 of the ZMK hardware metadata standard. The goal is to define the metadata such that the metadata files can be collected in a separate repository titled
zmk-modules
. This draft has not updated the metadata schema, but rather the documentation of it, to be easier to read and encourage discussion. Also note that as the schema has been previously changed without updating the documentation, there are some properties to which I was uncertain of their use - I gave it my best guess.The assumption is that (almost) all boards and shields currently in the ZMK tree will be moved to external module repositories, all interconnect definitions will be moved to
zmk-modules
, and only the boards and shields used for testing purposes remain in-tree.ZMK's setup scripts and related docs would need to be adjusted accordingly, either also in this PR or in a separate one. An initial rough draft
zmk-modules
can be found here, focusing on folder structure.As this would obviously break compatibility with a lot of people's setups, I would suggest doing it simultaneously with whatever changes are necessary to move to Zephyr 3.7 LTS. When everything is completed, then I believe we can (finally) close #453.
We could also include some optional properties that would allow for some cool tools to make use of zmk-modules. In particular, the data to enable tools comparing keyboards to one another might be very beneficial, as currently the developers of such tools have to input each new keyboard manually themselves.
TODO:
zmk-modules
repositoryzmk-modules
zmk-modules
repositoryzmk-modules
with existing modulesEDIT: Thanks to discussion, it seems that we also need: