Repository navigation
fix: leader sequences capture custom-keycode sm_td taps (#29) - #61
Merged
Merged
Conversation
QMK's process_leader runs after process_record_user in the quantum chain, so it only sees taps that sm_td re-enters via process_record(). Native keycodes already take that pipeline path; custom/derived keycodes fall back to a direct tap_code16 send that bypasses process_record, so leader never saw them and the tap key leaked to the host instead. smtd_tap_code16 now routes the tap into the leader buffer via smtd_leader_consume (guarded by LEADER_ENABLE), mirroring process_leader. Only the tap path is covered, not holds during a sequence. Adds the smtd_leader integration suite (native + custom keycode).
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Fixes #29. QMK's leader feature (
process_leader) runs afterprocess_record_userin theprocess_record_quantumchain, so it only eversees a tap that sm_td routes back through
process_record().SMTD_MT(KC_A, MOD)) already take the pipeline path(
smtd_emulate_key→process_record) since the Bug: Caps Word not working after CKC_SPACE #23 pipeline-taps change, soleader sequences worked for them.
SMTD_MT_ON_MKEY(CUSTOM, KC_A, MOD)) cannot bepipelined and fell back to a direct
tap_code16send that bypassesprocess_record. The leader never saw the tap andKC_Aleaked to the host —exactly the reporter's symptom ("the OS sees an 'a'").
Fix
smtd_tap_code16now callssmtd_leader_consume(key)before the direct send,guarded by
#ifdef LEADER_ENABLE(zero effect when leader is off). It mirrorsprocess_leader:get_tap_keycode(unlessLEADER_KEY_STRICT_KEY_PROCESSING),leader_sequence_add,LEADER_PER_KEY_TIMINGtimer reset, andleader_endon afull buffer.
Scope (YAGNI): only the tap path is covered — holding a custom mod-tap during a
leader sequence is not added to the buffer, since leader is a tap-sequence
feature. Documented in
docs/030_known_problems.md.Testing
New
tests/integration/suites/smtd_leader/runs against a real QMK checkout withthe actual leader feature:
native_keycode_tap_is_captured_by_leader— green before and after (proves thenative case already worked).
custom_keycode_tap_is_captured_by_leader— characterizes the bug, now greenwith the fix.
No regressions: integration
smtd_full(19) andsmtd_caps_word(5) green,python unit suite 119 OK.