libretro.h: add a sensor sub-device index for composite controllers - #19453
Open
XenuIsWatching wants to merge 1 commit into
Open
libretro.h: add a sensor sub-device index for composite controllers#19453XenuIsWatching wants to merge 1 commit into
XenuIsWatching wants to merge 1 commit into
Conversation
Some controllers carry more than one sensor of the same kind on a single port. A Wii Remote with a Nunchuk attached is one player with two accelerometers, and adding MotionPlus makes it two accelerometers and a gyroscope, but retro_sensor_interface addresses exactly one sensor of each kind per port. A second port is not an alternative, because ports denote players. Carry a sub-device index in the upper bits of the existing ID, the same way RETRO_DEVICE_SUBCLASS encodes a subclass into a device ID. Index 0 denotes the controller itself and encodes to exactly the values already in use, so every existing core and frontend is unaffected. No new environment call or capability flag is needed, because the existing contract already describes the fallback: a frontend that does not implement this returns false from retro_set_sensor_state_t and 0 from retro_sensor_get_input_t, both of which are already documented, and a core that receives either answer behaves as it does today. Cores and frontends can therefore adopt this independently of one another. Definitions only; no behaviour changes.
XenuIsWatching
added a commit
to XenuIsWatching/dolphin
that referenced
this pull request
Sep 3, 2026
A Wii Remote with a Nunchuk is one player on one port with two accelerometers, and the sensor interface addresses exactly one of each kind per port. Carry a sub-device index in the high bits of the existing id, the way RETRO_DEVICE_SUBCLASS already encodes a subclass into a device id. Index 0 encodes to exactly the values in use today, so nothing existing changes, and no environment number or capability flag is needed: a frontend that has never heard of this answers false from set_sensor_state and 0 from get_sensor_input, which is the fallback the header already documents. Mirrors libretro/RetroArch#19453; drop this patch when it lands. Header only; the reader follows.
Author
|
implementation / use case is here libretro/dolphin#484 |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Some controllers carry more than one sensor of the same kind on a single port. A Wii Remote with a Nunchuk attached is one player with two accelerometers, and adding MotionPlus makes it two accelerometers and a gyroscope, but retro_sensor_interface addresses exactly one sensor of each kind per port. A second port is not an alternative, because ports denote players.
Carry a sub-device index in the upper bits of the existing ID, the same way RETRO_DEVICE_SUBCLASS encodes a subclass into a device ID. Index 0 denotes the controller itself and encodes to exactly the values already in use, so every existing core and frontend is unaffected.
No new environment call or capability flag is needed, because the existing contract already describes the fallback: a frontend that does not implement this returns false from retro_set_sensor_state_t and 0 from retro_sensor_get_input_t, both of which are already documented, and a core that receives either answer behaves as it does today. Cores and frontends can therefore adopt this independently of one another.