Based on these logs, ALVR is presenting itself as a physical display, but when vrcompositor attempts to find and lease the display, Wayland says that ALVR's display does not exist.

In the interests of narrowing this down to whether it's a SteamVR issue or an ALVR issue... if you take ALVR out of the equation -- basically try connecting with Steam Link -- do things work?

I have also that 303 problem. When lauching with Steam Link only I get to the main space but then can't open the menu by pressing the burger menu button despite the virtual one showing that it is pressed. And after quitting I find a -201 error.

If someone tells me how I can try to get the logs.

Steam Beta Branch: Stable Client
Steam Version: 1780352834
OS: Zorin OS 18 Core (based on Ubuntu 24.04 LTS)
Goggles: Meta Quest 3

Kornuptiko - Are you also using ALVR, like @RealSourceOfficial is?

Logs are in ~/.steam/steam/logs/ by default, and the ones I'm most interested in are vrserver.txt and vrcompositor.txt and (if using VRLink) driver_vrlink.txt.

If you are using ALVR, my above question stands -- if you remove ALVR from things and use Steam Link directly, does it work? (ALVR appears to always present as a connected HMD, so you'd need to actually entirely take it out of the setup.)

The above experience was after closing SteamVR and connecting via the Steam Link App on the Meta Quest 3. With "Take it out of the setup" do you mean completely uninstalling or does this suffice?
Here are the logs:

vrserver.txt

vrcompositor.txt

driver_vrlink.txt

Related issue ALVR/#3294
I'm not sure if Steam Link would work with my Meta Quest 1. It's an ancient piece of hardware and ALVR is barely supported on it as is. Furthermore I've always had issues with Steam Link (unrelated issues at that) with entirely blank screencasts. Probably an issue with Wayland (which I'd find funny, I've already had to go upstream once on this issue)

When I'm back at my machine I can test my setup again, and provide logs. For now I've fixed it by switching to the previous version available on Steam.

@Kornuptiko

The above experience was after closing SteamVR and connecting via the Steam Link App on the Meta Quest 3. With "Take it out of the setup" do you mean completely uninstalling or does this suffice?

Last time I checked, I think ALVR actually moved SteamVR's vrcompositor out of the way and tried to replace it with its own shim layer. So uninstalling would probably give the cleanest test result, admittedly. (Especially since a -201 error in vrmonitor suggests that vrmonitor couldn't find the vrcompositor it expected.)

FWIW, in your logs, I do not actually see the dashboard button toggle sent, but I do see an received EVTYPE_LDASH_PAUSE: Remote was paused meaning that the Meta-side dashboard was pulled up and the vrlink scene lost focus, and was thus paused as a result. I mention this only because this always trips me up when testing on Quest, but only the off-hand button pulls up the Steam dashboard while the main hand one will pull up the Meta dashboard on the headset. And this is particularly annoying given that Meta can now pull up just a small, not-necessarily-obvious transparent bar now in HorizonOS 2.3...

@RealSourceOfficial

I'm not sure if Steam Link would work with my Meta Quest 1. It's an ancient piece of hardware and ALVR is barely supported on it as is. Furthermore I've always had issues with Steam Link (unrelated issues at that) with entirely blank screencasts. Probably an issue with Wayland (which I'd find funny, I've already had to go upstream once on this issue)

Ah, the screencasts issue with Wayland, you may need to run Steam with -pipewire as a parameter, just FYI. Cleaning the desktop capture 'quirkiness' up is definitely an on-the-list thing, but there's higher priority stuff to tend to first.

You may be right about the Quest 1, I fear; I haven't actually looked at the specs on that in ages so I'm not 100% certain that the current VRLink app supports it. If the issue is with ALVR, though, there's only so much I can do to try to support it.

(Also FYI, I added an error codes reference to the github not too long ago, which may be useful in knowing what a given error code means beyond the short descriptions in the vrmonitor window. So -201 is listed there, while 303 -- being a positive number -- would be in the linked file of OpenVR errors.)

Ah, the screencasts issue with Wayland, you may need to run Steam with -pipewire as a parameter, just FYI. Cleaning the desktop capture 'quirkiness' up is definitely an on-the-list thing, but there's higher priority stuff to tend to first.\n\nYou may be right about the Quest 1, I fear; I haven't actually looked at the specs on that in ages so I'm not 100% certain that the current VRLink app supports it. If the issue is with ALVR, though, there's only so much I can do to try to support it.

-pipewire is one of the many things I've tried; ergo, I am not the one who should be trusted with testing this. Wish I could offer more help, but I got rid of my wired headset a while ago. Unless we can come up with an alternative test method I am but the owner to this issue.

I did mention the issue in the ALVR repo, hopefully someone who has better hardware there can come and help test this issue.

I was gonna write the below but then I wanted to give you clean logs so I did it again until before ALVR and now I get a 300 error immediately with starting and I cant connect. Also it asked me for the superuser pw after install which it didn't the first time around. here are the logs:

vrserver.txt

vrcompositor.txt

driver_vrlink.txt

After I purged ALVR from my system and reinstalled SteamVR it worked besides the reasons I used ALVR in the first place. Then I reinstalled ALVR and the errors are back.

EDIT: I've gone back to the previous branch of SteamVR and while the superuser Popup came back, I canceled that and started it via ALVR and everything seems to work

Also it asked me for the superuser pw after install which it didn't the first time around.

The superuser popup is because on many Linux systems, you cannot set up a high-priority GPU compute queue without CAP_SYS_NICE permissions, so vrsetup.sh will try to setcap CAP_SYS_NICE=eip on vrcompositor-launcher. That's needed for Vulkan async mode, but not if you're not using async. When you reinstall SteamVR, the capabilities bit gets cleared so it has to set it again, and doing the setcap there requires being superuser.

So, that's expected.

As for going back to the previous branch of SteamVR, 2.12 is ancient, just as warning.

i also have this issue, error 303 and sometimes -201, tried launching with the vrmonitor. i use ALVR streamer v20.14.1 it does render a stream to my quest, but its pretty bad, stuttering and bars on the screen. with steam link i managed to get it to work but the left stick is pressed down all the time. not able to use menus in vrchat, using the beta 2.17.1 and the stable branch. the last update i was using ran great no issues.

file:///tmp/Spectacle.gdLVTx/Screenshot_20260611_133440.png

I'm going to be honest, there's basically no way that SteamVR can work with the current build of ALVR. Instead of functioning like a normal HMD driver in SteamVR, ALVR tries to slice open chunks of SteamVR and rummage around in the insides.

To use an analogy here, let's say you have a game, and the game has support for user-created mods. But then you have a mod that, instead of using the modding API, decides to just move chunks of the game itself out of the way and replace it with its own bits that pretend to do the same things, but also do other things. So every time the game updates, it's a coin flip whether or not that particular mod will break, because it's relying on game internals.

That's what ALVR is doing, in effect. So any time things change in SteamVR, there's a really good chance it's going to break. And given how ALVR wants to replace chunks of SteamVR with its own versions, those breakages will usually take down the whole system because now the ALVR bits pretending to be SteamVR bits don't do what the rest of SteamVR expects.

The reason I keep asking "do you get this crash without ALVR involved" is that if you're seeing the same crashes with VRLink, that'll be entirely a SteamVR issue, and thus something I can actually potentially fix.

(And if VRLink doesn't work for you at all for some reason, putting in an issue for that will help improve things there.)

But there's really no fix I can make here that still involves ALVR in the mix and a current version of SteamVR, given the way ALVR tries to do things. ALVR would need to be updated... and unfortunately, from what I understand ALVR's Linux port has been abandoned.

This problem started this week after the steam update so don't think it's JUST a ALVR issue their saide has not changed since last year. So steam changed something but it's ALVR's problem seems kind of weak sauce.
Adding my report here for consistency but I can't overemphasis enough that ALVR has been working with steam VR for over year without issue, until now. I get a 102 error and 303, but neither tracks really. SO what was changed on SteamVR?
SteamVR version: 2.16.7, BuildID 23791826 (public branch)
OS: Bazzite (Fedora Atomic), kernel via rpm-ostree image 44.20260608
GPU: AMD RX 9070 XT, Mesa 26.1.0, amdgpu/RADV
Headset: Meta Quest 2 via ALVR v20.14.1 (unchanged install since Nov 2025)

Summary
SteamVR + ALVR worked reliably for months. It broke completely the moment a
server-side update landed on 2026-06-22, confirmed via Steam's own
content_log.txt:

2026-06-22 19:41 - AppID 250820 finished update, BuildID 23791826
2026-06-23 22:53 - AppID 250820 finished update, BuildID 22542555 (rollback)
2026-06-23 23:13 - AppID 250820 finished update, BuildID 23791826 (re-pushed)

The Steam Linux Runtime sniper container (AppID 1628350) updated at the same
moment (19:41) to BuildID 23629198 and has not changed since.

ALVR's driver files have an unchanged mtime of Nov 2025 — ruling out an
ALVR-side regression.

Bug 1: vrlink driver binds sockets to all interfaces, including VPN tunnels
vrserver.txt shows the built-in vrlink driver binding its UDP data link
and the embedded Mongoose web server (port 27062, used by the dashboard)
to every network interface present on the host, including a Tailscale VPN
tunnel:

vrlink: SVLDataLinkTransferUDP::Init 192.168.1.98 dev eno1 10400 ...
vrlink: SVLDataLinkTransferUDP::Init fe80::... dev tailscale0 10400 ...

A transient Tailscale relay connectivity issue (unrelated to the headset)
produced:

[Error] - Mongoose mongoose.c:783:mg_error : 4 216 socket error
[Info] - vrlink: Performing shutdown.

...which 5 seconds later killed the master vrmonitor process, triggering
SteamVR's own failsafe:

[Warning] - Lost master process 14745 due to restart hint. Quitting all in 10 seconds if it
doesn't reconnect.
[Info] - Quitting all OpenVR processes because master process 14745 disconnected

Full SteamVR teardown, every component killed. vrlink has no business
binding to a VPN interface that has nothing to do with the HMD.

Workaround: disabling the (UI-hidden) vrlink driver via
steamvr.vrsettings: "driver_vrlink": {"enable": false}

Bug 2: ExpectWirelessHeadset read race kills every session, even with vrlink disabled
With vrlink disabled, every single connection attempt (5/5 reproduced)
still fails identically:

[Info] - Tracked device activated: 0
[Info] - CheckHmdDriverName: ActualTrackingSystemName: alvr_server (0)
[Info] - ExpectWirelessHeadset: 0
[Info] - [System] Transition from 'SteamVRSystemState_NotReady' to
'SteamVRSystemState_Restart'.
...
[Info] - [System] Transition from 'SteamVRSystemState_Restart' to
'SteamVRSystemState_Shutdown'.

vrmonitor queries ExpectWirelessHeadset ~2.6ms after the tracked device
activates — seemingly before the ALVR driver (driver_alvr_server.so,
emulation_mode: Quest2) has finished setting that property — reads false,
and treats the wireless HMD as a wired display that just got plugged in.
That triggers the internal "reload display properties" restart sequence,
which never recovers and shuts the whole session down instead. Black screen
in headset, then disconnect.

User-facing error originally reported: SteamVR failed to initialize for unknown reasons. (Error: vrclient Shared Lib Not Found (102)(1023))

Repro
Connect Meta Quest 2 or pico 4
via ALVR v20.14.1 (default Quest2 emulation mode)
Launch SteamVR via Steam (no custom launch options needed to reproduce)
Connect headset client
Observe ExpectWirelessHeadset: 0 in vrmonitor.txt immediately after
device activation, followed by failed Restart→Shutdown transition

This problem started this week after the steam update so don't think it's JUST a ALVR issue their saide has not changed since last year. So steam changed something but it's ALVR's problem seems kind of weak sauce.

Unfortunately, ALVR does not use normal SteamVR APIs.

To use an analogy here, let's imagine you go to a restaurant; the restaurant has a menu, and you can order food off of it. The restaurant then provides the food, and you get to eat. If the restaurant gets a new oven and rearranges things -- now the large freezer is on the south side of the kitchen and the main oven is where the freezer used to be -- it doesn't matter; you order off the menu, and the food comes out. There is a defined, consistent interface for you to use.

Using normal SteamVR APIs is like ordering off of the menu; you don't need to know exactly where everything is in the kitchen, as long as your order goes in and the food comes out. An update does not break things because those APIs are consistent, and if for some reason it does break something using those APIs, then you can reasonably argue that genuinely is SteamVR's fault.

What ALVR is doing, however, is to basically say "Oh hey I don't need the menu! See, you just walk into the kitchen, turn left 40 degrees, move exactly 10 steps, open the freezer, take this thing from the third shelf down on the right-hand side, close the freezer, turn 60 degrees right, walk 10 paces, turn on the stove, etc." So when the kitchen gets rearranged for that new oven, now you walk through the door and turn and then find no freezer, or slam into the wall, or whatever.

More literally what ALVR does is functionally to move the entire kitchen out of the way, placing its own kitchen there, and then tries to let things do stuff in its kitchen, which it then goes and does in the real kitchen. Needless to say, if there is anything that changes inside the real kitchen, everything in that method stops working. The kitchen staff who expect to find things in the new locations are slamming into things in ALVR's kitchen, and ALVR trying to do things in the real kitchen is slamming into things in the new locations.

(Literally, ALVR moves chunks of SteamVR out of the way and tries to replace them with its own things.)

As such, the only way that SteamVR can ensure that ALVR never breaks on an update is literally to never change anything, because ALVR relies on everything inside of SteamVR's internals being in exactly the same place it was previously.

As an explanation: this is why I keep asking if people see things crash for them without ALVR involved (meaning removing all the pieces of ALVR that pretend to be pieces of SteamVR, and putting the real pieces of SteamVR back). Because if they're seeing crashes with VRLink, that's genuinely on us and something we can fix.

The only fix for ALVR is "everything has to be exactly as it was previously."

That said, as sort of a corollary to all this: if you have a specific reason you think you need to use ALVR versus VRLink, please put in a feature request? VRLink is within our control, and something that can be fixed if there's a reason it doesn't work for you.

We may as well just be waiting for a package update from ALVR. We haven't heard back from the developers, and I am aware it is an open source project, so that may not happen immediately. While this does unfortunately mean we use the previous version of SteamVR, I think we are still fortunate it works at all.

i had a 303 error that didn't go away after multiple reinstalls and just kept on saying that a 'key component of steam vr isnt working correctly ' i fixed it by changing the steam vr version one more time and reinstalling alvr, it worked somehow even though that i did that multiple times but i am glad that it works now.

@Packetdancer I have tested things with the latest SteamVR version on EndeavourOS (Aarch Base).
With just bare SteamVR I don't have the tracking issues that I see when I add ALVR into the mix (though I use ALVR so I can actually get some things to work that SteamVR doesn't let me set).

As soon as I turn ALVR on I get motion sickness again ;) rolling back SteamVR one version does then resolve the ALVR issues again.

Edit: As for the reasons to use ALVR, that's quite simple. VR is still a bit quirky, and I use ALVR to set nvidia encoder/bandwith settings to a finer detail to ensure a smooth experience. For games like HL Alyx this doesn't matter too much, but for high-paced games like Beat Saber a little lag spike can be a huge pain.

So having this kind of low level encoder/GPU tuning in VRLink would immediately make me switch over to it.

System specs for completeness:

OS: EndeavourOS
Kernel: Linux 7.0.9-arch1-1
Display (MO27Q28G): 2560x1440 in 27", 240 Hz 
Display (DELL U2724DE): 2560x1440 in 27", 120 Hz
DE: KDE Plasma 6.7.1
WM: KWin (Wayland)
CPU: Intel i9-13900K 
GPU: NVIDIA GeForce RTX 4090
Memory: 32GB
HMD: Meta Quest 3

One note: After some lockups in the latest nvidia driver for Arch, I have rolled it back one go as it kept crashing games like Deadlock and Civ VII.

though I use ALVR so I can actually get some things to work that SteamVR doesn't let me set

Since ALVR on Linux is apparently largely abandoned, could you put in tickets for whatever the things that don't work for you are? Either bugs (if it's stuff that should work which isn't) or feature request (if it's a feature you absolutely need from ALVR that VRLink doesn't provide).

I can't really fix ALVR, for the reasons listed above; the only way to make it work again would be to literally go fix the open source project itself. But spending a bunch of spare time fixing ALVR feels like the wrong use of my time, when I could instead do my day-job and work on trying to improve VRLink to cover whatever use cases it's not currently handling...