libretro
DS4 controller being improperly identified/mapped
First and foremost consider this:
- Only RetroArch bugs should be filed here. Not core bugs or game bugs
- This is not a forum or a help section, this is strictly developer oriented
Description
Retroarch is seeing my DS4 (when plugged into shieldTV) as a steam/nintendo USB switch pro controller and as such swapping the A/B X/Y buttons. I tracked it down to the Nintendo Switch Pro Controller USB Steam User 1.cfg autoconfig profiles which were recently added and was able to circumvent the behavior by deleting them. Obviously not an ideal long term solution as each time you'd update your autoconfig profiles you'd have to prune those out.
Expected behavior
The DS4 to be seen as an xinput controller user 1 (when used in this fashion)
Actual behavior
I have used it this way for years. Launching retroarch via steamlink on the ShieldTV. It has always picked the DS4 up as an xinput controller user # when i have it tethered via usb cable (as it should). At some point in recent history some switch/steam profiles were added and it began seeing it as a nintendo switch pro controller.
retroarch and all assets are updated to latest nightly as of immediately prior to this post
Steps to reproduce the bug
- plug your DS4 into a shieldTV via USB
- open the steam link app
- launch retroarch and notice how the controller is mis-identified/mis-mapped.
Bisect Results
[Try to bisect and tell us when this started happening]
Version/Commit
You can find this information under Information/System Information
- RetroArch: 1.88 e91e9336a9
Environment information
- OS: Win10
- Compiler: [In case you are running local builds]
Aside from the labels being backward, are the functions still where they should be? For example, does Mario jump when you press the bottom button (cross on your DS4) in SWM?
thats a negative, theyre actually functionally backwards. For example in the RA menu i have to press cancel to confirm and vice versa. This was confirmed by opening the steam/usb/nintendo switch profile/cfg and looking at the buttons assigned for button0 button1 etc and as expected, they're opposite of what they are in the xinput controller autoconfig files.
