Controller Config Not Persisting

Welcome Page Forums RetroPie Project Controller Configuration in RetroPie Controller Config Not Persisting

This topic contains 6 replies, has 4 voices, and was last updated by  illuminerdi 2 years, 2 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #109242


    I’ve been trying to edit the controller config for Retropie but I seem to be running into a problem:

    I’m running RP 3.2.1 and using a Dualshock 3 controller. The controller pairs fine and works, but whenever I edit the controller’s configuration file, the changes get reset when I reboot my RP.

    For example: I edited the PS3 config file located in /opt/retropie/configs/all/retroarch-joypads to change a few things – I wanted Start+Select to open the RGUI, for example, instead of exiting the game.

    So I used vi to edit my changes, saved them, and restarted ES and it worked until I rebooted my RP, at which point the controller’s config file was reverted back to defaults with Start+Select exiting the emu.

    Does anyone know why these configs would be getting reset or rewritten? Is this some kind of byproduct of the DS3 pairing procedure?




    I’m still having no luck on this. I tried enabling per-core overrides in the retroarch config file to see if that worked, and even that failed – despite putting custom entries in my picodrive config it would still default to the same controls every time.

    I’m starting to think that the ONLY place I can change the controller config is in the retroarch.cfg file somewhere, but even this is confusing: there are at least 2 or 3 copies of this file scattered about various locations…

    I’m going to turn on debugging/logging for retroarch and see what the actual log files have to say about exactly WHICH config file is being loaded and from where, maybe that will help, but I’m still in over my depth here so any suggestions would be appreciated.



    For those interested, I managed to work around this but it’s not the cleanest solution.

    So here’s what I did:

    1) I made a directory: /opt/retropie/configs/custom

    2) I copied the contents of /opt/retropie/configs/all/joypad-config to the directory in step 1

    3) I edited /opt/retropie/configs/all/retroarch.cfg and changed joypad_autoconfig_dir to point to the directory in step 2

    This now causes Retroarch to load up my custom controller binds every time.

    Though ironically in my last edits I somehow managed to break something because now retroarch crashes/instantly exits whenever I try to load up a SegaCD game (which I was using to test this), the same game that was previously working. I think I know what I changed to break this, but it’s still annoying that something as simple as trying to change controller configurations turns out to be so difficult.

    This would be completely irrelevant if the system would save config changes made through RGUI by default, but for whatever reason creating config binds/changes through RGUI does NOT save properly, either due to a bug or just plain obtuse implementation, but either way this whole process has been way more difficult than it should be.

    I’m not blaming anyone – I’m sure there are good reasons why this is the way it is (dev time is valuable and they are not paid, these things are bugs, etc), this is just turning out to be a major frustration for what should have been a non-issue…



    Rgui configs definitely have room for improvement when it comes to making custom configurations. Believe me it’s on the list.



    @illuminerdi You can see some of the current RGUI logic on this video

    RetroPie help guides -->
    Please read this before asking for help -->



    I had issues with something blanking out my controller configuration every so often – what I did was use WinSCP to revoke write permissions to the file after I had set it. I haven’t had any more problems with it so far.



    So I have at least some inkling of what’s going on here now. After lots of poking around I have what I believe is a firm grasp of at least how the system here works:

    First you have the config in /opt/retropie/configs/all/retroarch.cfg – I will refer to this as the “baseconfig”.

    Then you have your controller configs located in /opt/retropie/configs/all/retroarch-joypads – I will refer to these as “stickconfigs”.

    Lastly you have configurations located in /opt/retropie/configs/emulators/{system name here}/retroarch.cfg

    Here is where it gets tricky. Each of these files is mostly empty and the last line is #include /opt/retropie/configs/all/retroarch.cfg

    So when you boot up an emulator it looks at its configuration, and (as far as I can tell), it then parses custom configs, THEN it grabs a copy of the baseconfig, and includes it for configuration, before (possibly?) grabbing the stickconfigs and including those.

    So I’m pretty sure there’s a bug here, because making per-emulator changes to /opt/retropie/configs/{emulatedsystem}/retroarch.cfg was not working for me, I believe because the baseconfig file is being loaded after the file that’s supposed be be containing “overrides”.

    So even if I put “blah_thing_btn = x” in /opt/retropie/configs/{system}/retroarch.cfg, it would just immediately get stomped over by the baseconfig (and/or the stickconfig) getting included as a later part of the config loading chain.

    Maybe I never correctly set a necessary flag, or this is a bug; I haven’t experimented enough to find out which, and I don’t really have the time to 🙁 – sorry! I’m just documenting this in case it helps others or helps the devs bugfix.

    So my solution for emulators where I want to alter the “stock” config: rename /opt/retropie/configs/{system}/retroarch.cfg to something else, and then copy the baseconfig file to that same directory and make necessary modifications there. Without the #include taking place you don’t have to worry about your per core changes getting stomped over!

    It’s a brute force way to solve the problem, but as I said, I wasn’t really interested in putting in a ton of time into tracing the config hierarchy and determining what was *actually* taking precedence and being loaded in what order and then working around that. I can confirm this method does work for me, and I’m happy with it, so I don’t intend to do a lot of global tweaks from here on out.

    I hope this helps anyone interested! Feel free to use this information anywhere helpful (wiki, etc) if someone wants to write up a summary/guide on the basic flow for loading configs, since I couldn’t find it documented clearly on the Wiki (though it may be there and I just never found or understood it)…

Viewing 7 posts - 1 through 7 (of 7 total)

Forums are currently read only - please visit the new RetroPie forums at

PLEASE NOTE: All orders that are placed between January 14th and January 28th will be shipped on January 29th. Dismiss