Steam Linux - Adobe substance not launch #701
Comments
|
As a short-term workaround, running Steam with @touraill-adobe, @Froyok, is this the same failure mode that you mentioned on a different issue? This issue is about Substance 3D Painter 2023, and you mentioned Substance 3D Painter 2024, but if that's an update of essentially the same product a year later, it seems reasonably likely that they're related. To investigate this further, we will need a log file for the scenario where it fails. https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information @kisak-valve, do you want to move this to ValveSoftware/steam-runtime? |
|
If this is a Qt problem, setting environment variable |
|
As a wild guess based on the dependencies of |
Yes it is the same problem, basically all recent versions of the Substance 3D apps no longer run after the client update (unless you launch the client with The errors we are getting are
so I think your guess is right. |
|
Some additional context: while we were initially building against the Steam runtime, we stopped doing so several years ago because the runtime was getting way too old for our needs. So we started building on a more recent Ubuntu and made that our only supported target. Since we bundle most of our dependencies, things mostly worked out. I'm not entirely sure why the change broke everything, I still haven't caught up with the latest evolutions of the runtime, by I read that the legacy runtime relied solely on |
|
In the future we might try to go back to building within the Steam runtime since it now seems to be well maintained, but what solutions do we have for our older applications (or the ones we might release in the meantime)? Currently we told our users to run their client with the "don't force slr flag" but you seem to hint that this flag will probably go away in a future release of the client. Wouldn't it be possible to let developers specify that their game should run natively, outside of any Steam runtime (leaving to them the responsibility of which distributions they would support)? Just launch the executable and that's it, without containers or |
|
I'm seeing here that you would be willing to update the runtime with some libraries to restore compatibility, that would be a nice solution I suppose. Is there anything I can try locally to check what are the missing pieces in the sniper runtime? If I can somehow add missing libraries one by one we could have an overview of what it would take to make the runtime compatible? |
|
Here is the full log in case it helps, I didn't use the verbose flag as it would require some curation on the output but there is not much more information than just " (And thanks for pointing me to those handy environment variables, I was looking for a way to troubleshoot some completely unrelated issues I have with a Windows game I run through Proton ^^). |
|
Hello,
It works, thank you very much for your help
…________________________________
De : Luc Touraille ***@***.***>
Envoyé : jeudi 7 novembre 2024 21:06
À : ValveSoftware/steam-runtime ***@***.***>
Cc : adx-fr ***@***.***>; Author ***@***.***>
Objet : Re: [ValveSoftware/steam-runtime] Steam Linux - Adobe substance not launch (Issue #701)
@touraill-adobe<https://github.com/touraill-adobe>, @Froyok<https://github.com/Froyok>, is this the same failure mode that you mentioned on a different issue?
Yes it is the same problem, basically all recent versions of the Substance 3D apps no longer run after the client update (unless you launch the client with -compat-force-slr off).
The errors we are getting are
* in the Scout runtime:
/home/luc/.local/share/Steam/steamapps/common/Substance 3D Designer 2024/Adobe Substance 3D Designer: error while loading shared libraries: libbrotlidec.so.1: cannot open shared object file: No such file or directory
* in the Sniper runtime:
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
—
Reply to this email directly, view it on GitHub<#701 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BMXYWYCMURYG7TRGWFTBRYTZ7PB23AVCNFSM6AAAAABRL53ED2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRTGEYTGNBSG4>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
I'm going to interpret this as: the workaround in #701 (comment) was successful, but there is still a dependency problem that needs to be solved by Adobe and/or Valve for future-proofing. |
Yes, this. In the new container runtime, your application can't see libraries from the host system in its search path (unless they are part of the recursive dependencies of the user-space graphics drivers, which for technical reasons we have to borrow from the host in most cases). This is good because it means the application can't make assumptions about libraries that it hopes are installed on the host system for other reasons, which maximizes the probability that an application that works in 2024 will still work in 2034, even after the host system has undergone incompatible changes (for example replacing However, for existing applications that already make assumptions about host-system libraries, it can cause regressions like this one. Arguably we're still providing better consistency between distributions, but unfortunately the consistent situation in this case is "doesn't work", which obviously isn't really what anyone wants.
It depends on the library, really. If the required library is small, has no dependencies that we don't already ship, and is under a "normal" permissive license, then we can probably just add it. If it's large, has large dependencies, or is under a strange license that lawyers don't want to have to think about, then we might have to say no. The The Qt 6 family is an example of something that we would not add without some significant thought, because it's rather large: we don't want to let the size of the runtime get out of control, because it's a disk space cost that every Steam-on-Linux user needs to pay.
Please do - that's what it's there for. The recommended version for new code is Steam Runtime 3 'sniper', for which you can get a SDK (as a Docker/Podman/Toolbx/OCI container, or a chroot tarball) from https://gitlab.steamos.cloud/steamrt/sniper/sdk/. There is also a "Platform" OCI image available from https://gitlab.steamos.cloud/steamrt/sniper/platform which you can use for compatibility testing. This only provides a rather old version of Mesa (so you'll probably only get software rendering) but hopefully that's enough for a simple smoke-test that verifies that your application can launch and load its mandatory plugins. The only libraries and versions that you can rely on having access to at runtime are the ones in the Platform image - on end-user systems, you will often see newer versions of libraries like Mesa and glibc, but those are an implementation detail and not part of the runtime's ABI guarantee. The intention is to have a series of newer container runtimes in future, "the same shape" as sniper but based on newer Debian releases. At the moment we have an internal-only branch based on Debian 12, and another based on Debian 13 prereleases. The Debian-12-based branch isn't available for general use at the moment because we don't want to take up more disk space than we need to, and it's possible that we'll skip past Debian 12 and go straight to a Debian-13-based runtime instead - we'll have to see what the timing of the Debian 13 freeze is like.
Yes, unfortunately this is a familiar story from various app/game developers. Steam Runtime 1 'scout' is very, very old (based on Ubuntu 12.04), but we can't upgrade it without breaking backwards-compatibility, and until relatively recently we were not ready to replace it with a container-based environment that mitigates the backwards-compatibility concerns. But, one of the flaws of the old For new software that you are willing and able to recompile, the intention is to encourage app/game developers to use Steam Runtime 3 'sniper'. For example, Valve has done this for Counter-Strike 2 and other flagship titles. I'm guessing you might want to do this for at least the 2024 versions of your apps? For legacy software that is shipped as a set of frozen binaries and not going to be recompiled, the Steam Linux Runtime 1.0 (scout) container is our backwards-compatibility story. For example, Valve is currently still using this for the older Half-Life and Portal games. It's intended to approximate the result of running the old If your app was compiled in a newer environment anyway (which environment?), then you might find that sniper is a better fit. sniper is based on Debian 11 from 2021, so it's generally newer than Ubuntu 20.04 (but older than 22.04).
The general answer is to identify all of your ELF executables and libraries, parse their Alternatively, if it's possible to launch your application in a Docker/Podman/Toolbx container with software rendering, you could try running it in the Platform image from https://gitlab.steamos.cloud/steamrt/sniper/platform. The advantage of that approach is that you can easily experiment with adding new packages (enter the container as root and do an It is also possible for an app/game developer to edit the SLR runtime in-place for local experiments (see https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/slr-for-game-developers.md#running-in-a-sdk-environment, https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/slr-for-game-developers.md#running-in-a-modified-platform-or-sdk-environment) and prepare a wishlist of missing libraries that way. Please don't suggest this to your users as a workaround, though! This is definitely in "unsupported tinkering" territory. If you're willing to switch an application to be run under SLR 3.0 (sniper), the official definition of what is in the sniper runtime is: sniper ABI. Most of those libraries are at the versions found in Debian 11, with a few key libraries like SDL and Vulkan-Loader backported from Debian 12 or newer (inspect the Platform or SDK OCI image to find specific versions). For legacy applications that run under SLR 1.0 (scout), officially the only thing you can rely on is what's in the scout ABI, mostly at the versions found in Ubuntu 12.04 (which is ancient), although it does have a significant number of backported packages from Debian 10 or newer. However, SLR 1.0 isn't actually a completely strict Steam Runtime 1 'scout' container, because we found that in practice, a lot of game developers have been compiling their games in a non-scout environment. Instead, it's actually a Steam Runtime 2 'soldier' container (based on Debian 10), with a |
Specifically, the information we need is the missing SONAME, Unfortunately, this is only the first missing library dependency: if your I think what I'm going to do as a first step is to see what the size impact would be if we add most of the |
|
I think I can try |
|
Adding only |
|
Thank you so much for the very detailed summary of the current state of things and options we have, this is very very much appreciated ❤️. As a side note, we were discussing internally about how we missed all those latest developments on the SLR, and learned about the breaking update only after it was released; what would be the best channel to keep up-to-date with those changes, is there a newsletter/mailing list we should subscribe to? |
|
|
I imagine this one should be reasonably straightforward. I'll see what happens if I add the whole
I'm a little surprised that you need this when you're (presumably!) not implementing a desktop environment; but it's small, so we might be able to add this too. I'll look into it.
This is present in both soldier and sniper, and has been for a long time, so I'm surprised you're not finding it. Can I see a
This is not part of either the soldier or sniper ABI, which includes the older Sorry, we are unlikely to add If the dependency is in a plugin, you might be able to mitigate the crash risk by dlopening it with Or, if you are able to recompile in the sniper SDK against the sniper ABI so that you get a dependency on the older In the longer term, if we do a new runtime based on Debian 12 (Steam Runtime 4, 'medic' exists as an internal beta but is not currently available to the public) or Debian 13 (Steam Runtime 5 exists as an internal alpha, but we certainly can't usefully release that to the public until Debian 13 has frozen), those will include
This is associated with newer versions of
Sorry, I don't know a library of this name and neither does The I think you'll need to bundle your own copy of this library.
This wasn't added to Debian until after Debian 11, so isn't trivially available in sniper (and I'm somewhat surprised the app works reliably if this is a mandatory dependency, since it seems like a feature that host OSs might just skip). We also disable this feature in our |
I think I must have rushed my investigation on Painter 2024 earlier, I redid some tests and only had to copy Also we are much aware that by leaving the runtime, we gave up on compatibility with many distributions. This is a trade-off we accepted at the time, and communicated to our users; we will definitely reevaluate this choice in the light of the new runtimes/SDKs you are providing, which seem really neat. So we have no expectations that our older apps will continue running on newer distributions (at least not without tweaks), and we don't expect Steam to somehow make those apps forward compatible, since we decided to build outside the runtime, with full knowledge of the facts. Some additional information I'd like to have to discuss with the teams before coming back to you:
And again, thanks for the help! 🙇 |
It's possible that you were affected by ValveSoftware/steam-for-linux#11448, a regression in which some titles are run in an incorrect runtime, which I found today while investigating this issue. I hope that a Steam developer can address that issue soon (I cannot). You can tell for sure which runtime you are in by looking at Steam Linux Runtime 1.0 (scout) looks like this in
The key facts to look for are that it uses Steam Linux Runtime 3.0 (sniper) looks more like this:
The key facts to look for are that this time, it uses For comparison, the legacy
If you want to check this programmatically from inside your application, the facts to look at are:
[1] typically |
Aha, that makes sense. I'm hoping to add this library to future versions of all container runtimes so that you can rely on having it around.
I'm also hoping to add this, and a bunch of the other
If those are all you need, then adding them to the runtime will be sufficient. If you find that you need more libraries, please ask and we can discuss the right way to address them (either adding them to the runtime, or asking you to bundle them with your app). If necessary we can do this iteratively, smallest/easiest/least-controversial libraries first, until everything is resolved.
Sorry, I can't answer those policy questions: my role here is to make each of the various runtimes work as well as possible, and it's up to Valve/Steam developers which ones they do or don't offer to app developers and users. @TTimo might be able to shed some light on this, though? My personal recommendation, if you can, would be to build your app as purely x86_64 (no 32-bit code) in the Steam Runtime 3 'sniper' SDK, and flag it to run under Steam Linux Runtime 3.0 (sniper). That is the "modern" runtime environment that we are increasingly aiming to recommend for new titles. I realise that for your particular app, this will probably not be possible until we can add a few more libraries to sniper. Adding the first few of those is in progress.
Again, whether that is offered or not is not up to me. It's an option that is available for Valve to consider, if they want to. I would request that if this is added, it should not be referred to as "native", because that can mean several different things in the context of Linux gaming and it's better if we can avoid that ambiguity. We often use "native" in the context of "native Linux executables, not a Windows executable via Wine/Proton/emulation", because I don't think there's any other good name for that; but others often use "native" to mean some different thing like "host OS libraries, not the Steam Runtime" (I think that's what you're requesting here), or "host OS packaging system, not Flatpak/Snap/AppImage", or "non-sandboxed, not Flatpak/Snap/Firejail", or even "using the OS's GUI look-and-feel, not an unrelated UI toolkit". Sometimes this comes with an implicit value-judgement where "more native" is assumed to be better (which is not necessarily true). From the point of view of the Steam Runtime, I would describe the environment you're suggesting here as having two major aspects: the host OS's library stack (with no special compatibility layers), and no container boundary. That is not actually something that Steam has ever officially offered: even in 2013 when Steam first became available on Linux, all games ran in the There are two compatibility issues with having your app use such a thing. The first is that on distros that do not match the one you support (older, newer, or just different), some libraries and external executables can be incompatible because they are older or newer, making ABI compatibility a moving target over time; it seems you might be addressing that by officially requiring a single, specific distro. The second, which is more subtle, is that you're also relying on the list of libraries and external executables that are preinstalled by the distro: for example, you might be able to assume that users of a relatively complete GNOME or KDE desktop will always have #702 is an interesting example of the "list of executables" problem: typical GNOME or KDE systems will have |
|
Addition of Note that because of the way these components get released internally, this change will show up as an update to the You can opt-in to beta versions of SLR 2.0 by locating it in your Library, then following instructions similar to https://help.steampowered.com/en/faqs/view/5A86-0DF4-C59E-8C4A - but instead of changing the properties of Counter-Strike 2, you would change the properties of SLR 2.0 to use the |
That's great news, thank you! I can confirm that at least Sampler 2023, Designer 2024 and Painter 2024 now launches successfully in the |
|
For historical native Linux titles (which are assumed to be targeting scout unless configured otherwise), this is believed to be fixed by Note that even though the compatibility tool indicated in the UI is For native Linux titles where the developer has specifically opted-in to using sniper, this is fixed in To opt-in to a compatibility tool beta, follow instructions similar to https://help.steampowered.com/en/faqs/view/5A86-0DF4-C59E-8C4A, but instead of locating Counter-Strike 2 and changing its Properties, you would do the same for SLR 2.0 and/or SLR 3.0 (whichever one is appropriate, if in doubt do both). If I am reading SteamDB correctly, Adobe's Substance 3D Designer 2024 and Substance 3D Painter 2024 are currently assumed to be scout titles, so Steam will run them in a Similarly, the retired title that is labelled as either Substance 3D Sampler 2023 or Sampler 2024 (depending where I look) is also currently assumed to be a scout title. If you want to run it as a sniper title, please configure it accordingly in the partner web interface. If you find that you need other libraries, we can discuss whether they should be added to a suitable runtime or bundled with your app. It might be better if we take that discussion to a new issue report per batch of libraries, so that each batch is immediately actionable. |
This change has now been copied to the default branch.
This doesn't seem to have changed: these titles are still being treated as targeting Steam Linux Runtime 1.0 (scout). If Adobe's intention is for the newer Steam Linux Runtime 3.0 (sniper) container to be used, then action will still required from Adobe to set that up.
I think it might be best if we close this issue now, and an Adobe developer can open a new issue as a continuation of this one if you find that more libraries are necessary. |
|
Sorry I missed your message from last week.
This is great news, we will do a new round of testing outside the beta, thanks!
Yes, we didn't make the switch on Steamworks before the release of the beta runtime as it would have prevented the
We noticed some problem related to Thanks for your help! |
Ah, yes, I can see that being a reason to not switch to sniper. You are correct to think that
If it helps, OpenSSL in sniper is Confusingly, there is also After you have moved these titles to run in sniper, recompiling your copy of Qt in a sniper container should give you a binary that will not have warnings about version mismatches. |
Hello,
After asking for steam support for “Adobe Substance 3D Painter 2023” doesn’t launch.
Teamthe support returned me :
“I am sorry to hear that you are experiencing an issue running Substance 3D Painter 2023 using our Steam Play Proton feature for Linux.
Please submit all issues or bugs occurring when using this feature, to the Valve - Proton Github bug database using a GitHub account. This database is regularly reviewed by the Valve development team.”
Steam Support
Chris”
I tested run to steam application and to the terminal but same result, it appear substance image after open steams application and nothing.
In the terminal :
steam.sh[6467]: Running Steam on debian 12 64-bit
steam.sh[6467]: STEAM_RUNTIME is enabled automatically
setup.sh[6505]: Steam runtime environment up-to-date!
steam.sh[6467]: Steam client's requirements are satisfied
CProcessEnvironmentManager is ready, 6 preallocated environment variables.
[2024-11-07 18:31:53] Startup - updater built Nov 5 2024 21:33:18
[2024-11-07 18:31:53] Startup - Steam Client launched with: '/home/adx/.steam/debian-installation/ubuntu12_32/steam' '-srt-logger-opened' 'steam://run/2199970'
11/07 18:31:53 minidumps folder is set to /tmp/dumps
11/07 18:31:53 Init: Installing breakpad exception handler for appid(steam)/version(1730853027)/tid(6578)
[2024-11-07 18:31:53] Loading cached metrics from disk (/home/adx/.steam/debian-installation/package/steam_client_metrics.bin)
[2024-11-07 18:31:53] Using the following download hosts for Public, Realm steamglobal
[2024-11-07 18:31:53] 1. https://client-update.fastly.steamstatic.com, /, Realm 'steamglobal', weight was 900, source = 'update_hosts_cached.vdf'
[2024-11-07 18:31:53] 2. https://client-update.akamai.steamstatic.com, /, Realm 'steamglobal', weight was 100, source = 'update_hosts_cached.vdf'
[2024-11-07 18:31:53] 3. https://client-update.steamstatic.com, /, Realm 'steamglobal', weight was 1, source = 'baked in'
[2024-11-07 18:31:53] Verifying installation...
[2024-11-07 18:31:53] Verification complete
UpdateUI: skip show logo
Steam logging initialized: directory: /home/adx/.steam/debian-installation/logs
XRRGetOutputInfo Workaround: initialized with override: 0 real: 0xf03d7780
XRRGetCrtcInfo Workaround: initialized with override: 0 real: 0xf03d6050
steamwebhelper.sh[6589]: Using supervisor /home/adx/.steam/root/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-supervisor
steamwebhelper.sh[6589]: Starting steamwebhelper under bootstrap sniper steam runtime via /home/adx/.steam/debian-installation/ubuntu12_64/steam-runtime-sniper.sh
steamwebhelper.sh[6589]: Using CEF sandbox (try with -no-cef-sandbox if this fails)
steamwebhelper.sh[6589]: Starting steamwebhelper with Sniper steam runtime at /home/adx/.steam/debian-installation/ubuntu12_64/steam-runtime-sniper/_v2-entry-point
exec ./steamwebhelper -lang=en_US -cachedir=/home/adx/.steam/debian-installation/config/htmlcache -steampid=6578 -buildid=1730853027 -steamid=0 -logdir=/home/adx/.steam/debian-installation/logs -uimode=7 -startcount=0 -steamuniverse=Public -realm=Global -clientui=/home/adx/.steam/debian-installation/clientui -steampath=/home/adx/.steam/debian-installation/ubuntu12_32/steam -launcher=0 -use_xcomposite_workaround -no-restart-on-ui-mode-change --valve-initial-threadpool-size=6 --valve-enable-site-isolation --enable-smooth-scrolling --disable-gpu-compositing --disable-gpu --password-store=basic --log-file=/home/adx/.steam/debian-installation/logs/cef_log.txt --disable-quick-menu --disable-features=SpareRendererForSitePerProcess,DcheckIsFatal,ValveFFmpegAllowLowDelayHEVC
Steam Runtime Launch Service: starting steam-runtime-launcher-service
Steam Runtime Launch Service: steam-runtime-launcher-service is running pid 6819
bus_name=com.steampowered.PressureVessel.LaunchAlongsideSteam
Desktop state changed: desktop: { pos: 0, 0 size: 4480,1440 } primary: { pos: 0, 0 size: 2560,1440 }
Caching cursor image for left_ptr, size 24x24, serial 1764, cache size = 0
BuildCompleteAppOverviewChange: 132 apps
BuildCompleteAppOverviewChange: 132 apps
chdir "/home/adx/.steam/debian-installation/steamapps/common/Substance 3D Painter 2023"
Game Recording - would start recording game 2199970, but recording for this game is disabled
Adding process 6947 for gameID 2199970
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: minimal, offscreen, xcb.
Game Recording - game stopped [gameid=2199970]
Removing process 6947 for gameID 2199970”
I have removed steam application and "Adobe substance" but same result.
Can you help me, I need this application for my work.
Thanks for your prompt return.
My system
OS : Debian 12 Bookworm (actual OS)
OS : Fedora 41 (tested but same result)
Steam Version : 1730853027
Kernel : 6.1.0-26-amd64 (tested same result)
Kernel : 6.10.11+bpo-amd64
Desktop : GNOME v.43.9
CPU : Intel Core i9-10850K
GPU : GeForce RTX 4070 Ti SUPER
The text was updated successfully, but these errors were encountered: