It didn’t work either. I tried :
$ DRI_PRIME=1 firefox
$ DRI_PRIME=0 firefox
… but I found a workaround !
How could I not have tried this before :
# snap disable firefox
# snap enable firefox
That being said, I would like to know what was done in that process that put things straight. I noticed a difference in the mounted filesystems, the following was missing while the snap was disabled :
nsfs on /run/snapd/ns/firefox.mnt type nsfs (rw)
EDIT : That is for me the definitive solution :
umount /run/snapd/ns/firefox.mnt
Once that is done, the dGPU is properly detected by FF. A simple, single operation, non-persistent and effective.
From what I understand, Snap sandboxing is achieved by means of :
- AppArmor, restricting access to OS resources
- Linux namespaces, that maintain a private vision of the OS namespace
A private namespace is deleted once the last process using it has exit()ed, unless it has been mounted beforehand, which is the case here. Snaps maintain their own private vision of the namespace from first execution after boot until OS shutdown.
This is not a bad thing, just that in my very specific case, a hardware change happens that alters the global namespace as it should, but the private namespace retains some information that hides it somehow. In that case, removing it is enough, and a new one is created during the following snap program execution.