convert core GPIO pin mappings from button-to-pin to pin-to-action #504
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bsstephan
changed the title
bsstephan
force-pushed
the
configuration-by-pins
branch
2 times, most recently
from
cf8bf11
to
5a77cdd
Compare
bsstephan
force-pushed
the
configuration-by-pins
branch
from
4220e23
to
a826aab
Compare
bsstephan
force-pushed
the
configuration-by-pins
branch
2 times, most recently
from
5bbed01
to
0839f45
Compare
this changes the core board config and gamepad behavior to be that the settings/user configures what each pin does, rather than the old behavior which configures what pin each button is assigned to. this allows for the new configuration to have one canonical location for what each of the pins does, and removes the limitation that a button can only normally be activated by one pin --- now it is trivial to assign many pins to take the same action "actions" are all button presses right now, but they may be other things in the future as this branch expands. this is just the core functionality and migration code for now, further changes (removing extra input addon, refactoring DDI, maybe refactoring the sliders, working the profiles into this scheme, etc.) to come
motivation for this is the migration sets everything to NONE anyway, so the 0 value isn't super important to us, and protobuf by convention seems to use the lowest value as a default (e.g. in the python GUI editor), so setting that to NONE is idiomatic in both cases
the rest of the DDI settings remain untouched, and the whole addon is basically where it always was, this just allows for centralization in the new GPIO mappings
ArduinoJson retains the reference to the string until write time, so it was only actually publishing the value for pin29
there's not much left of the addon other than the config for what to do when nothing is held, so, this is a great candidate for getting folded into core
- Make new pin mapping handle labels for all input modes including swapTpShareLabels
temporary measure as the addons' validation needs reworking to support a response that includes their own pins
bsstephan
changed the title
this also removes the protobuf isValidPin(foo) check and replaces it with a has_ + a nested check that it's between 0 and 29, so that if a user set a button to -1, we don't fallback to the BoardConfig.h, which would clobber their intentional unmapping
Profile settings
I believe that it would be possible, without this history, for someone to unmap certain gpioMappings (or hotkeys) for intentional reasons and then accidentally trigger a re-conversion of the old BoardConfig.h values, meaning they could never unmap certain hotkeys or gpioMappings. this bool avoids that by only running the migration code once ever maybe it makes startup faster too, idk
jack2game
added a commit
to jack2game/GP2040-CE
that referenced
this pull request
Oct 29, 2023
…penStickCommunity#504) (#11) * convert core GPIO pin mappings from button2pin to pin2action this changes the core board config and gamepad behavior to be that the settings/user configures what each pin does, rather than the old behavior which configures what pin each button is assigned to. this allows for the new configuration to have one canonical location for what each of the pins does, and removes the limitation that a button can only normally be activated by one pin --- now it is trivial to assign many pins to take the same action "actions" are all button presses right now, but they may be other things in the future as this branch expands. this is just the core functionality and migration code for now, further changes (removing extra input addon, refactoring DDI, maybe refactoring the sliders, working the profiles into this scheme, etc.) to come * remove the extra button addon, it is unnecessary now * unset deprecated pin mappings after migration * unset the extra button addon pin after migration * fix the processing of the aux state/Fn button * renumber the non-managed pin enum entries motivation for this is the migration sets everything to NONE anyway, so the 0 value isn't super important to us, and protobuf by convention seems to use the lowest value as a default (e.g. in the python GUI editor), so setting that to NONE is idiomatic in both cases * fix the unsetting of the extra input addon after migrating * convert DDI pins to gpioMappings the rest of the DDI settings remain untouched, and the whole addon is basically where it always was, this just allows for centralization in the new GPIO mappings * add TODO for fixing the pin UI * fix the checking of the DDI masks * convert get/setPinMappings API to match refactor * "hardcode" the writing of 30 pins to JSON ArduinoJson retains the reference to the string until write time, so it was only actually publishing the value for pin29 * convert the JS slider pins to the centralized config there's not much left of the addon other than the config for what to do when nothing is held, so, this is a great candidate for getting folded into core * rename default JS mode option for consistency w/SOCD slider * preliminary SOCD slider port to gpioMappings * correct JS slider migration to refer to proper config/defines * correct SOCD slider migration by referring to proper settings * Global pin state action example using zustand * Export baseUrl * Pin to action ui playground, using global state with zustand * Hide som actions from dropdown. make the select disabled if action is set from board * Add a form for semantics * Add translation for labels, dynamic columns. * Remove pin -> action PoC from playground * Make savePins return promise * Replace pin mapping with pin -> action * Remove unused handler in usePinStore * remove DDI pins from addon page, point at Pin Mapping page * add more add-on pin usages to the UI * flag miscellaneous addon pins as ASSIGNED in migration * when saving addons/display pins in web config, mark them ASSIGNED * don't allow profiles to touch RESERVED/ASSIGNED_TO_ADDON this is partially a problem now (we shouldn't let a profile assign a pin that is normally reserved or on a addon), and partially a problem in the future (we shouldn't let a profile SET a pin to reserved/for an addon), when the profiles are refactored to use gpio mappings * Add better typing for usePinStore * - Create a new Capture button component that is reusable for any input. - Make new pin mapping handle labels for all input modes including swapTpShareLabels * don't include ASSIGNED_TO_ADDON in getUsedPins temporary measure as the addons' validation needs reworking to support a response that includes their own pins * don't allow setPinMappings to set/change addon/reserved pins * addons API shouldn't refer to DDI pins anymore now that they're "core" * remove unused API stuff from the dev server JSON * DRY on the simple protobuf-or-boardconfig pin migrations this also removes the protobuf isValidPin(foo) check and replaces it with a has_ + a nested check that it's between 0 and 29, so that if a user set a button to -1, we don't fallback to the BoardConfig.h, which would clobber their intentional unmapping * set ASSIGNED_TO_ADDON -> NONE if the new addon pin is invalid * un-ASSIGNED_TO_ADDON the Dminus pins when unsetting the Dplus pins * Remove double call on context * Remove useState for selectedBoard as it's only set once * Remove unused imports * Remove setLoading on getPinMappings as this creates race conditions, remove log * Map new pin actions to button mappings for profile settings * Remove unused lodash import * Remove export * remove unused EXTRA_BUTTON_ENABLED define * track when migrations have occurred I believe that it would be possible, without this history, for someone to unmap certain gpioMappings (or hotkeys) for intentional reasons and then accidentally trigger a re-conversion of the old BoardConfig.h values, meaning they could never unmap certain hotkeys or gpioMappings. this bool avoids that by only running the migration code once ever maybe it makes startup faster too, idk * remove unnecessary save()s in slider addons * define types for a pin and a gamepad mask --------- Co-authored-by: Brian S. Stephan <bss@incorporeal.org> Co-authored-by: ian <ian@vidales.se>
jack2game
pushed a commit
to jack2game/GP2040-CE
that referenced
this pull request
Nov 1, 2023
…penStickCommunity#504) * convert core GPIO pin mappings from button2pin to pin2action this changes the core board config and gamepad behavior to be that the settings/user configures what each pin does, rather than the old behavior which configures what pin each button is assigned to. this allows for the new configuration to have one canonical location for what each of the pins does, and removes the limitation that a button can only normally be activated by one pin --- now it is trivial to assign many pins to take the same action "actions" are all button presses right now, but they may be other things in the future as this branch expands. this is just the core functionality and migration code for now, further changes (removing extra input addon, refactoring DDI, maybe refactoring the sliders, working the profiles into this scheme, etc.) to come * remove the extra button addon, it is unnecessary now * unset deprecated pin mappings after migration * unset the extra button addon pin after migration * fix the processing of the aux state/Fn button * renumber the non-managed pin enum entries motivation for this is the migration sets everything to NONE anyway, so the 0 value isn't super important to us, and protobuf by convention seems to use the lowest value as a default (e.g. in the python GUI editor), so setting that to NONE is idiomatic in both cases * fix the unsetting of the extra input addon after migrating * convert DDI pins to gpioMappings the rest of the DDI settings remain untouched, and the whole addon is basically where it always was, this just allows for centralization in the new GPIO mappings * add TODO for fixing the pin UI * fix the checking of the DDI masks * convert get/setPinMappings API to match refactor * "hardcode" the writing of 30 pins to JSON ArduinoJson retains the reference to the string until write time, so it was only actually publishing the value for pin29 * convert the JS slider pins to the centralized config there's not much left of the addon other than the config for what to do when nothing is held, so, this is a great candidate for getting folded into core * rename default JS mode option for consistency w/SOCD slider * preliminary SOCD slider port to gpioMappings * correct JS slider migration to refer to proper config/defines * correct SOCD slider migration by referring to proper settings * Global pin state action example using zustand * Export baseUrl * Pin to action ui playground, using global state with zustand * Hide som actions from dropdown. make the select disabled if action is set from board * Add a form for semantics * Add translation for labels, dynamic columns. * Remove pin -> action PoC from playground * Make savePins return promise * Replace pin mapping with pin -> action * Remove unused handler in usePinStore * remove DDI pins from addon page, point at Pin Mapping page * add more add-on pin usages to the UI * flag miscellaneous addon pins as ASSIGNED in migration * when saving addons/display pins in web config, mark them ASSIGNED * don't allow profiles to touch RESERVED/ASSIGNED_TO_ADDON this is partially a problem now (we shouldn't let a profile assign a pin that is normally reserved or on a addon), and partially a problem in the future (we shouldn't let a profile SET a pin to reserved/for an addon), when the profiles are refactored to use gpio mappings * Add better typing for usePinStore * - Create a new Capture button component that is reusable for any input. - Make new pin mapping handle labels for all input modes including swapTpShareLabels * don't include ASSIGNED_TO_ADDON in getUsedPins temporary measure as the addons' validation needs reworking to support a response that includes their own pins * don't allow setPinMappings to set/change addon/reserved pins * addons API shouldn't refer to DDI pins anymore now that they're "core" * remove unused API stuff from the dev server JSON * DRY on the simple protobuf-or-boardconfig pin migrations this also removes the protobuf isValidPin(foo) check and replaces it with a has_ + a nested check that it's between 0 and 29, so that if a user set a button to -1, we don't fallback to the BoardConfig.h, which would clobber their intentional unmapping * set ASSIGNED_TO_ADDON -> NONE if the new addon pin is invalid * un-ASSIGNED_TO_ADDON the Dminus pins when unsetting the Dplus pins * Remove double call on context * Remove useState for selectedBoard as it's only set once * Remove unused imports * Remove setLoading on getPinMappings as this creates race conditions, remove log * Map new pin actions to button mappings for profile settings * Remove unused lodash import * Remove export * remove unused EXTRA_BUTTON_ENABLED define * track when migrations have occurred I believe that it would be possible, without this history, for someone to unmap certain gpioMappings (or hotkeys) for intentional reasons and then accidentally trigger a re-conversion of the old BoardConfig.h values, meaning they could never unmap certain hotkeys or gpioMappings. this bool avoids that by only running the migration code once ever maybe it makes startup faster too, idk * remove unnecessary save()s in slider addons * define types for a pin and a gamepad mask --------- Co-authored-by: ian <ian@vidales.se>
jack2game
added a commit
to jack2game/GP2040-CE
that referenced
this pull request
Nov 2, 2023
* Add Rotate, update doc, separate SOCD for LS&RS * Indentation * Indentation * convert core GPIO pin mappings from button-to-pin to pin-to-action (OpenStickCommunity#504) * convert core GPIO pin mappings from button2pin to pin2action this changes the core board config and gamepad behavior to be that the settings/user configures what each pin does, rather than the old behavior which configures what pin each button is assigned to. this allows for the new configuration to have one canonical location for what each of the pins does, and removes the limitation that a button can only normally be activated by one pin --- now it is trivial to assign many pins to take the same action "actions" are all button presses right now, but they may be other things in the future as this branch expands. this is just the core functionality and migration code for now, further changes (removing extra input addon, refactoring DDI, maybe refactoring the sliders, working the profiles into this scheme, etc.) to come * remove the extra button addon, it is unnecessary now * unset deprecated pin mappings after migration * unset the extra button addon pin after migration * fix the processing of the aux state/Fn button * renumber the non-managed pin enum entries motivation for this is the migration sets everything to NONE anyway, so the 0 value isn't super important to us, and protobuf by convention seems to use the lowest value as a default (e.g. in the python GUI editor), so setting that to NONE is idiomatic in both cases * fix the unsetting of the extra input addon after migrating * convert DDI pins to gpioMappings the rest of the DDI settings remain untouched, and the whole addon is basically where it always was, this just allows for centralization in the new GPIO mappings * add TODO for fixing the pin UI * fix the checking of the DDI masks * convert get/setPinMappings API to match refactor * "hardcode" the writing of 30 pins to JSON ArduinoJson retains the reference to the string until write time, so it was only actually publishing the value for pin29 * convert the JS slider pins to the centralized config there's not much left of the addon other than the config for what to do when nothing is held, so, this is a great candidate for getting folded into core * rename default JS mode option for consistency w/SOCD slider * preliminary SOCD slider port to gpioMappings * correct JS slider migration to refer to proper config/defines * correct SOCD slider migration by referring to proper settings * Global pin state action example using zustand * Export baseUrl * Pin to action ui playground, using global state with zustand * Hide som actions from dropdown. make the select disabled if action is set from board * Add a form for semantics * Add translation for labels, dynamic columns. * Remove pin -> action PoC from playground * Make savePins return promise * Replace pin mapping with pin -> action * Remove unused handler in usePinStore * remove DDI pins from addon page, point at Pin Mapping page * add more add-on pin usages to the UI * flag miscellaneous addon pins as ASSIGNED in migration * when saving addons/display pins in web config, mark them ASSIGNED * don't allow profiles to touch RESERVED/ASSIGNED_TO_ADDON this is partially a problem now (we shouldn't let a profile assign a pin that is normally reserved or on a addon), and partially a problem in the future (we shouldn't let a profile SET a pin to reserved/for an addon), when the profiles are refactored to use gpio mappings * Add better typing for usePinStore * - Create a new Capture button component that is reusable for any input. - Make new pin mapping handle labels for all input modes including swapTpShareLabels * don't include ASSIGNED_TO_ADDON in getUsedPins temporary measure as the addons' validation needs reworking to support a response that includes their own pins * don't allow setPinMappings to set/change addon/reserved pins * addons API shouldn't refer to DDI pins anymore now that they're "core" * remove unused API stuff from the dev server JSON * DRY on the simple protobuf-or-boardconfig pin migrations this also removes the protobuf isValidPin(foo) check and replaces it with a has_ + a nested check that it's between 0 and 29, so that if a user set a button to -1, we don't fallback to the BoardConfig.h, which would clobber their intentional unmapping * set ASSIGNED_TO_ADDON -> NONE if the new addon pin is invalid * un-ASSIGNED_TO_ADDON the Dminus pins when unsetting the Dplus pins * Remove double call on context * Remove useState for selectedBoard as it's only set once * Remove unused imports * Remove setLoading on getPinMappings as this creates race conditions, remove log * Map new pin actions to button mappings for profile settings * Remove unused lodash import * Remove export * remove unused EXTRA_BUTTON_ENABLED define * track when migrations have occurred I believe that it would be possible, without this history, for someone to unmap certain gpioMappings (or hotkeys) for intentional reasons and then accidentally trigger a re-conversion of the old BoardConfig.h values, meaning they could never unmap certain hotkeys or gpioMappings. this bool avoids that by only running the migration code once ever maybe it makes startup faster too, idk * remove unnecessary save()s in slider addons * define types for a pin and a gamepad mask --------- Co-authored-by: ian <ian@vidales.se> * Update with v0.7.5 latency testing (OpenStickCommunity#605) Tests were done using Ferals optamized testing sketch found here: https://github.com/FeralAI/usblag_optimized/blob/main/usblag_optimized.ino * Input Macro Add-on Button labels (OpenStickCommunity#603) * Fix for missing value in input macro add-on page * - Allow capture button to not have any text if small prop - Send one label for macro page - Align button and inputs on macro page --------- Co-authored-by: ian <ian@vidales.se> --------- Co-authored-by: Brian S. Stephan <bss@incorporeal.org> Co-authored-by: ian <ian@vidales.se> Co-authored-by: TheTrain <32771064+TheTrainGoes@users.noreply.github.com> Co-authored-by: Luke Arntson <arntsonl@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this changes the core board config and gamepad behavior to be that the settings/user configures what each pin does, rather than the old behavior which configures what pin each button is assigned to. this allows for the new configuration to have one canonical location for what each of the pins does, and removes the limitation that a button can only normally be activated by one pin --- now it is trivial to assign many pins to take the same action
"actions" are all button presses right now, but they may be other things in the future as this branch expands. this is just the core functionality and migration code for now, further changes (removing extra input addon, refactoring DDI, maybe refactoring the sliders, working the profiles into this scheme, etc.) to come