[feature request] Use gamepad serial to uniquely identify pads
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 14.1k
- Forks
- 2.2k
- Avg merge
- 7h 35m
- Merged PRs (30d)
- 51
Description
Description
Currently, vid, pid and device name are the only fields we use to identify gamepads. This can be a problem when a controller goes to sleep and the driver/OS never informs RetroArch that the pad has disconnected, since it will show up as a brand new pad when it wakes back up. If we included the serial, we could uniquely identify pads to know when the same controller has reconnected, as well as potentially enable gamepad-specific remaps.
Expected behavior
When controllers go to sleep and wake back up, RetroArch sees that it's the same controller and returns it to its previous control state.
Actual behavior
RetroArch thinks it's a new controller and drops it into P2, P3, P4 ... each time it reconnects.
Steps to reproduce the bug
- connect a bluetooth controller
- let it go to sleep and then wake it back up
- it will be dropped into the P2 slot instead of P1, and you will no longer be able to control the game/menu
Bisect Results
has always happened
Version/Commit
You can find this information under Information/System Information
- RetroArch: 1.9.10 stable
Environment information
- OS: ubuntu bionic, but it happens everywhere
- Compiler: gcc
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating RetroArch's gamepad identification and reconnect handling, especially the paths that currently use VID, PID, and device name. Compare the platform input paths to determine where serial data is available. Done means a sleeping controller reconnects to its previous player slot and control state instead of being assigned a new slot.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- game-dev
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100