[Linux] Resonite doesn't launch
Describe the bug?
Trying to launch Resonite from Steam under Linux, I see the Resonite.exe process (under Proton), but not much else happens.
The dotnet-install.sh script runs, as the runtime directory is created.
Steam sees Resonite as running (shows the Stop button).
To Reproduce
- be on Linux
- launch Resonite from Steam
Reproduction Item/World
N/A
Expected behavior
Resonite should launch as usual
Screenshots
No response
Resonite Version Number
2025.11.24.1340
What Platforms does this occur on?
Linux
What headset if any do you use?
No response
Log Files
The main log is empty:
vixen - 2025.11.24.1340 - 2025-11-25 19_42_09.log
Renderite.Host.Crash.638996929293641914.log
This is the STDOUT/STDERR output redirected into file (> ~/reso.log 2>$1):
Additional Context
Tried to do a fresh install (deleting the installation folder), but that didn't help.
Reporters
@shadowpanther, @goof320
Hello! Here are the results of the automated log parsing:
| Version | OS | CPU | GPU | VRAM | RAM | Headset | Plug-ins/Mods | Renderer | Clean Exit |
|---|---|---|---|---|---|---|---|---|---|
| no | None | ❌ |
This message has been auto-generated using logscanner.
Did it run before on the same machine? Did you have any changes to the system itself?
It looks like iit's having trouble determining the home directory - looks a bit like "HOME" environment variable isn't defined.
Did it run before on the same machine? Did you have any changes to the system itself?
Yes, 2 days ago I ran both Release and Prerelease versions (9.0 and 10.0). Some system packages were updated since, but nothing breaking. Other Windows games work in Steam/Proton.
It looks like iit's having trouble determining the home directory - looks a bit like "HOME" environment variable isn't defined.
I've tried to add an echo to the LinuxBootstrap.sh, and it shows empty $HOME indeed. I'm not sure what is causing it.
If I just run LinuxBootstrap.sh from a plain shell, it has a non-empty $HOME, and the Renderite window opens.
Prepending HOME=<my home path> to the Steam launch string (this sets the environment variable explicitly) doesn't help, so it is lost somewhere down the wrapper chain.
But changing the compatibility layer from proton-cachyos to proton experimental did fix the issue somehow. So looks like the proton-cachyos package got updated yesterday, maybe that's what caused the bug. I guess other games don't require the $HOME variable, so nothing else broke with this update.
Hmm... That's most likely the culprit.
Are XDG_DATA_HOME and XDG_CACHE_HOME defined? We use these as primary, but $HOME is used as fallback and evaluated whether XDG ones exist or not.
We could make it not evaluate that variable if XDG ones are present, which should fix the issue.
related issue on the proton-cachyos github also https://github.com/CachyOS/proton-cachyos/issues/80
In proton-cachyos in the affected version I imported a few changes from the upstream Wine project that treat some unix env variables as special. With these changes special environment variables coming from Unix are prefixed with WINE_HOST_, so HOME becomes WINE_HOST_HOME, and variables prefixed with XDG_ become WINE_HOST_XDG_.
The following are the commits that introduced these changes to the Wine project, hopefully in the proper order
- https://gitlab.winehq.org/wine/wine/-/compare/ada1a8c972eda99cedb1b794d8f1a82676315a10...d4920360bffddaa5923a8da0b15f3ad9a2a97e78
- https://gitlab.winehq.org/wine/wine/-/commit/ad0aef6da18eca5b287aac053f820ab4c88c1b8d
- https://gitlab.winehq.org/wine/wine/-/commit/baeb97c3572bfcc41b0c13c8e93aa09ae15b7c35
- https://gitlab.winehq.org/wine/wine/-/commit/a99dc1a779c392980aed0ff12149a2b33966693e
Subsequently, testing with wine-10.19 the HOME and XDG_ env variables are not defined on the Windows side any more.
loathingkernel@pc ~ (master) $ WINEDEBUG=-all wine --version
wine-10.19 (Staging)
loathingkernel@pc ~ (master) $ WINEDEBUG=-all wine cmd.exe /c echo %HOME%
%HOME%
loathingkernel@pc ~ (master) $ WINEDEBUG=-all wine cmd.exe /c echo %WINE_HOST_HOME%
/home/loathingkernel
loathingkernel@pc ~ (master) $ WINEDEBUG=-all wine cmd.exe /c echo %XDG_CACHE_HOME%
%XDG_CACHE_HOME%
loathingkernel@pc ~ (master) $ WINEDEBUG=-all wine cmd.exe /c echo %WINE_HOST_XDG_CACHE_HOME%
/home/loathingkernel/.cache
loathingkernel@pc ~ (master) $ WINEDEBUG=-all wine cmd.exe /c echo %XDG_DATA_HOME%
%XDG_DATA_HOME%
loathingkernel@pc ~ (master) $ WINEDEBUG=-all wine cmd.exe /c echo %WINE_HOST_XDG_DATA_HOME%
%WINE_HOST_XDG_DATA_HOME%
In my case XDG_DATA_HOME is unset in my unix env, while XDG_CACHE_HOME is set.
As an external observer following Wine's development seems like this change is going to stay, it helps with keeping the Windows environment clean, but I do not know how this will be handled eventually with Proton 11.
Edit: Seems like wine-10.19 does handle this correctly according to https://github.com/CachyOS/proton-cachyos/issues/80#issuecomment-3580404882, it is just that I didn't import those changes into proton-cachyos because they are also tied to other changes that I didn't want to import. I guess this is on my side of things, and I should figure something out.
I had issues launching Resonite on Arch Linux, it kept saying that it couldn't find dotnet 10. After moving the game from my external drive to my system drive, it just worked (it was previously installed on my external drive)
related issue on the proton-cachyos github also CachyOS/proton-cachyos#80
A fix was merged 2 days ago and multiple users there report that the fix works. @shadowpanther, mind testing again with the proton-cachyos branch?
related issue on the proton-cachyos github also CachyOS/proton-cachyos#80
A fix was merged 2 days ago and multiple users there report that the fix works. @shadowpanther, mind testing again with the proton-cachyos branch?
A fix was merged, but the package was not published yet. When it releases, I'll test again.
proton-cachyos update was published today. Resonite runs just fine with this new version.