Add RETRO_ENVIRONMENT_GET_VFS_AUTHORIZED_LOCATIONS env

[spleen1981]

Adds a new env call to get a list of frontend-authorized filesystem locations.
Paths returned by this call must be directly usable with the VFS interface, for example saf://... on Android.

[cscd98]

@white-axe Before this gets merged in, how does this look to you? As I think you did the SAF implementation if I'm not mistaken.

[white-axe]

Seems fine.

[cscd98]

FYI this is for scummvm.

[cscd98]

@warmenhoven Anything like this in Apple ecosystem?

[i30817]

I kind of want vfs in scummvm so consider this a +1 for this pr

[warmenhoven]

Why is this necessary at all. Why not just use the existing RETRO_ENVIRONMENT_GET_SAVE_DIRECTORY. I don't think cores should think they're free to just run around, frontends won't like that much.

[spleen1981]

Why is this necessary at all. Why not just use the existing RETRO_ENVIRONMENT_GET_SAVE_DIRECTORY. I don't think cores should think they're free to just run around, frontends won't like that much.

This has nothing to do with saves directory.
This is needed in Android to get SAF paths authorized frontend-side for cores like scummvm that need this information to browse internally the trees.
As the directories pick list and SAF authorizations are handled at frontend level, the core has no way to access this info, hence cannot have a starting point to browse the SAF trees from the internal UI even if VFS support is implemented.

[i30817]

Why is this necessary at all. Why not just use the existing RETRO_ENVIRONMENT_GET_SAVE_DIRECTORY. I don't think cores should think they're free to just run around, frontends won't like that much.

Scummvm in RetroArch has a internal method to create a playlist (because it has its own internal scanner handling a myriad of special cases) so like upstream, it either needs to create its own SAF authorizations to use it in that scanner, or get the frontend ones. I'm not sure but I think in the retroarch context (a loaded dll) it can't authorize its own SAF authorizations, or maybe its just for consistency not sure.

Tl;dr: Other cores scan the files outside and inherit a authorized saf rom path (files), scummvm needs to navigate a internal saf dir hierarchy and needs a mechanism to pass those.

Note scummvm also has the old method to pass saf "roms" like the other cores that I suspect would work, but it loses out on the scummvm internal scanner which "fixes" a lot of bugs (besides the older method being torture for users, involving using player created files in every single game - that method does have a advantage though, which is being able to use zip files as games, something which will never happen in the internal scanner because of hangups of devs about "piracy" and this core being upstream)

Zip files in this older method are extracted fully to retroarch tmp by retroarch itself (but because of that they also have high latency over a uncompressed game over a local network so its not really worth it)

[i30817]

Sorry about the closed new issue, clicked the wrong buttons while editing the message.

[cscd98]

Android:

User goes to load core -> scummvm
Then they goto load content: then they can either select:

Open.. to select a new SAF folder
Or selects the existing saf://content folder that the user has previously approved.

Then the user finds the relevant scummvm content, tapping to load.

Now from a RA perspective, that path to the ROM or whatever the user selected in the frontend is now passed to the core in retro_load_game:

retro_load_game(const struct retro_game_info* game)


struct retro_game_info
{
   const char *path;       /* Path to game, UTF-8 encoded.
                            * Sometimes used as a reference for building other paths.
                            * May be NULL if game was loaded from stdin or similar,
                            * but in this case some cores will be unable to load `data`.
                            * So, it is preferable to fabricate something here instead
                            * of passing NULL, which will help more cores to succeed.
                            * retro_system_info::need_fullpath requires
                            * that this path is valid. */
   const void *data;       /* Memory buffer of loaded game. Will be NULL
                            * if need_fullpath was set. */
   size_t      size;       /* Size of memory buffer. */
   const char *meta;       /* String of implementation specific meta-data. */
};

So that would already be a SAF authorized path? Could this be used? Or does it need to know about other paths? This is all guess work btw, I don't know about other requirements for scummvm.

But then this could be fed into vfs callback to open additional files, assuming its part of the same path, it should still be authorized?

[spleen1981]

So that would already be a SAF authorized path? Could this be used? Or does it need to know about other paths? This is all guess work btw, I don't know about other requirements for scummvm.

Theoretically it should work, though not tested on Android, if .scummvm files are placed in its game folder (you can have one .scummvm file per game folder or all .scummvm files together in a different path, e.g. saves folder), but you would need to prepare those files manually entering the gameIDs, which is not the recommended way.
Details are given here.

Another manual workaround may be preparing the scummvm.ini by hand with valid SAF URIs consistently with what is authorized from retroarch, and then add manually the scummvm.ini targets in each .scummvm file. Not tested as well.

The correct way would be: retrieving from the frontend the URI (and that is the reason for this PR) of a node in the tree high enough to contain all the games below, pressing "mass add" from scummvm launcher and create automatically the needed .scummvm files and playlist from there.
After this one-time operation, each game could be launched directly from the relevant retroarch playlist.