Apparently this is a vial bug rather than a qmk one...
If I setup a custom key, .... one that works perfectly fine as a regular key, to a tap dance double tap, instead of just triggering the key, it outputs repeat key forever. After putting in debug in the code, it is triggering the synthetic key release before the key press, thus the key release logic cannot activate.
enum ymdk_keycodes {
FOO = QK_KB_0,
HASH_TILDE
};
bool process_record_user(uint16_t keycode, keyrecord_t *record) {
debug_enable=true;
debug_keyboard=true;
debug_matrix=false;
uint32_t mods = get_mods();
uprintf("DEBUG: Keycode detected: %d pressed: %d type: %d\n", keycode, record->event.pressed, record->event.type);
switch (keycode) {
case HASH_TILDE:
if (record->event.pressed) {
uint16_t target_key = (get_mods() & MOD_MASK_SHIFT) ? KC_GRV : KC_3;
add_weak_mods(MOD_MASK_SHIFT);
register_code(target_key);
set_mods(mods);
if (record->tap.count == 2) {
unregister_code(target_key);
}
return false;
} else {
uprintf("released %d", keycode);
unregister_code(KC_GRV);
unregister_code(KC_3);
return false;
}
break;
}
return true;
}
So I have the above QK_USER_1 key. It uses register_code and unregister_code to simulate a key that has # hash as its value and ~ tilde as its shifted value (like some european keyboards actually have). I don't use tap_code16 because that doesn't handle actual held down repeating key. This works fine if I assign this key as a regular key. It can press, release hold and repeat like any other key. But when assigned to tap dance double tap it repeats forever. From the debug:
YMDK:Idobao x YMDK ID75:1: DEBUG: Keycode detected: 22272 pressed: 1 type: 1
YMDK:Idobao x YMDK ID75:1: DEBUG: Keycode detected: 22272 pressed: 0 type: 1
YMDK:Idobao x YMDK ID75:1: DEBUG: Keycode detected: 22272 pressed: 1 type: 1
YMDK:Idobao x YMDK ID75:1: DEBUG: Keycode detected: 22272 pressed: 0 type: 1
YMDK:Idobao x YMDK ID75:1: DEBUG: Keycode detected: 32257 pressed: 0 type: 1
YMDK:Idobao x YMDK ID75:1: released 32257DEBUG: Keycode detected: 32257 pressed: 1 type: 1
32257 is 7E01 in hex, aka QK_USER_1. As you can see there is a pressed: 0 (aka released event) BEFORE the pressed: 1 pressed event. So the tap dance synthetic key press seems to be in the wrong order, first triggering the release before the press. That means it is never released and it just repeats that key forever.
I was able to work around it in a rather nasty fashion by making a global variable to say if I received a key up, and then when I receive a key down within 20ms of that key up, I assume it's the tap dance bug and do a tap_code16 instead. Actually, the timing seems to be 0ms in practice, so I don't know if there's some event sorting that can't distinguish the right order or what, but there it is.
Apparently this is a vial bug rather than a qmk one...
If I setup a custom key, .... one that works perfectly fine as a regular key, to a tap dance double tap, instead of just triggering the key, it outputs repeat key forever. After putting in debug in the code, it is triggering the synthetic key release before the key press, thus the key release logic cannot activate.
So I have the above QK_USER_1 key. It uses register_code and unregister_code to simulate a key that has # hash as its value and ~ tilde as its shifted value (like some european keyboards actually have). I don't use tap_code16 because that doesn't handle actual held down repeating key. This works fine if I assign this key as a regular key. It can press, release hold and repeat like any other key. But when assigned to tap dance double tap it repeats forever. From the debug:
32257 is 7E01 in hex, aka QK_USER_1. As you can see there is a pressed: 0 (aka released event) BEFORE the pressed: 1 pressed event. So the tap dance synthetic key press seems to be in the wrong order, first triggering the release before the press. That means it is never released and it just repeats that key forever.
I was able to work around it in a rather nasty fashion by making a global variable to say if I received a key up, and then when I receive a key down within 20ms of that key up, I assume it's the tap dance bug and do a tap_code16 instead. Actually, the timing seems to be 0ms in practice, so I don't know if there's some event sorting that can't distinguish the right order or what, but there it is.