[BUG] SteamVR failed to initialize

[Sersys]

Describe the bug
SteamVR failed to initialize for unknown reasons. (Error: Not Initialized (109)(109))
SteamVR launches, Valve Index LEDs are stuck in blue, eye pieces are grey and sometimes I get flickers of the vr home randomly for a frame or two, USB is sometimes recognized as a 3d camera and sometimes as unknown but the hub tree of devices shows.

To Reproduce
Steps to reproduce the behavior:

1. Connect Valve Index (power, display port, usb port)
2. Launch SteamVR
3. See error on steam window

Expected behavior
-Valve Index recognized as steam device
-stable vr home screen

System Information:
-arch linux kernel version 6.3.7-arch1-1 (64bit)
-AMD Ryzen 9 7900x
-AMD Radeon RX 7900 XT.
-64GB DDR5

Additional context
-fresh installation of Arch linux,
-all hardware components are new (less than 2 month)
-all hardware components are tested and functional (except valve index)
-updated HMD firmware when prompted on first use.
-Valve Index starts up as a monitor by default even after pressing enable Direct Display. The app restarts but it's still in monitor mode
-in developer settings the button "remove all steamvr usb devices" is not working. Error message: "The helper application to remove the USB devices was not able to start. Make sure that you can run this application as admin".

Methods tried so far to fix
-ran steamvr in various compatibility modes (ge-proton8-4, proton experimental, proton8.0-2)
-ran command set LB_LIBRARY_PATH="~/.local/share/Steam/steamapps/common/SteamVR/bin" && sudo ./vrstartup.sh & disown in /home/USER/.local/share/Steam/steamapps/common/SteamVR/
-installed and replaced package steam-devices from AUR.

Screenshots

[Danielduel]

Hello, could you provide more info?

(From bug template:)
System Information (please complete the following information):

• Distribution: [Arch/Manjaro/Ubuntu/etc.]
• SteamVR version: [E.g. 1.7.2]
• Steam client version: [build number or date]
• Opted into Steam client beta?: [Yes/No]
• Graphics driver version: [run nvidia-settings or vulkaninfo | grep driverInfo:
• Gist for SteamVR System Information: [See instructions]

Thank you

[Sersys]

Thank you for replying

-arch linux kernel version 6.3.7-arch1-1 (64bit)
-steamvr 1.25.8

-Steam Version:  1687386907
-Steam Client Build Date:  Wed, Jun 21 2:18 PM UTC -08:00
-Steam Web Build Date:  Wed, Jun 21 3:26 PM UTC -08:00
-Steam API Version:  SteamClient020

-did not opt into beta
vulkaninfo | grep driverInfo:

driverInfo      = Mesa 23.1.2
        driverInfo                                           = Mesa 23.1.2
        driverInfo      = Mesa 23.1.2
        driverInfo                                           = Mesa 23.1.2

SteamVR-2023-06-28-AM_12_28_43.txt

I appreciate your interest in helping me.

[Danielduel]

X11 or Wayland?

[Sersys]

X11 or Wayland?

x11

[Sersys]

Update:

I've installed Arch on another disposable hard drive to test steamvr to avoid risking mis-configuring my main system. I have Gnome as my desktop environment instead of the KDE, I have on my main system, and interestingly I get different error messages:

-Steamvr prompts me to allow it super user access to finish installing and configuring
-no password prompt window appears after pressing "yes"
-a window warns me that some of the features will not be available
-the app starts anyway
-it asks for the HMD to be connected even though it is connected
-the HMD remains in standby mode and does not display anything
-switching display port while steam is running crashes either Gnome or X because my monitor went blank white but the mouse was still moving but all keyboard commands were unresponsive.

Conclusion:
I have a reason to believe that steamvr does not have the required privilege to properly conclude installation that's why it fails to initialize on KDE and ask for elevated access in Gnome.

Notice:
According to forums and blogs when Steam is open and the HMD is connected it should pop up a window asking to install Seamvr. When I connect the HMD it doesn't even trigger the new device connected message and Steam won't react to it either.

Is there a way to force steamvr to run as if it was "run as administrator" in Arch?

[Sersys]

Update:

I've installed Debian on yet another disposable hard drive to test steamvr under a different distro to see what it does:

-Steamvr prompts me to allow it super user access to finish installing and configuring
-no password prompt window appears after pressing "yes"
-I get the error message: SteamVR setup is incomplete, some features might be missing. See /tmp/SteamVRLauncherSetup.log for details.
- /tmp/SteamVRLauncherSetup.log is actually created, unlike in arch where nor the file neither the directory exists.
-according to the log steamvr can't find setcap and getcap
-in Debian this can be bypassed by creating a link from /usr/sbin/setcap to /usr/bin/ and equally /usr/sbin/getcap to /usr/bin/
-after this a cap has to be set on the vrcompositor binary (Debian)setcap CAP_SYS_NICE+ep ~/home/USER/.steam/steam/steamapps/common/SteamVR/bin/linux64/vrcompositor-launcher
-there are no more error messages but the HMD is still displaying a grey background with occasional flickers of the home screen
-plugging in the HMD still won't trigger steamvr to launch;

Conclusion:
-The initialization failure could be caused on Arch by steamvr not being able to find what ever is Debians's getcap/setcap equivalent in Arch.
-The initialization failure may not be connected to the grey HMD screen and the flicker
-my suspicion of probable causes:
a) HMD is faulty
b) "cap" for the vrcompositor is not set properly
c) other video or usb driver related issues

Notice:
I'm going to install windows on a spare hard drive to see if it is indeed faulty, but it will take some time.

[ZarathustraDK]

@Sersys This might sound incredibly dumb, but have you tried moving the windows away once the password-prompt for admin-privileges is supposed to appear? In my experience that particular window has a nasty habit of being pushed to the back and hiding behind other windows (usually Steam and the SteamVR installation window) for some reason. It doesn't even generate a new tab on the taskbar, giving off the impression that nothing is there.

[Sersys]

@ZarathustraDK Thank you for trying to help me. To recap:

-the issue of steamvr prompting me to allow it super user access to finish installing and configuring only persists in Arch under Gnome environment.
-in Arch and KDE environment it has a "failed to initialize" error message without any prompt to allow it super user access.
-in Debian there is a work around to give it access to the files steamvr needs by creating links to the files (getcap and setcap) from protected directories to the home directory.

With that being said I've launched the hard disk with the Arch+Gnome installation and there were no other windows present before or after pressing ok.

Thank you for your suggestion.

[Sersys]

Update

I've found out that setcap and getcap already exists in /usr/bin in Arch and the command setcap CAP_SYS_NICE+ep is also distro independent. On my Arch+KDE I used setcap CAP_SYS_NICE+ep ~/.steam/steam/steamapps/common/SteamVR/bin/linux64/vrcompositor-launcher and now it looks like this:

-I no longer get any initialization errors
-HMD LEDs turn green when HMD is active
-the HMD is still displaying a grey background with occasional flickers of the home screen
-changing the refresh rate will make the home screen flicker more frequently
-plugging in the HMD still won't trigger steamvr to launch;

Conclusion:
It is obvious that the initialization error was not connected to the flickering home screen and it has to do something with drivers, video card settings, and vrcompositor settings.

[Danielduel]

After recent updates (# pacman -Syyuu) I get weird behavior - after starting steamvr the system freezes for few seconds, flickers white and "steamvr dashboard gray" on the nonvr display (I haven't checked if it displayed anything in hmd)

This issue seems to be very different to yours, but maybe you can make some progress by downgrading your packages to a date that works for me.

Basing on: https://wiki.archlinux.org/title/downgrading_packages

Backup your /etc/pacman.d/mirrorlist, delete original mirrorlist, create a new mirrorlist with content of Server=https://archive.archlinux.org/repos/2023/07/02/$repo/os/$arch, then # pacman -Syyuu.
Keep in mind that if you use firefox - your profile will be unusable after downgrading and I don't have info if this rollback is safe from security point of view (for me it fixes my problem that I've described before).
After this I had to reboot the system.

[Sersys]

@Danielduel Thank you for the suggestion. Unfortunately I wont have time to try it out the next few days. I'll get back to you once I've tried it.

[Sersys]

@Danielduel I've tried your suggestion. Nothing has changed after reboot.
During the downgrade there were some error messages regarding firmware. I'm not sure if it's relevant:

:: Running post-transaction hooks...
( 1/22) Creating system user accounts...
( 2/22) Registering binary formats...
( 3/22) Updating journal message catalog...
( 4/22) Reloading system manager configuration...
( 5/22) Updating udev hardware database...
( 6/22) Applying kernel sysctl settings...
( 7/22) Creating temporary files...
( 8/22) Reloading device manager configuration...
( 9/22) Arming ConditionNeedsUpdate...
(10/22) Updating the MIME type database...
(11/22) Updating module dependencies...
(12/22) Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
==> Using default configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-linux -g /boot/initramfs-linux.img --microcode /boot/amd-ucode.img
==> Starting build: '6.3.9-arch1-1'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
  -> Running build hook: [keyboard]
==> WARNING: Possibly missing firmware for module: 'xhci_pci'
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
==> WARNING: consolefont: no font found in configuration
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux.img'
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
==> Using default configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-linux -g /boot/initramfs-linux-fallback.img -S autodetect --microcode /boot/amd-ucode.img
==> Starting build: '6.3.9-arch1-1'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
==> WARNING: Possibly missing firmware for module: 'ast'
  -> Running build hook: [keyboard]
==> WARNING: Possibly missing firmware for module: 'xhci_pci'
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
==> WARNING: consolefont: no font found in configuration
  -> Running build hook: [block]
==> WARNING: Possibly missing firmware for module: 'aic94xx'
==> WARNING: Possibly missing firmware for module: 'qla2xxx'
==> WARNING: Possibly missing firmware for module: 'qla1280'
==> WARNING: Possibly missing firmware for module: 'qed'
==> WARNING: Possibly missing firmware for module: 'wd719x'
==> WARNING: Possibly missing firmware for module: 'bfa'
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux-fallback.img'
==> Image generation successful
(13/22) Refreshing PackageKit...
(14/22) Updating the appstream cache...
✔ Metadata cache was updated successfully.
(15/22) Reloading system bus configuration...
(16/22) Warn about old perl modules
(17/22) Updating fontconfig cache...
(18/22) Updating 32-bit fontconfig cache...
(19/22) Updating icon theme caches...
(20/22) Updating the info directory file...
(21/22) Updating the desktop file MIME type cache...
(22/22) Updating the vlc plugin cache...

[ZarathustraDK]

@Sersys The warnings are unrelated. They're just referring to some drivers that could be installed if your machine was configured as a server. You're not the first, I fell for this too in an unrelated bughunt. And yes, that's possibly one of the dumbest warnings you'll ever encounter, like a bus-driver blowing a ferry-horn next to you walking on the sidewalk and then going "You need a bus-ticket if you want to ride with me!", then speeding off.

[Sersys]

Update

I've tested the HMD under Windows and surely enough it works without any errors, so the HMD is not faulty.
I've noticed something strange in Arch when I resumed to it after my Windows session. Earlier:

-My XFX AMD Radeon RX 7900 XT has a usb c type video output that was not working, (I was using hdmi to hdmi mini and a power supply usb c for my portable monitor) -now it works
-I couldn't get the monitor to switch to a 144hz refresh rate only 100hz. -now it it runs on 144hz
EDIT: usb c port fails to power on after waking from sleep and after cold or warm reset. It resumes working after completely powering the machine down and starting it up again. It may have functioned this way before I used Windows 10 and I just dismissed it as not working. This is a reoccurring bug mostly prevalent in laptops running arch. No work around fixed this issue for me yet but it's unlikely to be related to the SteamVR issues.

-The message SteamVR failed to initialize for unknown reasons. (Error: Not Initialized (109)(109)) no longer pops up
-After reinstalling Arch, Steam and SteamVR, SteamVR now properly prompts me to allow it super user access to finish installing and configuring, a password window pops up and installation completes as intended.

I have a reason believe that:
-Radeon Software Adrenalin (Windows 10 gui control panel for amd based graphics) automatically applied a firmware update to the graphics card, or activated some functionalities in the graphics card's bios.
-Windows 10 automatically applied firmware update to the motherboard chipset (Asus PRIME B650M-A II-CSM Micro ATX AM5 Motherboard)

Unfortunately further issues arose. I'm constantly getting the following error message:
A key component of SteamVR isn't working properly. Please quit SteamVR, then visit Task Manager and End any remaining SteamVR tasks before restarting the app.(307)

I've haven't looked into any further. I will resume testing once I have the time again.

[Sersys]

Update:

I've installed Debian again to see if anything has changed after using Windows 10:

-after setting up the previously mentioned getcap and setcap links, SteamVR properly prompts me for the superuser password and installs as intended
-SteamVR launches and prompts room setup (this hasn't happened previously in any Arch or Debian OS installs, it would just show flickers of the home environment)
-HMD shows the pre room install environent but artifacts are flickering everywhere
-during room setup SteamVR crashes at random times

I'm going to experiment in Debian for a while. Looks more promising than Arch. I'll try to apply my findings to Arch if I can get it working in Debian.

[Sersys]

Update:

Under Debian I've managed to get SteamVR running with severe limitations:

-changing the refresh rates over 90hz irreversibly crashes SteamVR. The app crashes before you could change the refresh rate back. I couldn't find the config for the refresh rate setting so I instead reinstalled Steam and SteamVR
-using numpad during room setup crashes SteamVR. Regular numeric keys seems to work.
-transitions and blank environments have flickering artifacts but does not persist in apps or even in VR home.
-if the HDM looses sight of both lighthouses, the HMD crashes and remains in a perpetual stand-by mode (blue led) until SteamVR is restarted.
-if SteamVR is started and the HDM can't see any of the lighthouses during startup, it produces the gray screen and VR home flickers as it was in the initial issue and stays that way until SteamVR is restarted.
-changing display ports while the HDM is connected (regardless of SteamVR running or not) will crash Debian. Always disconnect the HMD cable's break away port before changing display ports.
-Valve index is picky about which display port I'm using. One works the other does not.
-No issues with tracking the HMD or the index controllers.
-no events triggered by plugging in the HMD. SteamVR won't prompt to start.
-no sound

With this info I'll see how far I can get in Arch.

[Sersys]

Update:

I'm still working in Debian. I've managed to come up with a few work-arounds:

-no sound
Audio output manually hast to be set to the right output each session from desktop. I.E: my default audio output is HDMI1/Display port1 and after SteamVR launches another port appears HDMI2/Displayport 2.

-changing above 90hz refresh rate crashes SteamVR
120 hz actually works. Must have skipped it during my initial test. 144hz still crashes SteamVR.

-HMD crashing if it looses track of the lighthouses,
-If SteamVR is started while the HMD can't see the lighthouses it will only display the grey screen
These issues are related to the usb-c video port not powering up properly after waking from sleep bug. If the pc is started with a working usb-c port then these issues are not present. It seems like the entire graphics card has a problem with properly recovering from sleep. Also it could be that there was no firmware update by Windows 10 as I previously suspected, and this was the problem all along. I just disabled sleep for now, need to wait if a driver update comes out for the XFX version of AMD Radeon RX 7900 XT cards.

I'm going to test this in Arch if I have a chance.

[kisak-valve]

-changing above 90hz refresh rate crashes SteamVR
120 hz actually works. Must have skipped it during my initial test. 144hz still crashes SteamVR.
[...]
Radeon RX 7900

Hello @Sersys, this is a kernel driver issue #552.