This website works better with JavaScript.
Explore
Help
Sign In
xenua
/
zmk
Watch
1
Star
0
Fork
You've already forked zmk
0
Code
Issues
Pull Requests
Projects
Releases
Wiki
Activity
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1884
Commits
1
Branch
0
Tags
14 MiB
Tree:
356d9ac724
xmkb
Branches
Tags
${ item.name }
Create tag
${ searchTerm }
Create branch
${ searchTerm }
from '356d9ac724'
${ noResults }
zmk
/
app
/
tests
/
combo
/
combos-and-holdtaps-3
/
events.patterns
1 line
28 B
Raw
Normal View
History
Unescape
Escape
fix(behaviors): Fixing erroneous combo triggering, hold-taps sticking * This is a very simple fix to a rather complicated issue. Essentially, hold-taps will "release" (raise) their captured keys before actually telling the event manager they have captured a key. This means the event manager ends up assigning the `last_listener_index` to the hold-tap subscription rather than the combo. So when the combo calls `ZMK_EVENT_RELEASE` it raises after the hold-tap instead of after the combo as the combo code expects. * The corresponding test (which fails without this change) has also been added. * An event can be captured and released in the same event handler, before the last_listener_index would have been updated. This causes some handlers to be triggered multiple times. * The solution is to update the last_listener_index before calling the next event handler, so capturing and releasing within an event handler is harmless. * Also see discussion at https://github.com/zmkfirmware/zmk/pull/1401 * If our handler dedides our undedided hold-tap, return early before continuing. * Fix incorrect pointer logic, resulting in combo candidate filtering leaving incorrect timeout details. Co-authored-by: Andrew Rae <ajrae.nv@gmail.com> Co-authored-by: okke <okke@formsma.nl>
2 years ago
s/.*hid_listener_keycode_//p