-
-
Notifications
You must be signed in to change notification settings - Fork 39.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor steno and add STENO_PROTOCOL = [all|txbolt|geminipr]
#17065
Conversation
This breaks some conventions and assumptions the CLI makes about STENO_ENABLE = yes|no
STENO_DRIVER = gemini|bolt|etc |
Is PS: just to be clear, the rules.mk entries of the current state of the PR are not: STENO_ENABLE = GEMINI|BOLT|ALL Each protocol is a separate yes|no |
3c9c694
to
7956242
Compare
|
STENO_ENABLE_[ALL|GEMINI|BOLT]
STENO_PROTOCOL = [all|txbolt|geminipr]
The |
a8039b5
to
2c6e4e5
Compare
TXBOLT is a better name but BOLT is more consistent with the pre-existing TX Bolt related constants, which all drop the "TX " prefix
This is done so that existing keymaps invoking `steno_set_mode` don't all suddenly break
d73d50a
to
7600b65
Compare
(Last force push was to simply rebase the PR on top of latest develop) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the refactor and LGTM!
A additional request, it would be great if this PR could add the data driver equivalents for STENO_ENABLE
and STENO_PROTOCOL
to info_rules.json
along with the json schema validations in keyboard.jsonschema
. Would you mind adding these?
c39ef31
to
d2bd890
Compare
(Thanks dnaq)
d2bd890
to
16f19cd
Compare
…17065) * Refactor steno into STENO_ENABLE_[ALL|GEMINI|BOLT] * Update stenography documentation * STENO_ENABLE_TXBOLT → STENO_ENABLE_BOLT TXBOLT is a better name but BOLT is more consistent with the pre-existing TX Bolt related constants, which all drop the "TX " prefix * Comments * STENO_ENABLE_[GEMINI|BOLT|ALL] → STENO_PROTOCOL = [geminipr|txbolt|all] * Add note on lacking V-USB support * Clear chord at the end of the switch(mode){send_steno_chord} block * Return true if NOEVENT * update_chord_xxx → add_xxx_key_to_chord * Enable the defines for all the protocols if STENO_PROTOCOL = all * Mention how to use `steno_set_mode` * Set the default steno protocol to "all" This is done so that existing keymaps invoking `steno_set_mode` don't all suddenly break * Add data driver equivalents for stenography feature * Document format of serial steno packets (Thanks dnaq) * Add missing comma
…17065) * Refactor steno into STENO_ENABLE_[ALL|GEMINI|BOLT] * Update stenography documentation * STENO_ENABLE_TXBOLT → STENO_ENABLE_BOLT TXBOLT is a better name but BOLT is more consistent with the pre-existing TX Bolt related constants, which all drop the "TX " prefix * Comments * STENO_ENABLE_[GEMINI|BOLT|ALL] → STENO_PROTOCOL = [geminipr|txbolt|all] * Add note on lacking V-USB support * Clear chord at the end of the switch(mode){send_steno_chord} block * Return true if NOEVENT * update_chord_xxx → add_xxx_key_to_chord * Enable the defines for all the protocols if STENO_PROTOCOL = all * Mention how to use `steno_set_mode` * Set the default steno protocol to "all" This is done so that existing keymaps invoking `steno_set_mode` don't all suddenly break * Add data driver equivalents for stenography feature * Document format of serial steno packets (Thanks dnaq) * Add missing comma
Description
Refactor
quantum/process_keycode/process_steno.*
so that it's easier to read and more firmware space efficient (cut the compile size by ~15% if compiling all protocols and by ~50% if compiling only a single protocol) and give the possibility to users to compile only a single protocol because it's wasteful to compile all available steno protocols even if you plan to use only one — after discussing with some folks on the Plover discord, I came to the conclusion that there are little to no use cases to the ability of switching serial protocols on the fly so using only a single serial protocol is by far the most common use case.I also fixed a bug wherein the
n_pressed_keys
value given to thepostprocess_steno_user
hook was off by 1. Speaking ofpostprocess_steno_user
, shouldn't we rename this topost_process_steno_user
? I avoided doing it here as that would be a breaking change but that'd be more consistent with all the other availablepost_process_*
hooks.Types of Changes
Issues Fixed or Closed by This PR
Checklist