sigprof
commented
1 year ago That's one really complicated keymap…
Fast typing issue: fast 'i' + ('t'+'a') returns 'f' instead of '['. A fast 'i'+'t' will return a symbol from layer1 as expected. However when a combo is involved, it returns the combo from layer0.
This might not be fixable with the current combo implementation. The order of key event processing is as follows:
process_combo()— combos are resolved here; key events involved in combos are buffered until the combo term expires, then either the original events or the combo results are sent to the next step.action_tapping_process()— dual role keys likeLT()orMT()are resolved here; key events are buffered until the action can be resolved as a tap or a hold.process_record()— here the key events are actually translated to the corresponding action (send some key events to the host, switch layers, …).
Your i key is apparently #define RHI0 LT(1, KC_I) (and it's also involved in some combos), and you have PERMISSIVE_HOLD defined, so you may expect that quickly pressing i, then pressing and releasing another key, then releasing i would result in the i key actually switching the layer to 1 even if you perform that action faster than the tapping term. However, if you press the t and a keys quickly, the combo code looks up the keycodes for your t and a keys before the LT(1, KC_I) key has been processed, therefore it gets the keycodes from layer 0 and uses the corresponding combo; subsequent action_tapping_process() gets just the combo lookup result of KC_F, and even though LT(1, KC_I) gets processed before that KC_F and switches the layer, KC_F remains unchanged, because it's no longer a normal key event with a matrix row and column, but a combo result with a fixed keycode.
Using MO(1) on a dedicated key would avoid the problem (at least if it's not part of another combo, or if you always press the next key after the combo term for MO(1) had expired).
Alternatively, you may try using #define COMBO_ONLY_FROM_LAYER 0, defining all your combos based on layer 0 to return custom keycodes, and then handling the layer switching for those custom keycodes yourself:
case COMBO_1:
static uint8_t combo_1_layer;
if (record->event.pressed) {
combo_1_layer = get_highest_layer(layer_state);
}
if (combo_1_layer == 0) {
// ... handle press/release on layer 0
} else if (combo_1_layer == 1) {
// ... handle press/release on layer 1
}
break;You need to save the layer state on press separately for each such keycode, so that the release action would match the press action even if the layer state had changed in the meantime. This essentially duplicates the builtin keymap lookup functionality and the source layer cache, but is apparently the only way to apply the layer state set by LT() to combos.
(Instead of using #define COMBO_ONLY_FROM_LAYER 0, you may try to define custom keycodes only for combos from layer 0 keys, so that you can detect that a switch to layer 1 had happened and handle them as layer 1 equivalents in that case; however, there would be some chance that the tapping term expires between the keypresses in the combo — in that case the combo code would see a mix of keycodes from layer 0 and layer 1 and won't be able to build a combo from that.)
Roming22
TristanCacqueray
Describe the Bug
Keyboard configuration available here
Keyboard Used
No response
Link to product page (if applicable)
https://shop.beekeeb.com/product/pre-soldered-hillside-keyboard/
Operating System
Linux (Fedora 37)
qmk doctor Output
Is AutoHotKey / Karabiner installed
Other keyboard-related software installed
None
Additional Context
Board: Hillside46 MCU: Sea-picro controller (RP2040).