zmk.git/app/tests, branch mainZMK Bluetooth keyboard firmware.http://git.nvandoorn.com/zmk.git/atom/app/tests?h=main2021-06-13T14:44:18Zfix(behaviors): Fix timing of delayed hold-tap trigger2021-06-13T14:44:18ZOkke Formsmaokke@formsma.nl2021-03-07T13:50:30Zurn:sha1:efa497c69b813852d3704dbd96207f1186eb941a
A hold-tap timer event would be triggered too soon if the hold-tap
was delayed for longer than its tapping-term. This may cause
accidental hold behavior when the correct behavior would be tap.
By queuing the timer event instead of executing it immediately,
other delayed events get a chance to be processed properly.
fix(combos): Check each combo key, not just last2021-06-09T00:35:58ZJonathan Rascherjon@bcat.name2021-06-08T15:56:02Zurn:sha1:4e69a32103a2905b9a32c80c8d3d798fbb0d9a0f
The current combo completion check only makes sure the last key in the
combo is set. This works when the combo is typed correctly initially, or
when reraising events in a combo of length two. However, it fails for
longer combos since the last event in pressed_keys might be set, but the
first (or subsequent) event in pressed_keys can be NULL thanks to
release_pressed_keys.
Also added a regression test.
test(combo): Add unit test for complete long combo2021-06-09T00:35:58ZJonathan Rascherjon@bcat.name2021-06-08T15:47:23Zurn:sha1:eecc12c98022c1dce4a228914887ed328b1774c2refactor(combos): Rename existing long combo test2021-06-09T00:35:58ZJonathan Rascherjon@bcat.name2021-06-08T15:43:27Zurn:sha1:bba1599824dc98284656d96748c7f09f10d5a00e
This test doesn't test a long combo that completes, but rather one
that's incomplete (so the combo doesn't trigger). Renaming to avoid
confusion when we add more long combo tests.
fix(behaviors): Fix sticky keys quick-release for normal keypresses2021-05-09T11:52:41ZOkke Formsmaokke@formsma.nl2021-04-05T18:07:39Zurn:sha1:de4979bf58a628692547b056c80a75678005a647
Quick release for sticky keys failed for non-layer keys. The sticky key
was released just before the key that was supposed to be modified was
handled.
The issue was caused by an error in the sticky key logic, which released
the sticky key before handling the key up event.
Fixes #696.
fix(combos): Fix stuck keys when pressing long combos.2021-03-11T21:23:45ZOkke Formsmaokke@formsma.nl2021-02-27T21:34:15Zurn:sha1:0df71100581d040178bd0fe8ec0382d84dc59a40
To properly retrigger hold-taps when a combo is not activated, some
position down events are reraised instead of released. The corresponding
position up events were never reraised, causing a potential stuck key.
feature(hold-tap): no-hold-flash for retro taps2021-02-24T12:24:27ZOkke Formsmaokke@formsma.nl2021-02-09T19:20:54Zurn:sha1:0c1940bb799ec8d97bb2f80661778a1396e9277e
This is an improvement on retro-tap, solving the 'flashing hold' issue
users people experience.
When the tapping-term expires, the hold key is normally pressed. When
retro-tap is enabled, this is undesirable; only an interrupted hold-tap
should trigger the hold behavior.
This change disables the hold behavior for the 'STATUS_HOLD_TIMER'
state when retro-tap is enabled, and makes sure the
'STATUS_HOLD_INTERRUPT' state will be triggered when appropriate.
feature(hold-tap): Retro tapping2021-02-24T12:24:27ZOkke Formsmaokke@formsma.nl2021-02-06T19:58:04Zurn:sha1:89ed816c670abdc74fe02b484fe148bc5658564crefactor(hold-tap): pretty print decision_moment2021-02-24T12:24:27ZOkke Formsmaokke@formsma.nl2021-02-04T13:30:53Zurn:sha1:9c4c266b17f6fec4866d65bec0889233845b6282refactor(hold-tap): split hold state into interrupt and timer2021-02-24T12:24:27ZOkke Formsmaokke@formsma.nl2021-02-04T12:50:13Zurn:sha1:abc60fc7cb5c145bff9029a1aadd73c5adbf4a7b