[BUG] SteamVR does not launch at all (Arch/Hyprland)

[OwlCacone]

Describe the bug
After a fresh installation of SteamVR, it asks for sudo privileges to change a variable for a file. The app then "launches", nothing gets displayed on screen, then it crashes. I would provide terminal logs, but I don't know how to.

To Reproduce
Steps to reproduce the behavior:

Install SteamVR
Launch SteamVR
Enter password when asked for super user privileges to change variable in a file
Nothing...

Expected behavior
SteamVR launches properly

System Information

Distribution: Arch
SteamVR version: Any
Steam client version: 1751405894
Opted into Steam client beta?: No
Graphics driver version: mesa - 25.1.5-1
Gist for SteamVR System Information: SteamVR does not start

Screenshots
n/a

Additional context
For my desktop environment/ window manager, I use Hyprland, which runs on Wayland.
My initial setup for arch was as minimal as possible with the HyDE project installed afterward.

As for if my Steam client is the flatpak version. I don't know. I used the AUR to install the latest stable release.

Browsing through the bug reports, a solution I came across was to start SteamVR with this launch option: steam-runtime-launch-options -- %command%.
The problem I ran into with that was that no matter what options I changed, it would still not launch and the options would not save.

[CarbonNotes]

Many terminal apps allow piping a command through. Previously, when trying to capture console logs, I've used Konsole for it. Set the following as the launch args for SteamVR in Steam after installing Konsole:

konsole --hold -e %command%

Putting that in your launch options should wrap the SteamVR launch command inside a Konsole instance, and allow you to see output (at least from the main executable.) --hold makes sure Konsole stays open after the process inside shuts down, so that may help show some useful log output.

[OwlCacone]

Putting that in your launch options should wrap the SteamVR launch command inside a Konsole instance, and allow you to see output (at least from the main executable.) --hold makes sure Konsole stays open after the process inside shuts down, so that may help show some useful log output.

Yeah, so that didn't work unfortunately. It crashes basically as soon as it launches, so it doesn't have enough time to even open a konsole instance

[u9djfgoj]

same problem