search

kareltucek / firmware

This is fork of UHK's firmware featuring extended macro engine.
Other
82 stars 9 forks source link

ResolveSecondary still contains pending key #83

Closed soraxas closed 2 years ago

soraxas commented 2 years ago

I wanted to use the ifPrimary / ifSecondar / resolveSecondary to implements ctrl+esc combo.

However, sometimes when I press the MacroKey + otherKey too quickly, MacroKey is still being resolved as the primary key (i.e. emits esc in my setup) rather than being treated as a secondary key (i.e. emits ctrl + whatever)

I have initially used the ifPrimary / ifSecondar, and switched to resolveSecondary to see if the parameters help. Please provide any guideline to me if I am missing something!

The following is how I worked around the issue (the ifPending command to check if there exists any pending key even when it was resolved as primary key)

resolveSecondary 350 100 primary secondary
primary:  // tap with short duration
    ifPending 1 goTo secondary  // any pending key will still morph it to ctrl 
    tapKey escape
    break
secondary: // holding key
    final holdKey leftControl
    break
kareltucek commented 2 years ago

IfPrimary / IfSecondary currently uses the advanced secondary role mechanism described an discussed in https://github.com/UltimateHackingKeyboard/firmware/issues/207 / https://github.com/UltimateHackingKeyboard/firmware/pull/326

Long story short, recognition is based on release sequence - in order to activate secondary role, next key has to be released at least <safety gap> ms before the secondary role key. You probably want to decrease the gap rather than increase it.

For your usecase, I guess you might want to use standard simple strategy. Regarding that, when the PR is accepted in official repository, I plan to connect the macro mechanism to the secondary role driver, and add argument to allow picking one of the two resolution strategies.

Also, I guess you would be fine with the mechanism described in examples - search for ifInterrupted.

soraxas commented 2 years ago

I see! Thanks for the great pointer and explanation of the advanced usage of ifPrimary / ifSecondary. I do agree that for my usecase, ifInterrupted would probably makes more sense.

Connecting the macro mechanism to the official repo with selectable resolution does sounds interesting! Hopefully this repo can get to merge more features back to the official repo.