Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not possible to save custom controller profiles #256

Open
xordspar0 opened this issue Sep 30, 2023 · 5 comments
Open

Not possible to save custom controller profiles #256

xordspar0 opened this issue Sep 30, 2023 · 5 comments

Comments

@xordspar0
Copy link

xordspar0 commented Sep 30, 2023

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 #102 (comment)

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
Copy link

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 #243 (comment), 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
Copy link
Collaborator

RobLoach commented Oct 9, 2023

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

@xordspar0
Copy link
Author

xordspar0 commented Oct 10, 2023

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. 🙂

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants