This is a complete rework of how Kaleidoscope is built, but should be largely transparent to most developers and completely invisible to folks using the Arduino IDE.
Some advanced features of kaleidoscope-builder config files have gone away, but it’s likely that @algernon was the only person using them. The tradeoff is that we’re now using a much better maintained build tool under the hood and that we’re no longer as tied to a single specific directory structure.
The greedy match was including whitespace if more than one space character
separated the "keyswitch" token and the first coordinate.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
The virtual hardware device, unlike others, was calling `handleKeyswitchEvent()`
for every keyswitch, every cycle. It should suppress calls corresponding to idle
keyswitches, just like the other devices.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Even if a testcase shouldn't generate any HID reports, we should verify that it
didn't. If it does generate a report when there are none expected, that test
should fail.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
The code example was using an outdated header for `tapDanceAction` that used `row` and `col`.
Updated to use `key_addr` instead.
Solution found in this forum reply: https://community.keyboard.io/t/status-of-using-tapdance-with-chrysalis/4143/5
Signed-off-by: Pedro Diogo <158898+PedroDiogo@users.noreply.github.com>
This replaces the `CHECK_EXPECTED_REPORTS()` macro with a new `CheckReports()`
method. The new method verifies both the content and timestamps of expected
keyboard reports, and provides more output on failures (including details of any
unexpected reports).
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
The code for guarding against integer overflow on the prior interval timestamp
was in the wrong place, and wouldn't get executed on cycles when the keyboard
was idle, leading to a very slim chance of getting the wrong qukey value if all
keys were idle long enough (65 seconds).
Also fixed the same problem in the first quarter-second after the keyboard power
on. Not likely to ever be observed, but costs nothing extra to fix.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Jesse Vincent
Michael Richters
Pedro Diogo