Per-core 'Reset to default configuration' option

[dankcushions]

As discussed some time ago in discord, it would be useful to have an option in the package manager for each libretro core. This saves the user the current fiddly process of:

1. Delete file /opt/retropie/configs/all/[foo]/retroarch.cfg ([boo] is the system directory. eg snes - this could potentially be shared with another libretro emulator for the same system, but if it needs resetting for one it probably needs resetting for all)
2. Reinstall emulator via retropie_setup (regenerates retroarch.cfg deleted in 1.)
3. Delete overrides directory /opt/retropie/configs/all/retroarch/config/[bar] ([bar] is the libretro core library name, eg Snes9x - should be similar, but not neccesarily the same, as rp_module_id - eg lr-snes9x)
4. For completeness, all the core options set in /opt/retropie/configs/all/retroarch-core-options.cfg should be removed. they are in the format [bar][delimiter][option]="value" ([bar] is the libretro core library name. [delimiter] can be _ or - and maybe more). they will be reset to defaults when the emulator is next run)

step 3 and 4 are a little tricky to automate - either we add the libretro library name to the install scripts, or we programmatically retrieve it/store it somehow when updating/installing the core. i have a feeling there is a way to get the library name for a given core via command line but not sure... Maybe you can run the core with no game in verbose mode, and grep it from the log.

We would also want an option for resetting the main /all/retroarch.cfg

This option could potentially be expanded into non-libretro packages, to clear the /opt/retropie/configs/[food] directory, and then run sudo ./retropie_packages [foo] configure again, or something like that.

Happy to prototype this myself, but I think Buzz wanted to handle it.

[cmitu]

It would be a good addition to fix broken configurations - especially the ones with broken core options.

Regarding 3 and 4 - dealing with core options and core overrides:

• core naming can be taken from libretro-core-info. It seems to the synchronized with RetroArch releases, though in practice I'm not sure it matters, since we don't use the Libretro core repository.
• I don't think there's a way to get the core name via CLI. It seems the info is filled in by the core in retro_system_info, but I don't see a function to retrieve the library_name specifically in the libretro api.
• in the future, we might switch to the per-core options configuration, this will make dealing with resetting the core options easier. I'm not sure if there's a standard for finding out the core options prefix, it seems it's totally core dependent and the info is not present in libretro-core-info.

I'll see if there's a method for dynamically determining the core name without resorting to libretro-core-info, since the info there might be different than what is currently installed.

[cmitu]

Here's a quick and dirty method to get the core name by calling the .so's retro_get_system_info via python

#!/usr/bin/env python3
import ctypes
import sys
import os.path

class RetroSystemInfo(ctypes.Structure):
    _fields_ = [
        ("library_name", ctypes.c_char_p),
        ("library_version", ctypes.c_char_p),
        ("valid_extensions", ctypes.c_char_p),
        ("need_fullpath", ctypes.c_bool),
        ("block_extract", ctypes.c_bool)
        ]

retro_info = RetroSystemInfo(b'', b'', b'', False, False)

if sys.argv[1:]:
    if not os.path.isfile(sys.argv[1]):
        print('Not a valid file')
        sys.exit(1)

    try:
        core_file = ctypes.cdll.LoadLibrary(sys.argv[1])
        core_file.retro_get_system_info(ctypes.byref(retro_info))
        print('Core name: ' + retro_info.library_name.decode('LATIN1'))
    except:
        print('Cannot load DSO')
        sys.exit(2)

EDIT: this seems to fail for one core from the ones I have installed (lr-hatari), when it needs an additional .so (libcapsimage.so.) that's not in the system's library path.

EDIT 2: setting LD_LIBRARY_PATH to include /opt/retropie/libretrocores/lr-hatari before running the script seems to solve the DSO loading issue.

[hhromic]

That's a really clever idea of loading the core's dynamic library a and directly calling its name function. By far the most simple and robust method 👍

[dankcushions]

one potential future benefit of retrieving the core name, is working around this issue and similar: libretro/RetroArch#9007 - by moving to overrides (which need the core name to generate programatically) rather than appendconfig, which seems to be increasingly undersupported.

[busywait]

@dankcushions to get retroarch override folders (and other folders) you said "Maybe you can run the core with no game in verbose mode, and grep it from the log." This seems to be a robust option because it includes any (unexpected) configuration that might be specified. RetroArch can be configured to quit after a single frame with --max-frames=1 just to generate the log (or will write verbose output to stdout if --log-file isn't specified). Fast enough to run for the first valid rom found in each rom folder?

Or write and submit a patch to RetroArch for a --print-config command-line option that dumps the config to stdout and exits? That might be generally useful to more people? I can't see that anything similar exists already in https://github.com/libretro/RetroArch/blob/master/retroarch.c

[cmitu]

I added a few helper functions here.
We can probably hook the reset functionality in the retroarch scriptmodule (through a gui function in the Configuration/Tools menu) or in the configuration editor.

I'm not sure on where to do the reset:

• system/platform - reset all libretro cores for the system (and any content based configurations like shaders)
• libretro core - reset the core itself (options, configuration overrides, shaders, etc).

To find the core option prefix, we can default to use the library name (<core_libretro.so) and leverage the newly introduced mod_info ¹ vars to provide a value for the exceptions (i.e. mamercade -> mame).

1. Merge module arrays and include all modules in setup #3296

[joolswills]

Sorry I haven't joined in this discussion until now. I quite like the code to extract the libretro name, but I think I would implement it differently from the other code in your changes @cmitu . For the resetting I think we can leverage the existing libretro module configuration scripts using a parameter, which might be what you mean. Extracting name may be useful for the other configs. However, I'd like to see where my current package changes go and then revisit.

I don't think what I envisage would be much different really from the ideas here, but I will admit as you probably are aware, that I'm quite keen on working on the core stuff myself.

I think once I have some of the other packaging stuff in place it will be clearer the best route to take. But appreciate all the ideas :-)