[BUG] In VTOL VR, Index controllers unresponsive, stuck in Custom bindings and "loading current binding..."

[MaxBrains]

Describe the bug
When VTOL VR launches while using an Index headset and controllers, none of the interactive buttons in the start menu work. The controllers/hands track correctly in space, but using the trigger to activate them has no effect and it's impossible to start the game. Furthermore, controller bindings are initially stuck on Custom and trying to set them to Default doesn't work, though this seems to temporarily resolve after some time without making the controllers responsive again.

To Reproduce
Steps to reproduce the behavior:

1. Power on Index headset, controllers, and lighthouses
2. Launch SteamVR, open Settings, Controllers tab
3. Click Manage Controller Bindings
4. In the drop-down selector, select VTOL VR. Verify that Active Controller Binding is set to Default.
5. Launch VTOL VR.
6. Attempt to interact with any of the buttons—observe that this doesn't work
7. Enter dashboard, open VR Settings, Controllers tab
8. Click Manage Controller Bindings
9. Observe, at this point the Active Controller Binding is set to Custom, and the text below is "loading current binding...", even though Default was initially set in settings.
10. Try to set Active Controller Binding again to default—observe that this doesn't work

Expected behavior
Pressing any button in-game with the trigger should activate the button. If the control bindings are not correct, changing them back to Default should get them working again in the default state.

System Information (please complete the following information):

• Distribution: Manjaro (Linux 6.6.8)
• SteamVR version: 2.2.4 Beta
• Steam client version: 1703100617, Wed, Dec 20 12:06 PM UTC -07:00
• Opted into Steam client beta?: Yes
• Graphics driver version: Mesa 23.1.9-manjaro1.1
• Gist for SteamVR System Information: https://gist.github.com/MaxBrains/df02ef711fd508ea3c157bc666ac36a5

Screenshots

Additional context
I initially attempted the fix described at: https://steamcommunity.com/app/250820/discussions/2/2950377478182625392/
However, none of the files described in this guide were present anywhere in .local/share/Steam, nor was there a section representing VTOL VR (App ID 667970) in steamvr.vrsettings.

Note: Commenters who are also experiencing this issue are encouraged to include the "System Information" section in their replies.

[mr2meowsYT]

im on vive arch linux wayland and i also have this problem and i dont think they're going to fix it because its the same bug as issue 329 and thats been open since 2020
https://gist.github.com/mr2meowsYT/20f34b105946bffec43bea9113de1d3b

[Patola]

Yeah, this bug disappears and reappears sporadically. Now I'm experiencing it with most games on SteamVR 2.5.5... I can't even play No Man's Sky VR in peace now that there's a new expedition, dang.

[Patola]

Great... Going back to 2.4.4 didn't fix the issue, going up to 2.6.2 didn't fix it either... So is the issue in other places? Tried Synth Riders, it works, it can find a default binding for the Valve Index. Tried No Man's Sky and it doesn't find a default binding for the Valve Index. WHAT'S GOING ON?

[Patola]

Ok, for No Man's Sky I even booted in my windows partition, started no man's sky, created a new binding that's exactly the default binding and copied it to the cloud, then booted into Linux and copied that section from the windows steamvr.vrsettings for the game:

   "steam.app.275850" : {
      "knuckles_250820_CurrentURL_steamvrinput" : "vr-input-workshop://3257568351",
      "knuckles_250820_NeedToUpdateAutosave_steamvrinput" : false,
      "knuckles_250820_PreviousURL_steamvrinput" : "vr-input-workshop://3257567835"
   },

into my Linux steamvr.vrsettings, then I started SteamVR and tried No Man's Sky.
SAME THING HAPPENED. It can't load the bindings for No Man's Sky, it doesn't allow me to select "default" instead of custom, when I try to "choose other" it says there are none, and when I try to create my own it just presents an empty screen with no controls.

I also tried:

• disabling SteamVR gamepad support;
• disabling OVR Advanced VR settings;
• comparing the directories No Man's Sky/GAMEDATA/INPUT between Linux and Windows, and the 16 files there are exactly the same;

[Patola]

Linux's logs/vrwebhelper_controllerbinding.txt does not have any error message that's different from Windows' (e.g. CEF Local Resource Load Error: http://127.0.0.1:27062/dashboard/css%5Cvrwebui_shared.css -> 404 (Not Found)).

Yes, I know that I have been experimenting with No Man's Sky mostly, but I just tried that with VTOL VR and... the same thing happened. I can't select default controls, I can't choose other controls and I can't create my own. No error messages for VTOL VR control loading either. Take note that I just recently completely removed OVRAS and SteamVR and removed the remanining of their directories to get as pristine a SteamVR installation as I could, so it's not cruft from old installations that's there.

Please @kisak-valve get someone to look at this. Not being able to play VR games just because of control bindings not loaded is ridiculous: being so close, but unable to bridge this small gap. Why aren't the proper SteamVR input dialogues working?

[Patola]

Now tried removing ~/.local/share/Steam/userdata/MY_STEAM_ID/275850 (for No Man's Sky) and ~/.local/share/Steam/userdata/MY_STEAM_ID/250820 (for SteamVR) and then starting SteamVR to get them recreated. They were recreated but the issue remains. Not sure where else to look to fix this issue.

I've also read a lot of the documentation of SteamVR and specifically steamvr input to try and understand what might be going wrong, to no avail. Please help! I just want to keep playing games that I've already played for hundreds of hours on Linux VR, that isn't much to ask.

[tingvarsson]

Ive had similar issues on 2.5 and 2.6, while it worked when using previous (2.4), and only today managed to make it work again. For me I got the same behavior but for Zero Caliber.
Issue is that I managed to do two changes before it not working and it working again.
I suspected it had something to do with the game and Steam/SteamVR being on different disks and possible issues mounting the game specific VR bindings (dont have the old logs anymore either but saw some error on loading the bindings from the game even though it was there).

So I:

1. moved the game to the same disk as steam/steamvr
2. it first didnt want to start due to some proton migration failing so I just nuked the proton/wine prefix under compatdata.

After that it works for me again.

So would be interesting if you have something similar @Patola.

Guessing... if it is 1. it points towards some mount issue with pressure-vessel? and if it is 2. I guess it something old and stale in the prefix ands not compatible with newer steamvr...

[Patola]

@tingvarsson thanks for the tip, you cracked it! I had to go through a lot of hoops, though...

I use LVM and No Man's Sky was installed on /jogos2 which is an SSD.
My /home is on HDD, and that's why I was avoiding putting it there. Anyway, I extended the logical volume of /home and through Steam, moved No Man's Sky there.

However then No Man's Sky would not start -- even in pancake mode.

I completely uninstalled it, but it left some remainders in the No Man's Sky directory there, which I removed (actually, I backed up to another logical volume -- it was BINARIES/Settings/*.MXML and GAMEDATA/* -- and then reinstalled it directly on /home. Unfortunately I was in a hurry to make No Man's Sky work, so I forgot to test with PROTON_LOG=1 %command% to understand what was causing the game to not run.

After that I started the game once in pancake mode to configure it, then left.
Started SteamVR, then started the game.

AND NOW IT ONLY STARTED IN THE LEFT EYE!!!!! The controllers were working, though!!
So that it really seems a problem in the pressure-vessel. I subscribe to the list, maybe @smcv can enlighten us on this one?

Adding the parameters AMD_VULKAN_ICD=RADV RADV_PERFTEST=emulate_rt,rt,nv_ms,sam VKD3D_CONFIG=dxr11 VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/amd_pro_icd32.json:/usr/share/vulkan/icd.d/amd_pro_icd64.json fixed the one-eye image for some reason. I'll look into it later, now I will play some well deserved VR game.

[Patola]

Sorry, @tingvarsson -- forgot to say that I had first ruled out (2) with both No Man's Sky and VTOL VR (removed the proton prefix for both games, didn't change anything). This is a routine operation for me, so much that I made a script that finds out which of my (many) volumes is being used and removes the compatdata/appid and shadercache/appid directories.

As I didn't move VTOL VR to the same prefix as SteamVR, it still shows the same issue.

I also opened a ticket in the steam runtime bugtracker, https://gitlab.steamos.cloud/steamrt/steamrt/-/issues/30 -- just in case.

[smcv]

If you suspect a problem with Steam Linux Runtime (SteamLinuxRuntime_sniper, pressure-vessel) then please report it in https://github.com/ValveSoftware/steam-runtime/issues with a detailed log (there is an issue template which will send you in the right directions to collect this information). A log with STEAM_LINUX_RUNTIME_VERBOSE=1 in the environment is often helpful.

The Steam Runtime developers do not have VR hardware or access to your computer, so please assume that things that are obvious to you are not necessarily obvious to us! We will need to know the steps to reproduce a problem, the result that you expected, and the result that you actually got.

If you can set up two similar test scenarios where one of them works the way you expected and the other does not, then that's often helpful, especially if you collect logs from both test scenarios and make it clear which is which. For instance, if something works the way you expect with the previous_release beta branch of SteamLinuxRuntime_sniper but does not work in the default branch, then that's extremely useful information.

The container runtime framework, Proton and SteamVR are all complicated, so the result of combining them can be very complex. If you can construct a test scenario that is as simple as possible, it is more likely that we will be able to solve it: for example using SteamVR defaults in preference to third-party drivers or addons, using Valve's official builds of SteamLinuxRuntime_sniper and Proton in preference to unofficial community versions, using native Linux executables in SteamLinuxRuntime_sniper in preference to Windows executables via Proton, and trying to minimize the number of things that are strange/different/reconfigured.

Please report issues to the steam-runtime issue tracker in preference to @'ing me personally: there is only one of me, and sometimes I am busy with something else (but I am part of a team, and perhaps someone else in the team can help you).

I use LVM and No Man's Sky was installed on /jogos2

This sounds like: https://github.com/ValveSoftware/steam-runtime/blob/master/doc/steamlinuxruntime-known-issues.md#sharing-directories-with-the-container

If you can clarify what directories were involved (in a separate issue report, please) it might be possible to have the container runtime framework pick up from Steam which other directories need to be used for this particular game, or teach Steam to give us that information.

VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/amd_pro_icd32.json:/usr/share/vulkan/icd.d/amd_pro_icd64.json

If this is AMDVLK (open source but not part of Mesa) or AMDGPU Pro (proprietary), we have found that those drivers are often problematic, because of the way they try to force Vulkan games to prefer them. For AMD GPUs, if possible I would recommend using the open source amdgpu driver, also known as RADV, which is part of upstream Mesa (that's the same driver that's used on the Steam Deck for example). I would recommend only installing AMDVLK or AMDGPU Pro if you know that you need them.

Combining VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/amd_pro_icd32.json:/usr/share/vulkan/icd.d/amd_pro_icd64.json with AMD_VULKAN_ICD=RADV seems like there might be some confusion - you seem to be trying to force use of RADV but also trying to force use of AMDGPU Pro, and you can't have both.

If you think the Steam Linux Runtime / pressure-vessel is doing the wrong thing in this scenario, then we will definitely need to see an issue report with steps to reproduce the situation, what you expected the result to be, what the actual result was, and a log with STEAM_LINUX_RUNTIME_VERBOSE=1 in the environment.

[Patola]

If you suspect a problem with Steam Linux Runtime (SteamLinuxRuntime_sniper, pressure-vessel) then please report it in https://github.com/ValveSoftware/steam-runtime/issues with a detailed log (there is an issue template which will send you in the right directions to collect this information). A log with STEAM_LINUX_RUNTIME_VERBOSE=1 in the environment is often helpful.

Thanks. It was a rough week, so I disappeared for a while. Now that it's the weekend I took the time and created the ticket: ValveSoftware/steam-runtime#675

The Steam Runtime developers do not have VR hardware or access to your computer, so please assume that things that are obvious to you are not necessarily obvious to us! We will need to know the steps to reproduce a problem, the result that you expected, and the result that you actually got.

Sure, I will try to inform and describe everything that's in my reach, I am even adding two more logs now:

• Proton log for VTOL VR when it's on filesystem /jogos2 (thus with steamvr input not working)
  steam-667970-on-jogos2.log

• Proton log for VTOL VR when it's on filesystem /home (moved from within Steam "move install folder"), and this time working
  steam-667970-on-home.log

If you can set up two similar test scenarios where one of them works the way you expected and the other does not, then that's often helpful, especially if you collect logs from both test scenarios and make it clear which is which. For instance, if something works the way you expect with the previous_release beta branch of SteamLinuxRuntime_sniper but does not work in the default branch, then that's extremely useful information.

I tried some variations, like changing to the beta branch or using Proton 8.0-6 instead of 9.0-1 and it didn't change anything.

The container runtime framework, Proton and SteamVR are all complicated, so the result of combining them can be very complex. If you can construct a test scenario that is as simple as possible, it is more likely that we will be able to solve it: for example using SteamVR defaults in preference to third-party drivers or addons, using Valve's official builds of SteamLinuxRuntime_sniper and Proton in preference to unofficial community versions, using native Linux executables in SteamLinuxRuntime_sniper in preference to Windows executables via Proton, and trying to minimize the number of things that are strange/different/reconfigured.

I will try and get such cases. If I can rule out the steam runtime it would be useful indeed. I think I have only 2 or 3 native VR games, I have to remember which ones...

Please report issues to the steam-runtime issue tracker in preference to @'ing me personally: there is only one of me, and sometimes I am busy with something else (but I am part of a team, and perhaps someone else in the team can help you).

I use LVM and No Man's Sky was installed on /jogos2

This sounds like: https://github.com/ValveSoftware/steam-runtime/blob/master/doc/steamlinuxruntime-known-issues.md#sharing-directories-with-the-container

It might be, but I tried to fiddle with that PRESSURE_VESSEL_FILESYSTEMS_RW variable (e.g. /home:/jogos2) and it didn't work.

If you can clarify what directories were involved (in a separate issue report, please) it might be possible to have the container runtime framework pick up from Steam which other directories need to be used for this particular game, or teach Steam to give us that information.

For No Man's Sky and VTOL VR: they were in /jogos2, which is a logical volume /dev/ryzenvg/jogos2lv. /home is separate from root and in a different volume group, /dev/mijovg/homelv.

VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/amd_pro_icd32.json:/usr/share/vulkan/icd.d/amd_pro_icd64.json
^^^^^ this is amdgpu-pro, not amdvlk (which is not installed in my system)

If this is AMDVLK (open source but not part of Mesa) or AMDGPU Pro (proprietary), we have found that those drivers are often problematic, because of the way they try to force Vulkan games to prefer them. For AMD GPUs, if possible I would recommend using the open source amdgpu driver, also known as RADV, which is part of upstream Mesa (that's the same driver that's used on the Steam Deck for example). I would recommend only installing AMDVLK or AMDGPU Pro if you know that you need them.

Yeah, I recall you raising your concerns about amgpu-pro on the Demonicus bug report (you stopped responding there but the bug disappeared anyway), but I need it. In the case of No Man's Sky, if I run it in VR with RADV, for some reason the right eye doesn't work. For some other games, there are various reasons, from performance to being more resilient to crashes. But the default is RADV, I added this to /etc/environment: VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.i686.json:/usr/share/vulkan/icd.d/radeon_icd.x86_64.json

Combining VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/amd_pro_icd32.json:/usr/share/vulkan/icd.d/amd_pro_icd64.json with AMD_VULKAN_ICD=RADV seems like there might be some confusion - you seem to be trying to force use of RADV but also trying to force use of AMDGPU Pro, and you can't have both.

Yeah, this AMD_VULKAN_ICD=RADV was a leftover from something very old, I don't even recall what it was. Removed it, and everything was the same. As I say I need to run No Man's Sky in VR via amdgpu-pro.

If you think the Steam Linux Runtime / pressure-vessel is doing the wrong thing in this scenario, then we will definitely need to see an issue report with steps to reproduce the situation, what you expected the result to be, what the actual result was, and a log with STEAM_LINUX_RUNTIME_VERBOSE=1 in the environment.

I used the regular STEAM_LINUX_RUNTIME_LOG=1 first and the log went to 100 MB, I had to compress it with gzip (it's on the steam runtime bug report). If you really want me to grow it even more with verbose 1, please let me know, I'll redo the tests.

[Patola]

Ok... Just tried with two Linux native VR games:

• VR Driver School (appid 2759810, vrlinux beta branch): didn't have the controller issue
• Groove Gunner (appid 976930): the issue triggered! So it might not be the pressure vessel at all? To ensure I wasn't using the steam runtime, I after the first attempt tried Steam-Play-None https://github.com/Scrumplex/Steam-Play-None as compatibility tool for Groove Gunner and the game started with the VR input issue again. So can this rule out the steam runtime?

[smcv]

Groove Gunner (appid 976930): the issue triggered! So it might not be the pressure vessel at all? To ensure I wasn't using the steam runtime, I after the first attempt tried Steam-Play-None https://github.com/Scrumplex/Steam-Play-None as compatibility tool for Groove Gunner and the game started with the VR input issue again. So can this rule out the steam runtime?

Steam-Play-None is not a Valve-supported product, but I believe its purpose is to run native Linux games under the legacy LD_LIBRARY_PATH runtime (default for most native Linux games on desktop, but not the default on Steam Deck).

If that is correct, then yes, it rules out the SteamLinuxRuntime container runtimes and pressure-vessel being the cause for the issue you are seeing.

There are some ways to tell that a game is running in SteamLinuxRuntime_* (pressure-vessel), by using ssh remote access or Alt+Tab to a terminal:

• If you look at /proc/$pid/maps, where $pid is a game process, you will probably see some libraries mapped from /run/host/... paths.
• If you look at /proc/$pid/root, you will see that /proc/$pid/root/run/pressure-vessel exists.
• If you look at pstree, then you will see a srt-bwrap or bwrap process "above" the actual game.
• If you look at pstree, you will also see a pressure-vessel-adverb process that is a parent of the actual game. (We might rename this to something like pv-adverb in a future release, but either of those names indicates pressure-vessel.)

If you don't see those signs, then the game is running in the legacy LD_LIBRARY_PATH runtime or in no runtime at all.

If you look at /proc/$pid/maps and you see libraries mapped from locations like .../ubuntu12_32/steam-runtime/usr/lib/..., then that's evidence of the legacy LD_LIBRARY_PATH runtime being used.

[smcv]

If that is correct, then yes, it rules out the SteamLinuxRuntime container runtimes and pressure-vessel being the cause for the issue you are seeing.

... or, on second thoughts, maybe that doesn't rule it out. When you run that game, the game is not in a container, but SteamVR is still in a container.

I tried to fiddle with that PRESSURE_VESSEL_FILESYSTEMS_RW variable (e.g. /home:/jogos2) and it didn't work

Where, exactly, did you set this environment variable?

There are at least three places where it could be set with different effects:

• in the Launch Options of SteamVR: PRESSURE_VESSEL_FILESYSTEMS_RW=/jogos2 %command%
• or in the Launch Options of the game (e.g. Groove Gunner): PRESSURE_VESSEL_FILESYSTEMS_RW=/jogos2 %command%
• or for all of Steam and all of its subprocesses: PRESSURE_VESSEL_FILESYSTEMS_RW=/jogos2 steam

[smcv]

Questions for SteamVR developers, or maybe for knowledgeable SteamVR users:

Suppose I have:

• Steam installed in ~/.local/share/Steam as usual
• additional Steam libraries /a, /b, /c, /d, etc.
• SteamVR installed in /a/steamapps/common/SteamVR
• a game installed in /b/steamapps/common/Groove Gunner
• any other relevant components (Proton, OVR_AdvancedSettings, any other interesting component) installed in /c, /d, etc.

What would the directory and filename be for any files that are used to store custom bindings for Groove Gunner?

And which processes need access to those files? the Steam client? SteamVR? The game itself? Anything else?

[farmboy0]

@smcv AFAIK all custom bindings are written to ~/steamvr or something similar, at least its what I have but it might be just my SteamVR config. Let me check later when i'm home.
For the record I have a layout such as what you describe:
a = ~/.local/share/Steam/steamapps/common/SteamVR
b = /mnt/games/SteamLibrary
c = /mnt/work/SteamLibrary for Proton and steam runtime and OVR

[farmboy0]

As I have VTOL VR in my library I tested it and I cannot reproduce this, although I use a vive pro with knuckles not the index as it is currently not working.
What I can say is that it uses an action manifest which explains why without the game running at least once you will see the index legacy default config in the binding window but that changes once the game runs to VTOL's default knuckles bindings. The action manifest and all referenced binding files are in the game directory.