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

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%).

@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).

@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?

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

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

@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?

@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.

@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?

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.

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.