Help with Understanding/Creating autoconfig Mappings


#1

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!


#2

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.


#3

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.


#4

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.


#5

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


#6

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.


#7

Plug one pad, bind all, save autoconf, default all, restart, test, unplug. Plug another pad, bind all, save autoconf, default all, restart, test, unplug.


#8

I’ll have to give this a go. Is this supposed to make it so that whichever is plugged in will work automatically?

This might add another wrinkle to my problem. At my computer in my office, I can easily unplug my XB360 wired pad and the SNES pad, depending on which I want to use. But in the living room, the plan is to always and forever have the wireless XB360 receiver plugged in. The wireless controllers can certainly be turned off, but only after starting an emulator. I have a USB extension and hub that I plan to use for plugging the SNES, N64, 2600, or Genesis pads into as needed. Is there no way to have RetroArch allow bindings to two simultaneous gamepads? Like how it allows gamepad buttons AND keyboard input at the same time?

I really wish there was just a file that contained fields like “Retropad_buttonA=KeyEnter,XInput_360_button2,XInput_SNES_button1,XInput_Genesis_button1”, so that we could just bind whatever the heck we want to whatever the heck we want and have any or all of the pads connected and working along side one another.

I do appreciate everyone’s assistance with this. I’m so close to being happy and “done” with this retro gaming setup, the various gamepads & adapters is the one last big hurdle that’s giving me grief.


#9

EUREKA!!! This seems to have done it for me!!! Thank you!!! One addition that I would make is:

Plug one pad, bind all (in main menu), save autoconf, default all, restart, test, bind all AGAIN (in-game main input settings), save autoconf, default all, restart, test, unplug… for each pad (though i didn’t need to bother with the XB360 pad, it’s autoconfig works perfectly for me).

So, while I cannot have multiple gamepads plugged in at the same time and have them all work side-by-side, It looks like it is going to work beautifully to just unplug the controller not in use, and plug in the one you want to use that was setup with the above steps. Voila, yellow letters pop up saying which CONFIGURED gamepad was plugged in and it switches over to its mappings… I can’t tell you how excited I am about this!

I have only tested all of this at my computer so far, not from the living room TV over the Steam Link, so probably next weekend we’ll see how that goes. I’m hoping that even though the XB360 wireless receiver will remained plugged in, just turning off the wireless gamepads will “disconnect” that pad and allow any other gamepads then plugged in to take over.

The fun part is going to be mapping everything for all four users. I imagine that’s going to get convoluted and confusing, but I’m hoping both I and RetroArch will be able to keep everything straight and I will have a rock-solid retro gaming emulation setup running on a decent rig but playable on the big TV from the comfort of the couch, like when i was a kid/teenager again!

HUZZAH!!!.. Thanks again, radius & hunterk, for helping me tame RA’s baffling binding system! Assuming everything goes well from here on out.


#10

The system is not baffling… at all… and you can have multiple pads just fine…

You don’t need that extra step at all… not sure why you need it. Doing it once should be enough. it just uses the OS enumeration and it can’t know every controller under the sun…

Again, the process (starting with no conf at all)

  1. user 1 bind all
  2. fix anything that may have gone wrong
  3. user 1 save autoconf
  4. user 1 default all
  5. restart retroarch, even though you defaulted all you should have full control with the pad

Repeat for every pad. Don’t change user #x device index

And yeah it’s real plug and play / hotplug once you have the pads configured. Once you have autoconf profiles it will just assign the pads to the next free slot.

For instance my PC has 1 XBONE Elite, 1 XBOX 360 Wireless, 2 NES 30 Pros, 2 SNES30, 1 DS4 with the official dongle. That’s the order the OS is exposing too, I changed the order with this:

If I turn on any single pad it will assign it to port 1. If I turn on… 1 NES30 and one XBONE Elite it will set XBONE elite to user 1, NES30 to user 2.

Another example: If I turn on the DS4, it will assign it to port 1, if then I add the XBOX 360 it will assign it to port 1 and move the DS4 to port 2. If I add the XBOX elite then, it moves the others to 2 and 3 and XBOX elite becomes 1.

As for wireless 360, it doesn’t stay connected. Sadly the DS4 does so I just unplug that one. I just use that one for PSX stuff.

I want the system to be different, I want it to assign ports on first keypress:


#11

Well, it seems a little baffling to me, as someone who didn’t understand why things just weren’t working.

I don’t know why I needed that extra step either, but after starting RA, setting the inputs, saving the autoconfig, and binding default, all without actually loading a ROM, once I started a core and got into a game, the mappings did not stick. Even though they did stick in the RGUI after a restart, before loading a game. But I just repeated the exact same process within the game/core and it worked beautifully… Could this possibly be because I have it set to separate configs per core? There was a reason I needed to switch that setting, though I don’t remember what it was. But I would still imagine that the gamepad is configured with an autoconfig file after the first time, so it should register and map it automatically within a core, too. Who knows. The extra step doesn’t bother me. I agree it shouldn’t be needed, but it seems to be required in my case for some reason.

Sorry about the confusion about multiple pads. Clearly you can have multiple pads, even various different pads mapped and working at the same time for multiple users… What I meant was that I want (as user 1) to navigate around with my default, standard XB360 gamepad (especially since this is all happening through Steam Link and I use the XB360 pad for navigating Big Picture), then just put it down and pick up my already connected SNES pad and use that for SNES games, or take my pick between the SNES and XB360 pad, both for user 1. Then navigate back to my front end, start a Genesis ROM and pick up my already connected Genesis pad, or use my SNES pad again, or the XB360… But, now that I think about it, a system that allowed that would require a LOT of extra time binding all the buttons for each and every user and somehow retain that exact same user/binding pairing whenever unplugged & replugged. The hotswapping and auto-assigning you describe will actually be a much more intuitive and manageable system… I really haven’t experimented yet with multiple of the same gamepad and more than one user. I’ll probably be configuring all my gamepads this next weekend and testing multiplayer setups.

Thanks again for all your help!


#12

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.


#13

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: