Allow multiple process_record() calls per scan #2022
Conversation
seebs
force-pushed
the
seebs/multikey
branch
from
459816b to
a212262
Compare
|
okay, this one has a humorous error too, note the "static" on keys_processed, that shouldn't be there. will resend. |
keyboards/ergodox_ez/config.h
Outdated
| @@ -114,5 +114,6 @@ along with this program. If not, see <http://www.gnu.org/licenses/>. | |||
| //#define NO_ACTION_MACRO | |||
| //#define NO_ACTION_FUNCTION | |||
| //#define DEBUG_MATRIX_SCAN_RATE | |||
| #define QMK_KEYS_PER_SCAN 8 | |||
There was a problem hiding this comment.
Could we put this in a specific keymap and not in the overriding config.h? I am concerned of potential effects on our many users.
|
Just asked for it to be excluded from the default config.h and made available as an option. |
docs/config_options.md
Outdated
| @@ -123,6 +123,9 @@ If you define these options you will enable the associated feature, which may in | |||
| * how many taps before oneshot toggle is triggered | |||
| * `#define IGNORE_MOD_TAP_INTERRUPT` | |||
| * makes it possible to do rolling combos (zx) with keys that convert to other keys on hold | |||
| * `#define QMK_KEYS_PER_SCAN` | |||
| * Allows sending more than one key per scan. (By default, only one key event gets | |||
| sent via `process_record()` per scan.) | |||
There was a problem hiding this comment.
Could you elaborate on the effects of this in actual use here? Like, what's it good for, specifically, from the standpoint of a layperson mashing keys?
|
If you're mashing a LOT of keys... not much. If you're mashing a ton of keys, and you have an LCD hooked up and being updated by the firmware on scan, and it does work only when there's changes, and that work takes time, it goes from "you can watch the key states change" to "basically instant". But if you're a really fast typist, this could start showing up in cases where you type stupidly fast. Moreso without the related performance hacks, because the ergodox's scan rate is unusually slow. Basically, right now, the absolute theoretical maximum key-processing rate is about 150 key state changes per second. And you'd think that wouldn't matter much, but like, there's a guy on typeracer who has been filmed typing, and he really is able to type "kno" fast enough that the software does not detect even one millisecond between those key activations. on an ergodox, the theoretical minimum would be about 4-6ms, because only one key record can happen at a time, and the next one would wait for the next scan. Impact is probably pretty minor for most use cases. |
|
That makes sense. The "need" for KEYS_PER_SCAN became less severe anyway with the other performance changes. And yeah, I can see some TINY advantages to the doc change being more complete. |
This is particularly relevant for, e.g., the ergodox EZ and other keyboards with slow scan rates. Without changing the API or behavior of individual process_record() calls, we allow a configuration flag to make multiple calls in a single scan. This will probably have miniscule effects on non-steno users, and it's not enabled by default for any keyboards. Added note about it to ergodox README. Signed-off-by: seebs <[email protected]>
seebs
force-pushed
the
seebs/multikey
branch
from
a212262 to
db07b6f
Compare
|
Revised commit, repushed branch. |
|
Perfect! Thanks :) |
|
Should help improve issue in #910 |
This is particularly relevant for, e.g., the ergodox EZ and
other keyboards with slow scan rates. Without changing the API or
behavior of individual process_record() calls, we allow a
configuration flag to make multiple calls in a single scan.
This will probably have miniscule effects on non-steno users,
and it's not enabled by default for any keyboards except
the one where it was causing me trouble.
(Relevant to issue #1476)
Signed-off-by: seebs [email protected]