-
Notifications
You must be signed in to change notification settings - Fork 330
Experimental ZMK Features
Many ZMK users are building firmware from branches that provide additional features but haven't yet been merged into the main ZMK branch. The Keymap Editor expects that you'll be building from the latest official ZMK code and while it won't allow for adding unrecognized behaviors it will leave them alone when loading a keymap that already references them.
In anticipation of these features eventually landing in ZMK officially, I'm going to try to stay ahead and add support for those who want to use it. For you this means you are already able to build (either with GitHub actions or locally) a keymap with the desired features, and can enable the use of new behaviors in the app. Right now this is just at the per-behavior level of granularity, so something like additional properties of an existing behavior won't be supported any time soon.
This is my attempt at supporting unsupported features. If things go bad it isn't the end of the world, but you should understand that at the end of the day all this app is doing reading and writing code. Syntax errors aside, you're responsible for building the ZMK firmware either locally or through GitHub actions in a repo that's configured to build from a ZMK repo containing the desired features.
There are a few forks that include this and I'm hoping that the main difference is just how up to date they are with the core ZMK branch. I'm basing this off of https://github.com/zmkfirmware/zmk/pull/778 which adds
zmk,behavior-mouse-movezmk,behavior-mouse-keyszmk,behavior-mouse-scroll
ZMK main is working on fleshing out pointer support but the API differs slightly. I've updated this experimental feature to support both, which results in both &mwh and &msc behaviors and duplicate MOVE_* direction codes. It's not ideal but I really just want to leave this alone until there's one canonical way to do mouse emulation.
Note
Because of the way the parameters are rendered in the UI's value picker currently, both sets of directional codes show as "Mouse scroll [direction]". The second set map to the MOVE_* codes used by ZMK PR#2027.
For ZMK branches that include PR #1893 this enables zmk,behavior-send-string in the app.
Note that the charmap property is not natively supported. I think this would be the first case where a user-created behavior would want to reference a non-behavior "device", and honestly you'd probably have an easier time constructing that character map in devicetree ahead of time, so if you do have an alternate this is a raw field where you can add its reference.