Retroarch: DInput/XInput confusion when creating autoconfig files.

[bslenul]

Description

If you have a controller connected in DInput mode while "xinput" is selected as controller driver in RetroArch, if you create an autoconfig it will create it for "xinput", and if you unplug/replug the controller it will say "not configured" because it will look for an autoconfig inside the "dinput" folder.

So basically you can create the autoconfig but it can't be loaded, unless you move it to "dinput" folder afterwards.

Expected behavior

Either check the "xinput" folder when loading the autoconfig even if the controller itself is using DInput, or create the autoconfig inside the "dinput" folder.

Actual behavior

It creates the autoconfig in "xinput" folder which is not being read when plugging a DInput controller even with "xinput" selected as controller driver.

Steps to reproduce the bug

1. Delete/move content of the "autoconfig" folder and create 2 folders: "dinput" and "xinput". That's to make sure there's no conflict with existing autoconfigs.
2. Make sure RA controller driver is set to "xinput".
3. Plug a controller in DInput mode (a DS4 without DS4Windows or a 8Bitdo controller started in DInput mode for example).
4. Bind everything or anything, doesn't really matter as long as the file is being created :p
5. Save autoconfig, reset to defaults, unplug/replug controller... it will say "not configured".
6. Check your autoconfig folders, "dinput" should be empty but "xinput" should have the autoconfig file.

Here's a video of the whole process with my DS4: https://streamable.com/5okhzz

Bisect Results

I could bisect later or tomorrow, but it's pretty recent, probably started with the autoconfig changes made not long ago.
edit: It started here: 9b1edc5eee0359b46785f31b1d627e9869439ae7

Version/Commit

• RetroArch: 1.8.9 / ed3ee25

Environment information

• OS: Windows 10

[bslenul]

OK, bisect done, looks like it started here: 9b1edc5eee0359b46785f31b1d627e9869439ae7
Before that the autoconfig loads fine from the "xinput" folder.

[Sanaki]

While I can't speak for the viability, functionally it seems preferable to have them continue to load dinput from the dinput directory, and instead fix saving to go in the correct directory. This does mean some autoconfig profiles will need to be moved, but it also needs to be done only once and will significantly improve the usability of the dinput driver in the process.

[hizzlekizzle]

This one might be tricky to fix, since xinput and dinput overlap somewhat in the backend.

[bslenul]

it seems preferable to have them continue to load dinput from the dinput directory, and instead fix saving to go in the correct directory

Yeah that's what would make more sense IMO, log file says [INFO] [Joypad]: Found joypad driver: "dinput". when I plug the controller so it looks like RA is fully aware that it's using dinput, so I guess it would be doable to save in the "dinput" folder instead of "xinput" somehow? Although I know that it's not always as easy as it seems from a user POV to fix stuff...

[jdgleaver]

Sigh... More Windows nonsense... :(

It seems the conjoined nature of xinput and dinput means the user-set controller driver is ignored, and instead auto-selected based on the connected hardware. No other platform does this. The autoconfig save routine uses the set value, so when the driver autoselects something else, the wrong directory is used.

We just need to change the autoconfig save routine so that it queries the setting from the driver itself. In principle this is a trivial thing, but getting the driver ident string is a bit fiddly and annoying. I'm in the middle of another PR at the moment, but I'll try to get a fix done later today or tomorrow.

[jdgleaver]

A tiny update: it turns out that this is a bit more involved than I thought, and my last PR took longer than expected to finish - so I won't have time to get the bug fixed this week... But I know exactly how to do it now, so I'll get it wrapped up on Monday :)

[bslenul]

Hey! Thanks for the heads up, and good luck on your other PR! :p

[jdgleaver]

Okay, this should solve the problem: #11135

Let me know if there are any remaining issues :)

[bslenul]

Yup, I just gave it a try, autoconfig is correctly created in the "dinput" folder now! Can't spot any issue atm but sure, I'll let you know if I can find any.

And a big thank you, as usual :D

[jdgleaver]

You're very welcome!

Thanks for testing ;)