Help with Understanding/Creating autoconfig Mappings

I’ve been exceedingly impressed with RetroArch’s performance and modular, multiple-core setup. I have my living room retro gaming experience working quite beautifully now, thanks to Steam Link. However, after getting most of my cores properly configured and working smoothly, I finally decided to try working in some gamepads other than my default XBox 360 controller (wired at the computer, 4x wireless at the TV). I was sorely disappointed to discover how difficult this part of the process is, compared to everything else… I’m running RetroArch 1.3.6 on Windows 10, by the way.

As mentioned above, I have a wired XB360 gamepad and a XB360 wireless receiver that works mostly without issue. I foresee a tad bit of a headache when it comes to mapping all 4 wireless controllers within the RGUI, but I am confident I can get it done… The problem is that I have a number of generic USB controllers that I am trying/planning to setup with the various cores. I have an N64 USB adapter, USB SNES gamepads, USB NES pads, an Atari 2600 USB adapter, and a couple different USB Genesis/Saturn gamepads. So far I’ve only tried setting up the N64 controllers & adapter, and one USB SNES controller, but neither went very well at all. The N64 adapter & controllers get configured when RetroArch starts, but the only way I can find to edit the mappings is in the in-game RGUI menu and I can’t tell it “bind this button” then have it ask me for an input, it only has a few options for each button that I have to cycle through, and the button names on either side are quite confusing and the selection for each input is far too limited; e.g. I could not bind any of the c-buttons to any of the c-buttons. The USB SNES controller just gets reported as unconfigured when I start RetroArch.

I’ve peeked at a few of the files in RetroArch’s autoconfig directory. I don’t understand if there’s a reason that some files list the mappings line by line, and some seem to have no whitespace between fields. I also vaguely understand the concept of the Retropad, which I’m guessing most of these autoconfig files map to, but for the likes of an N64 controller, I don’t see any C buttons or Z button (though I imagine those could be mapped to the second stick and L or select, or something, then tested and sorted out in the RGUI). I see a “Generic_SNES_USB_Controller.cfg” file, but clearly that’s not the same as MY generic SNES USB controller. And I can only guess that most of my other controllers will offer similar headaches. So I’m wondering how one goes about creating an autoconfig file from scratch, so I can manually map the inputs myself. Like, what fields/intputs are required/available? How do you determine what “input_driver” to use? How do you find the “input_vendor_id” & “input_product_id”? How do you find the labels for the buttons returned by the controller? General syntax rules, etc.?

I recently decided to try just using a standalone emulator (BSNES) rather than the RetroArch core, with hopes that the input keymapping procedure would be simpler, but for some reason the emulator’s performance was absolutely abysmal compared to how the RetroArch version handles it. So, it seems, I’m stuck with RetroArch. But I really want to get all my other gamepads working with it. So I’d greatly appreciate any advice or assistance anyone might be able to offer me on the matter.

Thank you!

You can usually create an autoconfig profile right from RetroArch and it will be applied the next time you launch. Go to settings > input > input user 1 binds > bind all and then just map your pad as normal. Once it’s all mapped out, it ‘user 1 save autoconfig’ and that will create the profile.

The ‘driver’ is whatever your joypad driver is using in settings > driver (on linux it’s usually udev, on Windows it’s usually xinput).

For your N64 pad, if it’s autoconfigured, you shouldn’t need to do anything. It should already be mapped properly.

1 Like

Thanks. I might try that with the N64 pad, but like I said, some of the input names are very unclear. It’s definitely not mapped properly for N64 games. If I recall, only one button did anything at all in-game, might have been none. Neither the D-pad nor the stick worked to move/navigate.

And what about the unconfigured USB SNES controller? If it’s unconfigured, it seems to be unable to register in the RGUI at all… Or was that what the “bind all” instructions were for? Will that process accept the inputs even if the RGUI doesn’t seem to recognize them?

EDIT: Alright, so I tried using the “bind all” option for my “not configured” USB SNES gamepad, but as expected, it did not recognize any of the inputs… How does one get a new, previously unused/untested controller added to the autoconfigs? There seems to be no way to interface with unsupported generic gamepads to add support. I’m willing to script an autoconfig from scratch, but I don’t know where to start, how to determine the vendor ID, product ID, etc.

EDIT #2: So I tried again because I realized it was still set to “RetroPad w/ Analog” and X-Input in the mapping menu. I switched it to “RetroPad” and “Gamepad 0” or whatever the other option was, that seemed to do the trick. I was able to bind all the buttons on my USB SNES gamepad. I saved the autoconfig, quit, then reloaded RetroArch. The bindings still worked, but the yellow text about that controller, as RA starts, still says “not configured”. Then as soon as I start a game, whether through RetroArch or a different graphical frontend, everything seems to be reset and the USB SNES controller is rendered useless again. Within the in-game RGUI mini menu, the only way to change button bindings is to toggle between options for each button, there’s no option to bind all, or any way to have it query for an input to bind.

Also, I’m realizing that there seems to be no way to have the inputs from multiple controllers mapped simultaneously for hotpluggability. It seems like, even if I figure out how to get the other gamepads mapped, it’s something I’m going to have to redo every time I want to use one of them… My hope/plan was to use my XB360 gamepads as the default controllers, since they are the easiest, most universally supported, and are wireless in the living room. But I was hoping to be able to just plug any of my other pre-mapped USB gamepads in, depending on what game/system I’m emulating, and have it just work (possibly along side the still-connected XB360 pads) without having to go through the mapping process all over again.

Wow, this is a frustrating, confusing process.

Dunno why it can’t find your autoconfig file once you’ve created it. Can you look in your autoconfig directory and see if it created it successfully?

The usecase you’ve described is very doable, once you have autoconfig profiles for all of your pads. You only have to map them each to the retropad once, save the autoconfig, and then whenever you plug one in, it will re-load that mapping.

The core input remapping moves the core’s inputs around on the retropad and, yes, you have to cycle through the available buttons manually because it can’t listen for inputs.

2 Likes

Thanks again. My confidence is bolstered once again… I will take a look when I get another chance.

UPDATE: I tried the “bind all” process on the USB SNES pad again and verified that it did in fact create and save an autoconfig file. However, the file is just called “XInput Controller (User 1).cfg” and is in the xinput directory right next to one of the default files, “XInput_Controller_User_1.cfg”… I had to switch from XInput for user 1 in the input settings to “usb gamepad (#1)”, so it’s weird to me that the 2 names don’t match at all. Anyway, The bindings seems to stick and get set automatically now. I had to “bind all” a second time from the RGUI’s full input settings from within a game, but those now seem to stick, too (even though I forgot to save the autoconfig file again from there). However, now the XB360 controller doesn’t work in-game or in the RGUI (if I set it back to XInput, it does, but the bindings are all messed up (still same as the USB SNES pad), and I have to bind all to default or re-bind all again) I even tried unplugging the SNES pad and restarting RetroArch, but the mappings are still locked into the SNES controller.

Is there really a way to make the various controllers actually hotswappable? I really don’t see any way that this is possible.

Oh, I think I just realized why I needed to “bind all” that second time. I think I still had my XB360 pad connected before I realized that it would be using whichever pad is plugged in first for user 1. It was probably confusing it, having both connected. And as I recall, it was reporting about the XInput 360 pad first, so the bindings and autoconfig i had saved before probably WERE getting applied but to user 2, rather than user 1… I’m a doofus. Sorry.

I appreciate this is an old thread, but I wanted to add that I find the input system complicated, uninituitive, and inflexible. I have nothing but love for the RA team, but I would like to add my testimony here.

I’ve spent 2 years (on and off) working on a standalone input server that maps raw input devices with both the corresponding dinput index (how RA enumerates controllers) and xinput user index (1 - 4) where applicable.

I do this to build a bespke RA config file just prior to launching RA. My emulator frontend manages this, and it works great with MAME.

But - even knowing (and assigning) the dinput index of, say, my connected xbox one controller, and setting the joypad_driver to ‘xinput’, i am having issues.

Again - this isn’t a slant on the devs behind RA. I feel hugely indebted for their countless hours of work. But, man… autoconfigs or not… I just can’t get xinput devices to behave consistently / predictably with RA after 100s of hours of work with the driver set to ‘xinput’. These frustrations continue despite JIT cfg building and the aforementioned server that my frontend facilitates.

Long story short, OP, you’re not alone in finding the input system a bit foreign :slight_smile:

i trying to do this but failing miserably can anyone help me with teamviewer if no hassle sorry