Not possible to save custom controller profiles

[xordspar0]

In #102, a user was confused about not being able to update the core info files; trying to do so results in a EROFS (Read-only file system) error. For data that is supposed to be read only like core and content databases, this is benign though a bit confusing.

Correct, the .info files are shipped with the Flatpak, and are updated periodically through the Flatpak package.

Would like to disable Online Updater menu items for components that are handled through Flatpak:

• Info files
• Assets
• Shaders
• Joystick Autoconfig
• Database

Originally posted by @RobLoach in https://github.com/flathub/org.libretro.RetroArch/issues/102#issuecomment-461519964

However, joystick autoconfig is different. It's desirable to ship with some autoconfig so that common controllers are supported, but users may need to be able to configure their own controllers that aren't in the database. In particular, the Settings -> Inputs -> User 1 Binds -> User 1 Save Autoconfig button can never work. It always fails with "Error saving controller profile." Even if the user does copy an autoconfig file from a non-Flatpak install, that file will be ignored.

Is there any way to overlay .var/app/org.libretro.RetroArch/config/retroarch/autoconfig on top of the /app/share version? Or maybe RetroArch needs to grow support for a list of directories instead of just one.

[matheuswillder]

It's not exactly a solution, but for now I suggest you to just change all the default directories from /app/share/libretro to ~/.var/app/org.libretro.RetroArch/config/retroarch in the retroarch.cfg file (you can do it automatically using the replace option with a text editor), then open RetroArch and use the Online Update to update Assets (to the UI works correctly again) and then update all other options such as shaders, core info files, etc., I don't know if you've already done this (it wasn't clear to me), but it seems to be the only solution for now.

As I commented in https://github.com/flathub/org.libretro.RetroArch/issues/243#issuecomment-1732411086, maybe the better would be to rely the least possible on assets shipped through Flatpak because of these problems, but as mentioned there, there are also benefits to doing it this way.

Is there any way to overlay .var/app/org.libretro.RetroArch/config/retroarch/autoconfig on top of the /app/share version? Or maybe RetroArch needs to grow support for a list of directories instead of just one.

I also tried to overlay the directories using symbolic links but it doesn't work, and I don't know if there is an easy way to make RetroArch use more than one directory (this would be confusing), but perhaps the best thing would be for RetroArch save any edited file only in /retroarch/config folder by default, I don't know why it's not like that yet, as it doesn't make sense for asset files to be mixed with customizations made by users. But that would have to be suggested in https://github.com/libretro/RetroArch, as it's not specific to the Flatpak build. I'm not going to open any issue there with this suggestion right now (I'm short on free time), but please let me know if you or someone else opens it so I can follow up.

[RobLoach]

Would love to figure out a way to handle this, like merging the different paths or something.

[xordspar0]

I don't know if you've already done this

Yeah, I changed the autoconfig directory to ~/.var/..., configured my controller, and submitted it to retroarch-joypad-autoconfig. So when that ships, I won't need this feature anymore. :slightly_smiling_face:

it doesn't make sense for asset files to be mixed with customizations made by users

Right, it seems like Retroarch wants everything to be writable; there is no distinction between assets and user configuration. Just download everything to a local directory and edit/add to it as you see fit. There are a few problems with doing it this way. For example, I assume that if you have a local autoconfig file that you made, and later a file with the same name is added to the official autoconfig repository, the next time you download the autoconfig files it will overwrite your local file?

So in short, I appreciate how the Flatpak version is trying to divide up user config and assets. There are problems either way, and I hope we can find a solution in either the Flatpak side or in Retroarch itself.

[matheuswillder]

Right, it seems like Retroarch wants everything to be writable; there is no distinction between assets and user configuration. Just download everything to a local directory and edit/add to it as you see fit. There are a few problems with doing it this way. For example, I assume that if you have a local autoconfig file that you made, and later a file with the same name is added to the official autoconfig repository, the next time you download the autoconfig files it will overwrite your local file?

You're right but I think it's even worse than what you described, for example I follow the r/RetroArch subreddit and sometimes I see posts asking why RetroArch was working for a while and then suddenly stopped working, even without any update, sometimes it's controls that stop working, or a core that simply crashes, and most of the time this occurs for example when the user accidentally saves a control profile or when change some configuration per core. This is quite common on Android, there easily the user may accidentally change something when navigating through the Quick Menu because of the touch controls, but can happen even on other platforms simply because the user is testing all the options. With custom config files spread across many directories and mixed in with actual asset files, it can be difficult to figure out what exactly happened. On the other hand, if all the custom config files were saved in a single folder, it would be easier to say "hey, just delete all the files and folders in the /config folder and all the settings will be reset to default". It would be easier even to backup these config files for a new installation. And this alone also would allow RetroArch Flatpak users to customize whatever they want, since what is happening here is not exactly a bug but rather a result of how Flatpak works, since only files and folders in ~/.var/app can be edited, it is designed to be that way.

I also hope this can be solved in some way, but for me it's more a problem with how RetroArch is behaving with these files rather than a problem with Flatpak. It remains to be seen whether they would agree.

Good that you solved your problem and that this also will help anyone who has the same controller when it is merged.

[davidhedlund]

• https://github.com/flathub/org.libretro.RetroArch/issues/295