Confusion with creating input autoconfig profiles

RetroArch Windows devices
#1

So this is my first time using the autoconfig feature and I’m having a hard time understading what is going on with autoconfig profiles. I bought the new 8bitdo m30 controller and realized that no autoconfig profile for it exists. Unless I’m blind, I don’t think I see any option for creating a new profile so I went to the autoprofile directory and made a new profile mysql, supplying the correct vendor and product IDs. When I boot up retroarch again, it shows that it loads the profile correctly. I use a keyboard to navigate to Input > Input User 1 Binds and start binding the buttons. When I select “User 1 Save Autoconfig” though, instead of overwriting my blank m30 config (Device Index shows the m30 display name I put in my custom config btw), it creates a new file called “XInput Controller (User 1).cfg”.The m30 is the only controller I have plugged.

I tested this with a different controller, a dualshock 4 and when I choose the “User 1 Save Autoconfig” option without changing anything, it creates a new, different file instead named “Wireless Controller.cfg”. I tried an Xbox One controller and it too creates a new file called “XBOX One Controller (User 1).cfg”

Is this a bug or something I’m missing? This is on 1.7.5 by the way

#3

8Bitdo pads will report different vid:pid pairs based on the pairing mode, I think. So, try pairing it as different stuff until it says the name of the actual pad when connected.

#4

Choosing Save Autoconfig is how to create a new autoconfig file. The process is described more fully on this page: https://www.retroarch.com/index.php?page=joypad-autoconfig

#5

Hmm, so using the retroarch UI doesn’t allow you to make changes to existing profiles? I can probably get around things by renaming files to what I want manually but I was wondering if all of this was possible through retroarch.

#6

Let an existing autoconfig load. Then change the bindings to what you want them to be in the UI. Then select User 1 Save Autoconfig to save the modifications.

#7

Like I said, that doesn’t seem to update the profile that gets autoloaded. It creates a new file called Xinput Controller User 1 instead with the vid and pid values of the profile that got autoloaded

#8

As mentioned above, this is a result of using the xinput input driver which names autoconfig files based on the controller name as seen by your system.When you manually created an autoconfig called mysql you should have called the file Xinput Controller User 1 instead if it is for use with xinput.

RetroArch was generous enough (although maybe this is more confusing than helpful) to load the incorrectly named autoconfig you made, but not smart enough to keep using the incorrect name when you tried to save the modifications.

edit: If you had created your autoconfig entirely from within the UI from the beginning this scenario would not have happened and all would be working as expected, I think. I’d suggest deleting the autoconfig and trying to work entirely from within the UI to see if your results are more consistent.

1 Like
#9

I see. Hmm, will give it a shot again later today.

How about the dualshock 4 thing I mentioned? Attempting to save an autoconfig controller with it creates a new file called “Wireless Controller” instead of overwriting the existing Dualshock 4 cfg file

#10

I finally was able to create an autoconfig profile that maps perfectly with the Saturn Beetle core, but the mapping is all over the place when used with a Genesis core. I guess I have to rely on a per-core config remapping or something.

Something I noticed though: when running retroarch via command line with a core and game passed via flags, the Input Binds menu reflect the running core properly (eg. with the Saturn Beetle core, you see bindings for A, B, C, X, Y, Z, L, R). This makes it easier to map the controller accordingly. Other options seem to appear depending on the core.

When loading a core manually though (open retroarch, then load core and a supported game), the interface does not change to accomodate the running core. I only noticed this because I was using launchbox and was trying to figure out why the interface appears slightly different between that and running retroarch on it’s own.

Edit: Just realized that you could do core remaps too without messing with the configured controller profile. Learn something new everyday

#11

This is normal. It is using the device name as read by the system. It could be from the device firmware itself or the driver, not sure. In any case, you are not doing anything wrong.

Also the file name is part of the ‘scoring’ system that Retroarch uses to determine which autoconfig profile it selects, so I recommend you leave this name to guarantee that it is chosen.

For a better experience you can edit it to set the button labels. I have my own DS4 cfg’s for reference here.

#12

I think these 8bitdo controllers are not kind to retroarch. I also have an sf30pro and noticed that retroarch reads the exact same vid/pid from it as the new m30, so they end up sharing/using the same configurations.

I wonder if this is a case where 8bitdo just uses an existing xinput vid/pid. But it’s weird since I do see autoconf profiles for the sf30pro/sn30pro controllers already part of the repo and the numbers in there do not match what I see.

#14

Yes, that’s what I was referring to here. In Xinput mode, it reports a generic 360 pad vid:pid. In Nintendo mode, it’s a generic Wii U Pro controller, etc. You need to find the mode that actually says what it is (I think Android/PC mode is usually good).

1 Like
#15

Indeed, I use DS4 and 8bitdo with udev and they work well, both with USB and Bluetooth connections.