Yeah, this was the same in the older sddm-19 used in slackware 15. I checked and I don't see any significant changes in how Slackware sets up the environment before launching sddm so my best guess is that something changed in how mesa parses that variable.
It also looks like this is specific to how sddm runs on X. When using wayland it goes through a whole different process. Maybe mesa treated / as an invalid value or something who knows. Regardless I'm of the opinion that sddm should respect the system environment in which it runs. That's kind of the whole point of an environment variable. I expect my processes to listen when I tell them what $HOME is... -Ben On Tuesday, April 22nd, 2025 at 5:18 PM, Russell Senior <[email protected]> wrote: > git blame says: > > d42700a3 (Stefan Majewsky 2015-08-22 14:05:17 +0200 270) > env.insert(QStringLiteral("HOME"), QStringLiteral("/")); > > So, those lines have been there since A WHILE. > > -- > Russell > > On Tue, Apr 22, 2025 at 4:51 PM Ben Koenig [email protected] wrote: > > > Figured it out. SDDM has some code where they manually set the environment > > for their subprocesses which stomps on the system variables. > > > > So you are technically correct Russell, sddm forks off to a bunch of > > different subprocess. I checked the source code and sddm manually creates > > an environment for these processes to run in and sets that. > > > > <code> > > // create cursor setup process > > QProcess *setCursor = new QProcess(); > > // create display setup script process > > QProcess *displayScript = new QProcess(); > > > > // set process environment > > QProcessEnvironment env; > > env.insert(QStringLiteral("DISPLAY"), m_display); > > env.insert(QStringLiteral("HOME"), QStringLiteral("/")); > > env.insert(QStringLiteral("PATH"), mainConfig.Users.DefaultPath.get()); > > env.insert(QStringLiteral("XAUTHORITY"), m_authPath); > > env.insert(QStringLiteral("SHELL"), QStringLiteral("/bin/sh")); > > env.insert(QStringLiteral("XCURSOR_THEME"), > > mainConfig.Theme.CursorTheme.get()); > > setCursor->setProcessEnvironment(env); > > displayScript->setProcessEnvironment(env); > > </code> > > > > I patched it so HOME is set for "/root" and recompiled and BEHOLD - it > > stopped generating /.cache. Looks like upstream is not adhering to the > > system environment. > > > > -Ben > > > > On Tuesday, April 22nd, 2025 at 3:29 PM, Russell Senior > > [email protected] wrote: > > > > > The environment something runs in can sometimes be confusing. For > > > example, if the program forks, the exec operation that starts the > > > child can clear the environment. If you can start the program with an > > > strace wrapper, following forks and logging to a file, that might > > > shine some light on the problem. Something like: > > > > > > strace -f -ttt -s256 -o/tmp/strace-sddm.log <sddm-command-line> > > > > > > where > > > > > > <sddm-command-line> is the normal startup command. > > > > > > You'll have to figure out where that command is invoked. > > > > > > -- > > > Russell > > > > > > On Tue, Apr 22, 2025 at 3:21 PM Ben Koenig [email protected] > > > wrote: > > > > > > > I'm sure that's what it is, but then that raises the question of WHICH > > > > variable. These are not undocumented features, and I've literally set > > > > all the relevant variables but it decides it doesn't care... > > > > > > > > sddm-greeter works as expected. It puts everything in /var/lib/sddm > > > > like a good little program. > > > > > > > > -Ben > > > > > > > > On Tuesday, April 22nd, 2025 at 3:13 PM, Russell Senior > > > > [email protected] wrote: > > > > > > > > > I didn't parse all the C code, but it could be something has an empty > > > > > variable ("") and that's getting appended with /.cache/<etc> > > > > > > > > > > -- > > > > > Russell > > > > > > > > > > On Tue, Apr 22, 2025 at 3:10 PM Ben Koenig [email protected] > > > > > wrote: > > > > > > > > > > > I'll take a look at the QML_DISABLE_DISK_CACHE variable. > > > > > > > > > > > > I just did some testing and it looks like some part of SDDM or mesa > > > > > > is not obeying both the HOME and XDG_CACHE_HOME variables when sddm > > > > > > is launched. I confirmed that the vars are set in the environment > > > > > > when sddm.bin launches but it still creates 1.9MB of data in > > > > > > /.cache. > > > > > > > > > > > > -Ben > > > > > > > > > > > > On Tuesday, April 22nd, 2025 at 3:00 PM, Robert Detjens > > > > > > [email protected] wrote: > > > > > > > > > > > > > No disk cache in root on Fedora 42 / SDDM 0.21.0, though there > > > > > > > are some > > > > > > > under `/var/lib/sddm/`. > > > > > > > The systemd unit environment disables some other different disk > > > > > > > caching for > > > > > > > QT stuff, but the bug refs look unrelated to the shader cache: > > > > > > > > > > > > > > `# workaround https://bugzilla.redhat.com/1686675 # see also > > > > > > > https://bugreports.qt.io/browse/QTBUG-58508 > > > > > > > QML_DISABLE_DISK_CACHE=1` > > > > > > > > > > > > > > On Tue, Apr 22, 2025 at 1:45 PM Ben Koenig > > > > > > > [email protected] > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Hey all, got a really random Linux question. > > > > > > > > > > > > > > > > Does anyone here who uses SDDM to log into their computer have > > > > > > > > a bunch of > > > > > > > > mesa cache files in /.cache ? > > > > > > > > > > > > > > > > Yes, that's a hidden .cache folder in /, you'll need to use 'ls > > > > > > > > -a /' to > > > > > > > > find it. I'm specifically interested in systems running sddm > > > > > > > > versions >=20 > > > > > > > > but if you are on an older distro using 19 and have it that > > > > > > > > would be > > > > > > > > interesting as well... > > > > > > > > > > > > > > > > There's something funky going on in slackware -current and I'm > > > > > > > > too lazy to > > > > > > > > launch a new VM when I can ask users on other distros. That and > > > > > > > > the PLUG > > > > > > > > list has been a bit slow lately :) > > > > > > > > > > > > > > > > -Ben
