Bug occurs both with enabled and disabled Steam Runtime btw
Also doesn't occur when Resonite is started in screen mode
somehow fixed! you don't need to restart Steam entirely anymore, just SteamVR
not fully fixed, i should add
you still have to restart steamvr to get the game to launch, just not steam itself
Since the "Splittening" update in August 2025, Resonite uses a hybrid solution where the game engine runs natively on Linux while the Unity renderer runs in proton. Both processes communicate over a shared memory buffer, this setup is overall quite robust.
There is a problem however, Resonite has the ability to show your desktop in game while in VR. This will not work on Linux because the renderer is using this library to capture the desktop https://github.com/hecomi/uDesktopDuplication which only works on windows, and I believe proton lacks the implementation to translate those calls over currently.
The renderer for Resonite has been recently open sourced, you can view the issue about the desktop texture here: https://github.com/Yellow-Dog-Man/Renderite.Unity.Renderer/issues/19
[Proton 11.0 Beta / Experimental] Regression when attempting to launch Resonite on Steam.
Issue transferred from https://github.com/ValveSoftware/Proton/issues/9709.
@BlueCyro posted on 2026-04-24T08:34:26:
Resonite fails to launch on either Proton Experimental / Proton 11. The main game window does not show up and Steam closes it after several minutes.
With the above formality out of the way, I'd like to elaborate and give some additional context. A portion of our Linux users recently noticed that our program fails to Launch on Linux, and upon further investigation we determined that switching back to either Proton 10 or some 3rd-party flavor of Proton remedies the issue. This is why I believe this to be a regression with Proton rather than a bug related to our program.
According to the steam log attached above, this is because our program can't find a valid ICU package when Proton Experimental or Proton 11 is selected as the compatibility tool of choice.
Here's the relevant exception from the steam log (located at line 5889):
Process terminated.
Couldn't find a valid ICU package installed on the system. Please install libicu (or icu-libs) using your package manager and try again. Alternatively you can set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support. Please see https://aka.ms/dotnet-missing-libicu for more information.
at System.Environment.FailFast(System.Runtime.CompilerServices.StackCrawlMarkHandle, System.String, System.Runtime.CompilerServices.ObjectHandleOnStack, System.String)
at System.Environment.FailFast(System.Threading.StackCrawlMark ByRef, System.String, System.Exception, System.String)
at System.Environment.FailFast(System.String)
at System.Globalization.GlobalizationMode+Settings..cctor()
at System.Globalization.CultureData.CreateCultureWithInvariantData()
at System.Globalization.CultureData.get_Invariant()
at System.Globalization.CultureInfo..cctor()
at System.Globalization.CultureInfo.get_CurrentUICulture()
at System.TimeZoneInfo.GetUtcStandardDisplayName()
at System.TimeZoneInfo.CreateUtcTimeZone()
at System.TimeZoneInfo..cctor()
at System.DateTime.get_Now()
at Program.<<Main>$>g__Log|0_0(System.String, <>c__DisplayClass0_0 ByRef)
at Program+<<Main>$>d__0.MoveNext()
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[[Program+<<Main>$>d__0, Renderite.Host, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]](<<Main>$>d__0 ByRef)
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[[Program+<<Main>$>d__0, Renderite.Host, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]](<<Main>$>d__0 ByRef)
at Program.<Main>$(System.String[])
at Program.<Main>(System.String[])
Aborted (core dumped)
It appears that whatever new Linux runtime that Proton Experimental and Proton 11 ship with lacks the necessary ICU package(s) our program relies on for globalization. To reiterate: our program works fine on previous versions of Proton, such as Proton 10.
I personally do have the necessary ICU packages installed on my system, but this seemingly has no bearing on the issue.
An important note about our Linux compatibility: While we do require Proton/Wine to bootstrap our program, the majority of our engine actually runs as a native Linux process that downloads it's own .NET runtime (currently .NET 10 at the time of writing). Our engine then communicates over memory-mapped IPC to a barebones Unity game which we use as our renderer - this is why we even require Proton at all on Linux. We don't do anything nasty like try to break out of the environment either; all we do is launch a native Linux program within the runtime container alongside another which runs using Proton.
I bring this up to hopefully avoid any confusion that may arise should the mixture of native & Proton-related messages appear in the myriad of logs I've provided. Our hybrid "half Wine/Proton, half native" architecture is rather unique, so hopefully this tidbit helps provide context to anything that might seem somewhat strange in the logs.
We're currently having to direct our users to downgrade Proton in order to fix this, so anything that can be done would be much-appreciated!
@BlueCyro, regarding https://github.com/ValveSoftware/Proton/issues/7208#issuecomment-4313573766 (originally #9709):
While we do require Proton/Wine to bootstrap our program, the majority of our engine actually runs as a native Linux process that downloads it's own .NET runtime (currently .NET 10 at the time of writing). Our engine then communicates over memory-mapped IPC to a barebones Unity game which we use as our renderer - this is why we even require Proton at all on Linux.
Valve would have the last word on what they do and don't intend to support (cc @ttimo to check policies), but from my point of view as a Steam Runtime developer I don't think this is necessarily something that's supportable.
Proton guarantees to provide the Windows API, but only the Windows API: as an implementation detail, Steam happens to use a Steam Linux Runtime container as a way to run Proton, but there's no API guarantee about which Steam Linux Runtime container it is. It has changed over time:
LD_LIBRARY_PATH-based environment based on Ubuntu 12.04The newer versions of SLR don't (and can't) guarantee to contain all the same Linux libraries as the old ones, because of the way that ABIs evolve over time in Linux distros: for example SLR 2 has libicui18n.so.63 from Debian 10, SLR 3 has libicui18n.so.67 from Debian 11, and I don't think SLR 4 currently installs ICU at all, but if it did, it would be libicui18n.so.76 from Debian 13. Each of those libraries has an ABI that is incompatible with older and newer releases, so a native Linux game has to choose which one it is targeting.
For a native Linux game, the game developer would be able to choose which Linux API/ABI they are targeting: currently the choices are the legacy Steam Runtime 1 (scout), or SLR 3 (sniper), with SLR 4 hopefully being added as a third option in future. Whichever one the game developer chooses, they should compile in the corresponding branch of the Steam Runtime SDK (Docker/OCI container), and the game will usually be "pinned" to that major version for the lifetime of the game, with the underlying runtime only receiving changes that don't break compatibility. If a game is actively-maintained, the developer can swap to a newer (or older!) runtime at any time, by doing a new build in a different SDK, uploading it, and adjusting the metadata in the Steamworks partner interface at the same time they set the new build live: for example Valve did this when Team Fortress 2 moved from scout to SLR 3, and the Battle for Wesnoth team was an early adopter of SLR 3 that did a similar migration in the past.
But, for something that Steam believes to be a Windows game, the assumption is that the underlying Linux environment doesn't matter for the game itself and is only there to run Proton. Having a game that is flagged in Steam as being a Windows-only title, but which downloads and runs native Linux binaries if it happens to detect that it's being run under Proton, is definitely unusual and I don't think it's something that Valve is aiming to support.
One possible solution would be to have a Linux engine as backend and a Linux build of Unity as the renderer/frontend, and ship them as a native Linux game on Steam, the same way that e.g. Team Fortress 2 installs Windows binaries on Windows but installs native Linux binaries on Linux. I assume you'd want to flag this to run under SLR 3 (sniper), exactly like TF2 does - or even SLR 4, when that becomes available.
Another possible solution would be to use a fully-Windows build of the game, with no special Linux code, and rely on Proton to provide the necessary compatibility layer so the Windows version can run on Linux. Many (most?) titles on Steam work this way, for example Quake.
Another possible solution would be to build your own versions of dependency libraries that aren't involved in the graphics stack, like ICU, and statically link them into the Linux engine.
We don't do anything nasty like try to break out of the environment either
The game isn't "escaping" from the container, but by detecting that it's running under Proton and pivoting to native Linux code, it's breaking the assumptions of Steam's compatibility layer abstraction, which expects to be dealing with a Windows game or a Linux game, not a hybrid.
It would help us a lot if this was able to be fixed on Proton's end, considering this works properly under Proton 10, but breaks with update to Proton 11 Experimental.
We are not asking for something new, but something that has already worked with previous versions of Proton and is a regression from our point of view.
We're a relatively small team and some of the proposed solutions would put us at an disadvantage.
All in all, we'd like to kindly ask if there's possible considerations for this.
We have a relatively large Linux user base and we are, for the time being, relying on Proton to make our project run as well as it can for those users. If it breaks for us completely, we'll have to scramble and figure out workarounds.
Hello @Frooxius,
We are sorry you are having compatibility issues with Proton 11. We suggest pinning your game to Proton 10 to make sure the game doesn't break for your users. Please open a support ticket through the partner interface so we can discuss.
@Frooxius For now, we've added a global override to force Resonite to use Proton 10 by default. Users can still manually select a different Proton version. Proton 10 is officially a frozen branch now, so it will not receive updates or fixes (with some very rare minor exceptions).
proton 5.13x1 2026-04proton 11.0x1 2026-04proton experimentalx1 2026-04
Compatibility Report
System Information
I confirm:
Requested Logs
Functional Run - steam-2519830.log
Instant Crash - steam-2519830-crash.log
Symptoms
Starting from a fresh reboot, possibly just a restart of Steam, and thus SteamVR, you can run Resonite one time, and get a functional run. Close it and reopen it, and then VR_Shutdown is instantly called, resulting in the window only being open for around 2 seconds.
Reproduction