%COMMAND% / %command% seems to not be expanded properly in "Set Launch Options"

[jjmcdn]

Your system information

• Steam client version: 1468023329 (Built: Jul 8 2016, at 21:44:35)
• Distribution (e.g. Ubuntu): Debian 8 (with brewmaster_beta repos added)
• Opted into Steam client beta?: [Yes/No] Yes
• Have you checked for system updates?: [Yes/No] Yes

Processor Information: CPU Vendor: GenuineIntel CPU Family: 0x6 CPU Model: 0x3a CPU Stepping: 0x9 CPU Type: 0x0 Speed: 3300 Mhz 8 logical processors 4 physical processors HyperThreading: Supported FCMOV: Supported SSE2: Supported SSE3: Supported SSSE3: Supported SSE4a: Unsupported SSE41: Supported SSE42: Supported AES: Supported AVX: Supported CMPXCHG16B: Supported LAHF/SAHF: Supported PrefetchW: Unsupported

Operating System Version: Debian GNU/Linux 8.5 (jessie) (64 bit) Kernel Name: Linux Kernel Version: 4.6.0-rc3-burny+ X Server Vendor: The X.Org Foundation X Server Release: 11604000 X Window Manager: Openbox Steam Runtime Version: steam-runtime-beta-release_2016-06-15

Video Card: Driver: Intel Open Source Technology Center Mesa DRI Intel(R) Ivybridge Mobile x86/MMX/SSE2

Driver Version:  3.0 Mesa 10.6.3
OpenGL Version: 3.0
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 60 Hz
VendorID:  0x10de
DeviceID:  0xfd1
Revision Not Detected
Number of Monitors:  2
Number of Logical Video Cards:  2
Primary Display Resolution:  1920 x 1080
Desktop Resolution: 1920 x 1848
Primary Display Size: 23.54" x 13.23"  (26.97" diag)
                                        59.8cm x 33.6cm  (68.5cm diag)
Primary VRAM Not Detected

Sound card: Audio device: VIA VT1802

Memory: RAM: 7883 Mb

NOTE Not reported above by steam is my Optimus graphics card:

VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 650M] (rev ff) (prog-if ff)

Please describe your issue in as much detail as possible:

My steam client comes up fine and I'm able to install games with no trouble. I am running steam directly from the command line (that is, I am not using a command such as primusrun steam).

For most (all?) of my games, if I go in to *Set Launch Options" and enter a command like this:

optirun %command%

or:

optirun %COMMAND%

when I click on the "Play" button the game begins to launch but it won't get to draw the initial window before the ends and in the steam client UI I see "syncing..." and the game is now done (though the UI updates my 'last played' time accordingly as if I had been playing it.

If, however, I set my launch option to something like this:

optirun /home/joe/.steam/steam/steamapps/common/they bleed pixels/TheyBleedPixels

(cut and paste directly from my client) the game launches successfully with Optimus enabled.

Steps for reproducing this issue:

1. Launch the steam UI.
2. Select a game without custom launch options.
3. Enter 'optirun %COMMAND%' for example.
4. Attempt to launch the game. Game fails to launch.
5. Replace '%COMMAND%' with full path to game binary.
6. Attempt to launch the game. Game launches successfully.

[vlv-henryg]

If you leave the launch options blank, does the game launch successfully, and does it run with the proper video card?

[Tele42]

For what it's worth, when there is no %COMMAND% in the launch options, it is implied to be at the start. Therefore, having optirun /home/joe/.steam/steam/steamapps/common/they bleed pixels/TheyBleedPixels in the launch options is expected to put the options after the launch command, so TheyBleedPixels runs on the Intel gpu in this case, and the game is most likely ignoring what is being passed to it.

This sounds like yet another optirun compatibility issue with the steam runtime. But my gut says that TheyBleedPixels does not work well with virtualgl, the default bridge used with optirun, and you may want to try optirun with the primus bridge (optirun -b primus %COMMAND%).

[jjmcdn]

@vlv-henryg Some games, like They Bleed Pixels, Terraria, and so on, will launch successfully, yeah, but they're not using the NVidia card (or it seems like they are not based on the game performance).

[jjmcdn]

@Tele42 That's good to know. The example I quoted is just an example, though, with the current setup none of my games start with optirun (or primusrun, for that matter) in the custom options with %COMMAND% / %command% (which is it, by the way, or is it case-insensitive, I've seen both in the forums and nobody seems to have said definitively upper-case versus lower-case).

I'll re-test in a bit with optirun specifically calling primus as the bridge, but when I placed primusrun at the start of the command line, I was getting the same results.

Since I'm running Steam from an Xterm, I've been watching for additional log information but there doesn't seem to be anything like an error. Is there an environment variable I can set or something to make the stdout logging more verbose? Maybe that might point at the issue?

[Tele42]

Also, you may also need LD_PRELOAD="libpthread.so.0 libGL.so.1" (from #3506).

[jjmcdn]

@Tele42 No joy. I tried both They Bleed Pixels and Bastion with the following commands:

LD_PRELOAD="libpthread.so.0 libGL.so.1" optirun -b primus %command%
LD_PRELOAD="libpthread.so.0 libGL.so.1" optirun  %command%
LD_PRELOAD="libpthread.so.0 libGL.so.1" __GL_THREADED_OPTIMIZATIONS=1 optirun  %command%

all mentioned in #3506, all without success. The game never comes up but the UI goes from Running to Syncing to done within maybe half a minute and nothing else seems to be going on.

[Tele42]

@joeythesaint, can you check which version of libdrm-intel1 is on your system? libdrm-intel1-2.4.58 is known incompatible with optimus.

[jjmcdn]

@Tele42: It is, in fact, 2.4.58:

~ apt search libdrm-intel
Sorting... Done
Full Text Search... Done
libdrm-intel1/stable,stable,stable,now 2.4.58-2 amd64 [installed,automatic]
  Userspace interface to intel-specific kernel DRM services -- runtime

libdrm-intel1-dbg/stable,stable,stable 2.4.58-2 amd64
  Userspace interface to intel-specific kernel DRM services -- debugging symbols

but I also tried to follow the advice in #3506 and fetched an older one from the Debian repos and placed them in my .steam directory:

~ ls -lart /tmp/x/libdrm-*deb
-rw-r--r-- 1 joe  63442 Aug 10  2014 /tmp/x/libdrm-intel1_2.4.56-1_amd64.deb
-rw-r--r-- 1 joe 181084 Aug 10  2014 /tmp/x/libdrm-dev_2.4.56-1_i386.deb
-rw-r--r-- 1 joe 177954 Aug 10  2014 /tmp/x/libdrm-dev_2.4.56-1_amd64.deb
-rw-r--r-- 1 joe  65834 Aug 10  2014 /tmp/x/libdrm-intel1_2.4.56-1_i386.deb
-rw-r--r-- 1 joe  29362 Aug 10  2014 /tmp/x/libdrm2_2.4.56-1_amd64.deb
-rw-r--r-- 1 joe  31210 Aug 10  2014 /tmp/x/libdrm2_2.4.56-1_i386.deb
~ ls -l .steam/ubuntu12_*/libdrm*
-rw-r--r-- 1 joe  54166 Aug 10  2014 .steam/ubuntu12_32/libdrm.a
-rw-r--r-- 1 joe 163994 Aug 10  2014 .steam/ubuntu12_32/libdrm_intel.a
lrwxrwxrwx 1 joe     21 Aug 10  2014 .steam/ubuntu12_32/libdrm_intel.so -> libdrm_intel.so.1.0.0
lrwxrwxrwx 1 joe     21 Aug 10  2014 .steam/ubuntu12_32/libdrm_intel.so.1 -> libdrm_intel.so.1.0.0
-rw-r--r-- 1 joe 146228 Aug 10  2014 .steam/ubuntu12_32/libdrm_intel.so.1.0.0
lrwxrwxrwx 1 joe     11 Jul 11 18:38 .steam/ubuntu12_32/libdrm.so -> libdrm.so.2
lrwxrwxrwx 1 joe     15 Aug 10  2014 .steam/ubuntu12_32/libdrm.so.2 -> libdrm.so.2.4.0
-rw-r--r-- 1 joe  50756 Aug 10  2014 .steam/ubuntu12_32/libdrm.so.2.4.0
-rw-r--r-- 1 joe  65166 Aug  6  2014 .steam/ubuntu12_64/libdrm.a
-rw-r--r-- 1 joe 200042 Aug  6  2014 .steam/ubuntu12_64/libdrm_intel.a
lrwxrwxrwx 1 joe     21 Aug  6  2014 .steam/ubuntu12_64/libdrm_intel.so -> libdrm_intel.so.1.0.0
lrwxrwxrwx 1 joe     21 Aug  6  2014 .steam/ubuntu12_64/libdrm_intel.so.1 -> libdrm_intel.so.1.0.0
-rw-r--r-- 1 joe 135232 Aug  6  2014 .steam/ubuntu12_64/libdrm_intel.so.1.0.0
lrwxrwxrwx 1 joe     11 Jul 11 18:38 .steam/ubuntu12_64/libdrm.so -> libdrm.so.2
lrwxrwxrwx 1 joe     15 Aug  6  2014 .steam/ubuntu12_64/libdrm.so.2 -> libdrm.so.2.4.0
-rw-r--r-- 1 joe  47568 Aug  6  2014 .steam/ubuntu12_64/libdrm.so.2.4.0

I've exited and re-started steam since that and still no success. That said, the thread referenced a different location for the ubuntu12_* directories than what I found in my install, so it might be I've got to change (or add to) my LD_LIBRARY_PATH? Is there any way in the steam UI to determine which shared libs it is finding?

[Tele42]

@joeythesaint something's not right with how you're injecting that library into steam ... if you need to fiddle with libraries used by games, adjust the steam-runtime folder (~/.steam/ubuntu12_32/steam-runtime), however, common practice has been to make the system libraries sane, then LD_PRELOAD the system libraries as needed or remove the steam runtime variant.

[jjmcdn]

@Tele42 Okay, so what's the recommendation to try here? Based on the comment https://github.com/ValveSoftware/steam-for-linux/issues/3506#issuecomment-101027659 I thought putting the shared libs (actually, just doing the script in https://github.com/ValveSoftware/steam-for-linux/issues/3506#issuecomment-102565272 by hand) would get me where I need to be. It sounds like you're saying the better approach is to clean up my system libdrm-intel1 instead and avoid LD_PRELOAD unless I need it.

So if that's the recommended approach, these are the versions that appear to be easily installable:

~ apt show libdrm-intel1 -a | egrep '(Package:|Version)'

WARNING: apt does not have a stable CLI interface yet. Use with caution in scripts.

Package: libdrm-intel1
Version: 2.4.68-1~bpo8+1
Package: libdrm-intel1
Version: 2.4.62-1+bsos1
Package: libdrm-intel1
Version: 2.4.58-2

Given that 2.4.58 is the installed one and it has known issues, I'm happy to grab one of the newer ones, are there known issues with either 2.4.62 or 2.4.68 I should be aware of?

[Tele42]

In this case I'd update the system library. The specific issue with libdrm was fixed with 2.4.61 and I do not know what's changed between 2.4.62 and 2.4.68.

I should have directly referenced this before, when there are steam runtime issues, most users have been adapting the advise at https://wiki.archlinux.org/index.php/Steam/Troubleshooting#Steam_runtime_issues for their distro.

[jjmcdn]

Okay, update on this. Upgrading my system-wide libdrm-intel1 ended up being a non-trivial affair but the results are definitely more satisfactory than dumping special-purpose shared libs into my .steam hierarchy. Now that I've done that, all seems to be well. FWIW, I opted to go with the SteamOS version:

Package: libdrm-intel1
Version: 2.4.62-1+bsos1

The optirun %command% still fails on some games, though and I'm not clear why. Back to They Bleed Pixels. If I run it from the command line:

~ optirun -b virtualgl /home/joe/.steam/steam/SteamApps/common/they\ bleed\ pixels/TheyBleedPixels

It starts up fine, but the same command line in Set Launch Options:

optirun -b virtualgl %COMMAND%

Shows They Bleed Pixels go from grey to green and '- Running' in the UI right back to grey and not running. The reason why I say the results are more satisfactory, though, is if I take the suggestion to switch from virtualgl to primus as the bridge, TBP will successfully start up.

I'm willing to call this issue closed now, if this is just a fundamental issue with the Steam UI and VirtualGL, but something still seems very odd here since I can launch the game from the command line with a command that doesn't work in the Steam UI.

[kisak-valve]

Closing per the last comment.