Cannot access the Shaders directory

[alexb3d]

The directory is not accessible in home /.var
It is inside '/', and to make a change or use a custom shader you need to login as root.

[RobLoach]

Seems to be working here? Strange that root is required... What does your .cfg look like?

[alexb3d]

Mine is the same. In the configuration you have two directories.

libretro_directory = "~/.var/app/org.libretro.RetroArch/config/retroarch/cores"
video_shader_dir = "/app/share/libretro/shaders"

Those who say "~/.var/app/org.libretro.retroarch/..." they are saved in home.

Those who say "/app/share/libretro/..." are saved in root
"/var/lib/flatpak/app/org.libretro.RetroArch/current/active/files/share/libretro/..."

And the "default" that I think they have no assigned directory.

I also noticed that it can not be updated.

[terzag]

I've just noticed this when trying to setup the new Mega Bezel feature, which has to install a bunch of new shaders. Updating the shaders through RetroArch's menu doesn't seem to work −likely because the dir belongs to root− and doesn't display an error.

Why does the flatpak version put video_shader_dir (and a few others) into /var/lib/flatpak/app/... instead of ~/.var/app/...?
Is it safe to change it for the local dir rather than the system one?

[alexb3d]

You can change the directory to home and then update the shaders.
It seems to me that Flatpak is in disuse. I currently use appimage and it works flawlessly.

[terzag]

Ok, I'll try this. But shouldn't it be changed directly in the flatpak package? IMO, all the elements that can be updated through RA's online updater should actually be updateable and thus be in the local path.

[RobLoach]

The Flatpak comes with the Shaders installed out of the box...
https://github.com/flathub/org.libretro.RetroArch/blob/master/retroarch.cfg#L39

Do you believe we shouldn't ship the Shaders with the package? If we use the local path, we cannot ship with the shaders. It is possible to change the Shader directory, and then use the Online Updater.

Since we update the Shaders each release, this may not be a big issue. You'll get the same Shaders if you use the online updater.

[terzag]

To me, there are two issues related to the way files from the flatpak are organized:

• some content is in the system dir, other is also "mirrored" in the user's dir
• the config file (retroarch.cfg) has paths set to the system content and other paths set to the user content

This makes the whole use of the flatpak version quite confusing: I have a shaders subdir in my personal config dir (~/.var/app/...) but if I put new shaders there, I can't find them in RA, because it's actually looking in the system dir.
Also, given that some of the updatable content is in the system dir while other is in the user dir, the Online updater can update some categories (the ones in user dir) but not others (the ones in system dir), which is pretty confusing: e.g. assets, cheats... I'm not sure how often they're updated on RetroArch's side vs how often the flatpak package is updated.

This makes the Online Updater look partly broken.

IMO, everything that is updatable through the Online updater should actually be and so be set to the user dir in retroarch.cfg but I guess this would lead to different issues, i.e. having a non-functional RA out of the box and having to update everything through the Online updater on first use?

(Completely off topic, not sure if I should open a bug report: when looking through retroarch.cfg just now to check for some paths, I noticed there's a var cursor_directory set to the cursors system dir and just below a cursos_directory set to the cursors user dir; it looks like a typo −"cursos"?− and it's weird that there are two vars for the same content in both places but maybe it's normal?)

[RobLoach]

I'm not sure how often they're updated on RetroArch's side vs how often the flatpak package is updated.

The Flatpak is updated on each RetroArch release, bringing in the latest of each package. Would like to add a feature to RetroArch disable some of the Online Updater, as the following are shipped with the Flatpak release out of the box....

• Core Info Files
• Assets
• Controller Profiles
• Cheats
• Databases
• Overlays
• Cg Shaders
• GLSL Shaders

If we ship without the assets, for instance, when you run RetroArch, it would look like this.

when looking through retroarch.cfg just now to check for some paths, I noticed there's a var cursor_directory set to the cursors system dir and just below a cursos_directory set to the cursors user dir; it looks like a typo −"cursos"?− and it's weird that there are two vars for the same content in both places but maybe it's normal?)

I have no idea where cursos came from. There is no reference to that in either the Flatpak or RetroArch. The only instance I could find is recursos, which is in translations.

Again, you're able to change the directory to wherever you'd like it to be. By default, it will use Flatpak's system directory, which if installed using the user-space, will be at:

~/.local/share/flatpak/app/org.libretro.RetroArch/current/active/files/share/libretro

[alexb3d]

Hi. RetroArch has many supports, there are some that are not updated like Lakka.

Cursors in database and audio and video filters are making changes, I wouldn't worry too much about that.

Updates vary, some are constantly updated, some are not.

Yes, you can change the directory manually, but I don't see the point, if I want to use shaders and overlays I have to change retroarch to fit flatpak, shouldn't it be the other way around?

[fromthyashes]

The Flatpak is updated on each RetroArch release, bringing in the latest of each package. Would like to add a feature to RetroArch disable some of the Online Updater, as the following are shipped with the Flatpak release out of the box....

* Core Info Files

Since the flatpak doesn't ship with any cores, which I do think is the correct implementation, the user is already expected to navigate to the Online Updater and download the cores they want themselves, this is the same menu where they could simply Update Core Info Files before browsing cores. The intended functionality of the Core Downloader is to have access to new cores between releases, removing it just to provide a static set of Core Info files doesn't really improve the OOTB experience.

[RobLoach]

Agreed. Would love to ship with cores directly to save the user experience, and solve for some of the architecture issues. Made an issue for that over at #243

[fromthyashes]

Shipping with cores will move the location of the core directory and fully break the Core Downloader.

[RobLoach]

If we get all the compatible cores working though, then you wouldn't need to use the core downloader 😉 ... Either way it is still possible to change the Core Directory yourself if you want that level of control.

[fromthyashes]

You would still need the Core Downloader for new cores that are added outside of release though, which is already the issue that the Core Info directory is causing. This puts the onus on the user to restore the basic functionality of the application.

[alexb3d]

Do you want to send 1.3Gb of cores, or are you going to select some?
I would like to know which one you are going to select for me from Snes.

It doesn't work like that, flatpak should work exactly the same as the repo.
For a RetroArch "out of the box" there is already Lakka.

There is the case that I want to install an unofficial core that is not in RetroArch, or I can compile it myself.
Same with shader, overlays, thumbnails, cheats. You need full access to the directories.
Also not in the case of Databases, because this is updated after creating a playlist.

The only thing you can include are the Assets, Controller Profiles and maybe core info files.

The only thing to do is to move the directories of the "/app/share/libretro/shaders" a "~/.var/app/org.libretro.RetroArch/config/retroarch/cores".

Flatpak is more problems than solutions. I had to use a command in the terminal or Flatseal to give it access to my own "home". I stopped using it a long time ago, it's only good for webapp type applications.

[RobLoach]

Certainly sandbox issues to address. Hopefully we can find a good balance between out-of-the-box experience and customizability.

[vdegenne]

I don't know if that's related but I post here because I thought that was confusing too, I don't know if that occurred after an update but a lot of paths got renamed to this:

At first I thought all the builtin shaders got deleted and freaked out but there are under /app/share/libretro/shaders which is a virtual location. Very confusing never the less.

[alexb3d]

I just started a new installation. The path is still "/app/share/libretro/...".
There is nothing in /home, at least on my pc.
Maybe you pressed the space bar?

[vdegenne]

Thanks for confirming, I think it happened after I closed my OS session (without closing retro in that session) and tried to run another retro process in another session. I think it thought I was another user and created a new configuration file (probably copying an out of date default file from somewhere else). That's the only explanation I could find but I don't think it matters..

[yaomtc]

This is also an issue with the Arch Linux package. There, there is a ~/.config/retroarch, but putting files there doesn't work, as it's looking at /usr/share/libretro/ which doesn't have a shaders folder, only info. I created /usr/share/libretro/shaders/shaders_slang/ and copied in the Mega Bezel folder but every shader I tried failed to load.

Instead I switched to the Steam version as a workaround.

[RobLoach]

Strange. We have everything install to FLATPAK_DEST, and use sed to replace @prefix@ in retroarch.cfg with FLATPAK_DEST too. Other Flathub projects take on a similar pattern, so I'm not sure why the shaders aren't there.

[yaomtc]

Arch Linux package, not Flatpak. I'm thinking other native packages will have this issue too... I'll try one.

[RobLoach]

Looking through the package, it doesn't look like it installs the shaders:
https://gitlab.archlinux.org/archlinux/packaging/packages/retroarch/-/blob/main/PKGBUILD?ref_type=heads#L100-103

... Despite setting the directory:
https://gitlab.archlinux.org/archlinux/packaging/packages/retroarch/-/blob/main/retroarch-config.patch?ref_type=heads

[yaomtc]

I have an account on their issue tracker, I can report it there.

[yaomtc]

I now know there is a separate package for the shaders: libretro-shaders

I didn't know it existed because I had only searched for retroarch.

[RobLoach]

I believe it makes sense to make the retroarch package depend on libretro-shaders

[yaomtc]

It is listed in the optional dependencies at least, I just didn't notice it

https://gitlab.archlinux.org/archlinux/packaging/packages/retroarch/-/issues/3