-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
Description
Testing as of pre-v0.4, and issue confirmed on Discord.
Combos are defined with a list of keys (integers), implicitly in terms of the chosen layout.
Currently if there is an alternative layout and the user switches to that in ZMK Studio, the integer key list is seemingly reinterpreted naively for the new layout. It does not respect any position_map (which would either follow a natural adjustment or disable the combo if some of the keys are not currently active).
Example from Bivouac34 which has either 4 or 6 thumbs. My boot-loader combo is defined in the 6-thumb layout:
// Inner corners (T, Y, home thumbs) = &bootloader
combo_bootloader {
timeout-ms = <300>;
key-positions = <4 5 29 32>;
bindings = <&bootloader>;
layers = <0>;
};
My position map drops the 2 most tucked thumbs (originally 28 and 33):
/ {
position_map {
compatible = "zmk,physical-layout-position-map";
physical_layout34 {
physical-layout = <&physical_layout34>;
positions = <28 29 30 31 32 33>;
};
physical_layout32 {
physical-layout = <&physical_layout32>;
positions = <32 28 29 30 31 33>;
};
};
};
Ideally this would translate key-positions = <4 5 29 32>; (in physical_layout34) into key-positions = <4 5 28 31>; (in physical_layout32). In some cases a combo will be using a key dropped from the layout and will be unable.
Workaround: I could rearrange the key order in ZMK to put the optional thumb-keys last (as 32 and 33), then when they are removed none of the other keys change number. That's what my Bivvy16D design did.