Requesting For com.valvesoftware.Steam To Default To Mesa-23.2.1 #1193
Comments
|
Your assumption is incorrect. This app is using runtime version 23.08 and as such Mesa 23.2.1. Apps cannot choose which version of Mesa they use, they get whichever Mesa runtime ships. |
Pardon. it's what we assumed on the Void repository. Me, I'm not familiar with flatpak development. The error above still stands, however, and I know for certain that non-flatpak runtime version does not get such an error with I may need to then close as not planned, but, before I do, any idea anyone what could be causing this error, otherwise? |
|
I'm not entirely fluent with what is happening here and whether pressure-vessel (subsandboxing) is related or not. It might be useful to have a simpler reproducer (without subsandbox) |
|
Anything I can be of help with? Unfortunately, I'm not familiar enough with flatpak's inner workings. Symptoms would point for the flatpak runtime to be calling for Maybe the sandbox has been breached, somehow? EDIT: Clarified some things |
|
Reddit user Z3roKelvin at https://reddit.com/r/voidlinux/comments/18b592n/steam_suddenly_not_working_on_flatpak/ has posted a very similar output: I have been using the flatpak version of steam for about a month, and today it decided not to work. I looked at some other posts suggesting I should downgrade mesa, but that did nothing. I am using an AMD Radeon RX 6800 XT graphics card running the open source drivers on Xorg. Here is what happens when I try to start steam: I can also confirm that the OP error persists even given updates of |
|
Given the following output of
The above issue still persists. |
|
I assume everyone here has flatpak 1.12 or newer, right? |
Output of
|
|
If you run the app with |
|
This is getting weirder. Now I get this: Output is the same even without This error is even picked up by the WM ( Yet: I don't understand the following:
|
|
Do you have beta or stable version of the app installed? The error sounds like you are missing i386 compat extensions. You should be getting those automatically when you install stable version of app. |
As I said here, I'm on stable. BUT, nevermind, I solved this. It actually was a device permission problem, brought both by a rather counter-intuitive conflict with my If anyone comes across this error, remember to check your Even then, it may still not work, as the user on reddit cited above mentioned, and as it happened to me, depending on your OS defaults (I presume any non-standard device loading ruleset may contribute). Thus, the easiest way is to then install also Indeed, my Not really sure why a device (The GPU in this case, even though GPU accelleration was for sure working and accessible) that can't be accessed was being reported as a At best, maybe Sorry for wasting your time, but the error was very counter-intuitive, and error reporting routines (On the terminal, developers were very helpful on github) didn't help at all. Could anyone close this as "not a bug"? |
|
It is truly strange that the allow=multiarch wasn't there to begin with. The app recipe sets it here https://github.com/flathub/com.valvesoftware.Steam/blob/beta/com.valvesoftware.Steam.yml#L38 and it's mandatory. I have the recollection Mesa in general gives very bad output when device loading fails unless you explicitly request better output through LIBGL_DEBUG=verbose. This gives typically good enough output that you can figure out why loading fails. I suggest closing the issue yourself, there is no specific not a bug way to close the issue. I have stepped down as maintainer but thought to try to help troubleshoot this one since I was involved earlier. |
|
Yet, even disabling I guess you may connect the dots and realize it's actually a device access error, but you may also think something went missing during libGL installation, or some driver woes, or some filesystem corruption. The Thanks for the help @nanonyme Closing this as completed EDIT: Forgot to close with comment, closed manually |
We at Void were having the following non-distribution-specific error:
void-linux/void-packages#46649 quote for quote (Check the link for full description):
"
Relevant error log (Flatpak, but its steam-1.0.0.78_3 equivalent is largely identical) is as follows:
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1) amdgpu: amdgpu_device_initialize failed. libGL error: glx: failed to create dri3 screen libGL error: failed to load driver: radeonsi Steam Runtime Launch Service: starting steam-runtime-launcher-service Steam Runtime Launch Service: steam-runtime-launcher-service is running pid 336 steam-runtime-launcher-service[336]: E: Unable to acquire bus name "com.steampowered.PressureVessel.LaunchAlongsideSteam" amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1) amdgpu: amdgpu_device_initialize failed. libGL error: glx: failed to create dri3 screen libGL error: failed to load driver: radeonsi"
Which was eventually solved by void-linux/void-packages#46649 (comment) (Update to
mesa-23.2.1_2) at least onsteam-for-linuxnative binary, confirming thus thatmesa-23.1.9indeed throws the aforementionedauth/libGLerror.com.valvesoftware.Steamstill suffers from the aforementioned error, however, presumably due to defaulting tomesa-23.1.9.Indeed, on my system:
I presume thus that
com.valvesoftware.Steamdefaults tomesa-23.1.9, hence resulting in the aforementioned error.Presumably, defaulting
com.valvesoftware.Steamtomesa-23.2.1would fix this error.I thus formally request for maintainer(s) to try and verify if defaulting
com.valvesoftware.Steamtomesa-23.2.1would be possible in the near future.Thanks to developers for all their efforts, regardless.
The text was updated successfully, but these errors were encountered: