These are there to prevent applications (expecially GTK ones) from constantly waking my laptops dGPU for no reason. The problem is that this causes for instance the security center and firmware snaps to simply not launch. Ive been going through the snap documents and there doesnt seem to be any way to actually fix this but to simply not use snaps that cant handle these variables.
The snap documentation is kind of hard to go through and seems to assume youre making a snap not using one (kinda stange). While i didnt think to save which pages do this some of the documentation pages are dead links which makes it even more difficult to figure out if this is possible.
Any snap experts able to chime in on this? can the user even tell a snap to ignore variables set outside the snap?
will gtk and other applications still read these then? The issue isnt necessarily plasma itself but GTK applications in particular (and Gnome when i was using it) absolutely refuse to stop waking the dGPU without these set.
Yeap, any app started in your Plasma session inherits from that env folder, including GTK apps
The reason snaps died was strictly the hardcoded /usr/share paths. If you want GTK and other appps to stay on your integrated Intel GPU without breaking snaps, use DRI_PRIME=0 instead of pointing to static files. It keeps your dGPU asleep and snaps can still find their own drivers
DRI_PRIME doesnt work with GTK apps or Gnome to stop this (they select the right gpu most of the time with it), GTK apps will parse all the GPUs every single time on application launch even waking the GPU with DRI_PRIME and Gnome has a long standing issue of running a gnome-shell on the dGPU that keeps it awake when it shouldnt.
Ill give that a try later and see if that works to stop them doing that in a plasma session
i did do that, and unfortunately it seems like the snaps still pickup that env variable even if its not in /etc/environment but in the session env too
I know what the cause is, but i havent found a way to tell the snaps to ignore the env variables. Flatpaks just ignore it so they have no problems.
I can specifically override the variables per snap in the .desktop files to ones that the snap expects. That is a fragile way to handle it as if anything with snap changes that changes those paths in any way im back to square one. Theres also the fact that doesnt work from terminal unless i export those each time or create an alias
Yes and I think it is quite a corner case, I would expect most users to expect the exact opposite (which is the current default as you noticed already) i.e. that all user environment is handed to the snap by default … snapd would likely have to grow some system setting to allow you to override this globally…
it is somewhat, but being relatively new to snaps and having used Flatpak for a long time Im use to Flatpak which this is the default behavior and you can override them per flatpak or for flatpaks globally.
Seems to me like having the snaps pickup env variables on default (especially ones they cant handle and will break them) is a good way to have them break on users that need to deal with things that way that arent snap related.
Ill look at making a wishlist bug but in the mean time I think id rather just limit my snap usage. They keep ending up being more of a nuisance than a benefit when I use them unfortunately and that means i just cant use security-center as i havent found a deb for it.
Unfortunately then i have to maintain the paths that it expects through any snap changes that might break that which requires me entering the snap sandbox and figuring out what paths the snap expects when it does inevitably break.
doesnt feel worth the effort and idk how either of these applications are effected beyond that I.E if they run in the background but just end up crashing instead of doing their job.
While this is true, the .desktop files pretty much never change …
I mean, you are only adding another env entry there and the freedesktop spec makes sure your local .desktop is always preferred
That would have to be discussed in the bug (or would have to be brought to the architects by the snapd devs for a proper design after they processed the bug… a bug is definitely the necessary entry point here to start something in that direction)
variables are passed if you explicitly launch a flatpak with the variables, but not one of my flatpaks picks up anything i have in /etc/environment
I dont have a single flatpak that has ever picked up variables that i didnt explicitly pass to it. Its possible i have never used the right combo of variables for this to happen i will admit though but its simply never been an issue for me with flatpaks.
EDIT: Figured out why, /etc is a reserved path and unless you explicitly add the host-etc (or full host access) sandbox permission it isnt used in the sandbox and even then it isnt in the sandbox /etc but in a separate sub folder /run/host/etc
and idk how either of these applications are effected beyond that I.E if they run in the background but just end up crashing instead of doing their job.
Notably