How are you detecting this?

How are you detecting this?

I run a game that i know has problems with wine wayland, that being games that use the rockstar launcher.

Rockstar launcher under wine wayland right now is white so you cant see anything and its because of CEF or something not supporting wayland, then wine wayland does not support system tray icon support yet so it creates a rockstart window for that applet.

Simply trying to use wine wayland launch commands with ge-proton with this new improvement it wont work and it runs under xwayland, this problem is related similar to the mangohud issue which is basically no launch commands work under this new improvement.

https://github.com/ValveSoftware/steam-for-linux/issues/13008#issuecomment-4097781697

Same issue with using SDL_Video_Driver=wayland. Tested CounterStrike 2 with said launch param. and game launches on xwayland. Confirmation that it was xwayland was done using xeyes.

Also on RT3 client.

Custom environment variables in the Launch Options don't work in the steamrt3c-based Steam client yet. It's actually the same root cause as #13008, just with a less serious impact.

This affects all environment variables that are prefixed to the %command% in this way.

@kisak-valve, perhaps retitling this to something like [SteamRT3] Can't use custom environment variables in Launch Options would cover all cases of it and avoid some duplicate reports?

Same issue with using SDL_Video_Driver=wayland

FYI, the correct environment variable for SDL 3 is SDL_VIDEO_DRIVER=wayland: environment variables are usually case-sensitive (although SDL might be parsing case-insensitively, because the way it handles the environment is a bit unusual).

The "3rd party game" and "Proton" labels can probably also be removed: this is going to affect every situation where players add a workaround/tweak that looks like FOO=bar %command%, in every game.

It also affects regular Steam Beta (non steamrt3 users) as of the latest update to the Steam beta.

Try adding env -- in front of the command option.

e.g.

env -- MANGOHUD=1 %command% -force-d3d12

I'm also having this issue. Many thanks to @Billli11 as their solution fixed it for the time being.

Fedora 43 (kernel 6.19.8-200.fc43.x86_64)
GPU: AMD Radeon RX 7700S (Framework 16 dGPU)
Steam Client beta: Yes

I also experience this issue since today. I have noticed in the ~/.local/share/Steam/logs/gameprocess_log.txt that the ENV vars get appended instead of prepended on Client version: 1774488570 (installed with pacman on Arch linux https://archlinux.org/packages/multilib/x86_64/steam/) but it was not the case on Client version: 1774306123

Shoutout to @Billli11 as their solution worked for me too.

It also affects regular Steam Beta (non steamrt3 users) as of the latest update to the Steam beta.

Yes, I can reproduce this (and I can see why it happens). @kisak-valve, it would probably make sense to change the title to [Beta] … since this regression now affects all beta users.

Try adding env -- in front of the command option.

e.g.

env -- MANGOHUD=1 %command% -force-d3d12

I can confirm that this is a good workaround from the Steam Runtime's point of view, and it is likely to continue to work equally well in future Steam clients.

I've reported the regression for the FOO=bar %command% pattern internally, hopefully that pattern can be made to work again in a future beta (without regressing the steamrt3c client or the env -- FOO=bar %command% pattern).

have noticed in the ~/.local/share/Steam/logs/gameprocess_log.txt that the ENV vars get appended instead of prepended

More precisely, they get inserted into the middle of the long command-line that Steam launches: in ~/.steam/steam/logs/console_log.txt you'll see something like this (using Retroarch as my example game here):

/bin/sh\0-c\0…/steam-launch-wrapper -- …/reaper SteamLaunch AppId=1118310 -- MANGOHUD=1 '…/SteamLinuxRuntime_sniper'/_v2-entry-point --verb=waitforexitandrun -- '…/RetroArch/retroarch.sh'\0

instead of what happened previously, which looked more like

/bin/sh\0-c\0MANGOHUD=1 …/steam-launch-wrapper -- …/reaper SteamLaunch AppId=1118310 -- '…/SteamLinuxRuntime_sniper'/_v2-entry-point --verb=waitforexitandrun -- '…/RetroArch/retroarch.sh'\0

Just adding my +1 where games with launch options no longer launch successfully since updating to Steam Version: 1774488570 (SteamRT3 currently disabled)

changing my launch options per @Billli11 suggestion did workaround the issue and games (Elden Ring) successfully launch once again.

env -- DRI_PRIME=1 %command%

Note: I stopped enabling SteamRT3 as it seemed to have an issue finding my Game Library on a secondary drive (issue #13007 )... but while I had it enabled and when it did find the Game Library it had no issues launching games with Launch options set (in a previous build)... so odd that my experience was different, but explains why I never found this launch option issue until the recent build.

I can +1 as well. Launch options like gamemoderun mangohud %command% worked just fine but when trying to set environment flags like PROTON_LOG=1 games refused to launch.

Fedora 43
AMD 7800xt
AMD 5800x3d
Steam beta client
both RT3 and non-RT3 client versions

I forgot I was even on the Beta client.. I had to double check just now, and sure enough I am.

Glad I'm not the only one having this issue, and thanks a ton to Billli11 for the workaround!

This started happening immediately after I got build 1774488570. Billli11's workaround of prepending env -- worked, but it appears to launch abnormally in the console.
Arch Linux, RT3 and Non-RT3.
EDIT: This is now resolved in 1774577504 🎉

Seems that 1774577504 has resolved the issue for me. I was able to remove env -- from my launch options, resulting in DRI_PRIME=1 %command% successfully launching the game as normal.

SteamRT3 disabled in my scenario