[BUG] Issue Title

[eli803m]

Describe the bug
SteamVR's UI process (vrwebhelper) repeatedly segfaults in libcef.so under real gameplay load
(not menus), which then crashes vrcompositor.real. This happens specifically once a game moves
from light rendering (menus, SteamVR Home) into full 3D rendering — reproduced in Automobilista 2
and RaceRoom. Euro Truck Simulator 2 did launch in flatscreen mode even when vr version was selected and was very stuttery the whole time even when I lowered settings. The games themself either freezes without any message or freezes shortly after or right when the "ALVR isn't responding" dialog appears where then I am forced to shut down the game and or steam depending on what is happening.
Encoder/network/decoder statistics remain clean throughout (0% packet loss, ~40ms total latency,
sub-5ms per-stage timing), ruling out a streaming/bitrate cause.

To Reproduce

1. Launch SteamVR (Hyprland/wlroots Wayland compositor, ALVR driver, Quest 2 wired via Link cable)
2. Launch SteamVR Home — works fine
3. Launch Automobilista 2 or Raceroom(via Proton) — main menu loads and is fully interactive- it would also be worth a shot to test other games because in general i couldn't get anything to 3d render
4. Start a Test Drive / enter actual 3D gameplay rendering
5. vrwebhelper segfaults in libcef.so (repeats), vrcompositor.real then segfaults, game freezes
   or SteamVR shows "not responding"

Expected behavior
Game should transition from menu to gameplay rendering without SteamVR's UI process or compositor
crashing.

System Information:

• Steam client version: [fill in from Steam > Help > About]
• SteamVR version: 2.12
• Distribution: Arch Linux, Hyprland (wlroots/Wayland)
• GPU/driver: Nvidia RTX 4060, driver 610.43.03 (New Feature Branch), CUDA 13.3
• Headset: Meta Quest 2, wired (Link cable, USB-C, via VIA Labs USB3 hub)
• ALVR version: v20.14.1
• Steam runtime diagnostics: [Help -> Steam Runtime Diagnostics]
• Steam and SteamVR logs: tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs
• Minidumps: tar -zcvf ~/Desktop/steam-minidumps.tar.gz /tmp/dumps

Additional context

• dmesg shows repeated pattern at crash time:
  vrwebhelper[PID]: segfault ... in libcef.so
  vrcompositor.re[PID]: segfault ... in vrcompositor.real
  NVRM: Xid (PCI:0000:01:00): 69/32/31/13, pid=PID, name=AMS2AVX.exe, Class Error / MMU Fault
• The known bindings-spam patch (patch_bindings_spam.sh from
  alvr-org/ALVR-Distrobox-Linux-Guide) does not apply — it's hardcoded to SteamVR 2.3.5 file
  contents and aborts with "Couldn't find required file for patch" on 2.12.
• Tried: Proton (default), Proton-GE 9-27, Proton Experimental — Experimental and GE 9-27 get
  further into gameplay before the same crash signature recurs.
• Not caused by encoder/network overload (Statistics tab confirmed clean).
• Also observed intermittent unrelated USB disconnects (usb 4-2.1) on the same hub, mitigated
  separately via udev autosuspend rule, not the primary cause of this crash.
• No problems with bitrate, res, etc. Even at a low bitrate like 50Mbps and the fastest settings and lowest resolution I would still get this issue.
• I also entered the necessary launch commands for SteamVR on Hyprland and used all 3 current versions of SteamVR with 2.12 being the only one that would work and or launch consistently with the other 2 bringing a picture but being almost unusable and in an odd warped vr monitor state where the whole display would jutter to wherever you moved your head.
• I have tried to fixed this and troubleshooted for about 8 days and have deleted SteamVR numberous times, validated files, reinstalled ALVR on both the headset and PC making sure that every single file was wiped before re installation witch did seem to help a bit as I was able to consistantly use steam VR but at this moment I am restricted to SteamVR Home or the Void because like I said the games that i want to play do not work when it comes time to accually play them and the 3d rendering fails and that is where everything gets hung and freezes. I am interested to see if this can be recreated on X11 so I will test VR on Linux Mint and see if using X11 will work compared to Wayland.

[michauMiau]

Just a heads up, you forgot to include the logs

[Packetdancer]

...also a title.

That said, you're using ALVR and you mention vrcompositor.real -- ALVR does not work like a normal SteamVR driver. Normal drivers use the API that SteamVR exposes, which remains consistent from version to version. ALVR instead relies on rummaging around in the innards of SteamVR, and does so by moving vrcompositor out of the way (renaming it to the aforementioned vrcompositor.real) and sticking its own pretend vrcompositor in place which tries to proxy everything and pass it on to the real vrcompositor.

However, this only works when absolutely nothing inside of SteamVR changes (or at least, nothing ALVR cares about). So any time SteamVR updates, there's a strong chance that ALVR also needs an update. The problem is that ALVR on Linux has been largely abandoned in terms of development for some time now, which turned it into a ticking time bomb.

That bomb has now exploded.

Anyway... is there a specific reason you felt you needed to use ALVR versus Steam Link? Steam Link, I can reasonably support, but the only way ALVR will work is if you stay on an old SteamVR and do not update.