# WiVRn: Linux OpenXR Streaming for Standalone Headsets

> WiVRn streams PC VR applications from Linux to supported standalone Android headsets through a headset client and a PC server. It is a practical OpenVR and OpenXR path for supported Quest, Pico, HTC, and Samsung devices, but headset support, sandbox limitations, and version matching constrain adoption.

**WiVRn/WiVRn** — The Linux OpenXR streaming application to standalone headsets

- Repository: https://github.com/WiVRn/WiVRn
- Stars: 1,809 · Forks: 238
- Language: C++
- License: GPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/wivrn-wivrn

## WiVRn's Linux-to-Headset Streaming Boundary

WiVRn addresses a specific gap in PC VR: using a supported standalone headset as the display and tracking endpoint for a VR application running on a Linux computer. The headset does not need to execute the PC game locally. Instead, a headset application communicates with `wivrn-server` on Linux, and the server configures the OpenXR and OpenVR runtimes so that connected VR applications use WiVRn.

The project targets Quest 1, Quest 2, Quest 3, Quest 3s, Quest Pro, Pico Neo 3, Pico 4, HTC Vive Focus 3, HTC Vive XR Elite, and Samsung Galaxy XR according to its README. It lists the two HTC models as laggy, so nominal support should not be read as equal performance. Other Android VR devices have uncertain support because WiVRn cannot confirm them. Play for Dream, non-Android VR devices, and Android devices without VR support are outside the documented target.

The Linux client mentioned in the README is only for debugging. It has no audio or hardware decoding, so it is not a practical substitute for the headset application. This boundary matters when choosing WiVRn: the supported deployment is a Linux PC plus a compatible standalone Android VR headset, not a general-purpose remote VR client for arbitrary hardware.

WiVRn is licensed under GPL-3.0. The repository also contains `LICENSE-OFL-1.1`, so components may carry separate licensing terms that should be checked when redistributing or integrating particular files. The GPL-3.0 designation covers the project as identified by the repository, but this review does not interpret the effect of that license on a particular deployment.

## Server, Headset App, and Runtime Handoff

The documented architecture has two operational halves. The Linux side provides `wivrn-dashboard`, a graphical frontend that includes an initial setup wizard, and `wivrn-server`, the actual headless server process. The Android headset side provides the WiVRn application. During setup, the dashboard can send the user to the Meta Store for a Quest headset or download the appropriate APK for another supported headset.

Connection discovery depends on Avahi. The README requires `avahi-daemon` to be running and identifies port `5353/UDP` for Avahi. WiVRn also uses `9757/UDP+TCP`, so network discovery and transport require firewall rules for both services. Once the headset finds the computer, the user selects it from the server list and starts streaming.

After connection, `wivrn-server` changes the OpenXR and OpenVR configuration to make WiVRn the selected runtime. This creates an important operational rule: VR applications can run only while the headset connection is established. The configuration is reverted when the connection ends and all running VR applications close. An application therefore does not simply fall back to another runtime while WiVRn remains selected.

The connection also creates a virtual speaker and, when enabled, a virtual microphone. Linux users must select those devices as the default audio output and input. The README does not describe the video codec, transport protocol, controller packet format, tracking algorithm, latency controls, or adaptive bitrate mechanism, so those implementation details cannot be assessed from the available documentation.

For OpenVR and Steam compatibility, WiVRn needs a compatibility library such as xrizer or OpenComposite. The Flatpak includes both. Native package installations may require the user to arrange that compatibility layer separately, depending on the distribution package.

## Native Packages and Flatpak Installation

WiVRn recommends a native package when the user's distribution provides one. The README lists packages for Arch, Fedora, Gentoo, NixOS, and Ubuntu, including named repositories or package sources. It also provides a Flathub Flatpak for distributions without a suitable native package. These are two different deployment models, and the choice affects features.

The Flatpak contains xrizer and OpenComposite, which reduces the need to install those compatibility components separately. However, its sandbox can prevent support for SteamVR tracked Lighthouse devices. It may also block virtual gamepad, keyboard, and input devices forwarded from the headset. Native packages should therefore be considered when tracked SteamVR hardware or forwarded input devices matter.

The README directs users to the PC dashboard for first-run setup rather than providing one universal package command. It would be inaccurate to invent a package name and installation command for every distribution. The concrete first step is to use the listed distribution package source or install the Flathub application, then launch the graphical `wivrn-dashboard` frontend.

## First Connection with Avahi and WiVRn

Before starting WiVRn, enable and start Avahi. The documented command is:

```bash
systemctl enable --now avahi-daemon
```

This starts Avahi and configures it to start automatically. SteamOS requires an additional Avahi configuration change before WiVRn can publish its user service on the network. The README links to WiVRn issue 1001 for those instructions rather than duplicating them.

If UFW is installed, allow Avahi discovery and the WiVRn transport port:

```bash
ufw allow 5353/udp
ufw allow 9757
```

The second command opens WiVRn for UDP and TCP, matching the README's port requirements. The first command opens Avahi only for UDP. A successful setup should expose the Linux computer through the headset application's server list after the server and client are running.

Package-managed installations include a systemd user service named `wivrn`. It can start automatically at login with:

```bash
systemctl --user enable --now wivrn
```

This command applies to installations that provide the service through the distribution's package manager. A headless deployment can instead run `wivrn-server`, while `wivrn-dashboard` provides the graphical setup interface.

## Headset Setup, Permissions, and Default Streaming

The dashboard's wizard installs or links to the correct headset client. For Meta Quest hardware it can lead to the Meta Store, while other supported headsets receive the appropriate APK. The PC server and headset client must run the same WiVRn version. A version mismatch is therefore an immediate deployment blocker rather than a minor configuration detail.

Start `WiVRn` on the headset. A store-installed application appears normally, while a dashboard or manual `adb` installation appears under an unknown sources section. On first launch, the application asks whether to enable optional capabilities such as microphone, hand tracking, and eye tracking. These require permissions, and the README says they can be granted later from the Settings tab.

The README advises retaining default settings unless a problem requires adjustment. This is specific guidance because the available documentation does not provide a full tuning matrix for latency, resolution, bitrate, tracking quality, or feature combinations. Users should not assume that every advertised optional feature is equally supported across headsets, installation methods, or sandbox configurations.

Once the server appears, select its connect button. With the headset connected and no XR application running, WiVRn presents an application launcher. The launcher sources VR-tagged Steam games and desktop files containing `X-WiVRn-VR` in their `Categories` field. Steam may need to be restarted after a new VR game is installed so the list updates.

## Flatpak Steam Runtime File Access

A Flatpak Steam installation can run only when it has access to the Flatpak version of WiVRn and the relevant runtime configuration. The README provides this override for system-wide Steam:

```bash
flatpak override \
  --filesystem=xdg-run/wivrn:ro \
  --filesystem=xdg-data/flatpak/app/io.github.wivrn.wivrn:ro \
  --filesystem=/var/lib/flatpak/app/io.github.wivrn.wivrn:ro \
  --filesystem=xdg-config/openxr:ro \
  --filesystem=xdg-config/openvr:ro \
  com.valvesoftware.Steam
```

For a user installation of Flatpak Steam, the README says to add `--user` to `override`. These permissions expose WiVRn runtime data, OpenXR configuration, and OpenVR configuration as read-only paths to Steam. The same override approach applies to other VR applications distributed as Flatpaks.

This setup does not remove every Flatpak limitation. The dashboard and runtime integration are available through the Flatpak package, but tracked Lighthouse support and certain forwarded virtual input devices may be unavailable because of sandboxing. Steam launch options may also be required for individual games, and the dashboard or command-line output provides the applicable command rather than one universal Steam option.

## Support Gaps, Hardware Limits, and Upgrade Work

WiVRn's clearest limitations are hardware and packaging boundaries. Compatibility is explicit for the listed headsets, uncertain for other Android VR devices, and absent for Play for Dream, non-Android headsets, and non-VR Android devices. The README labels support for HTC Vive Focus 3 and HTC Vive XR Elite as laggy. It does not provide a quantified latency target, frame-rate result, resolution matrix, or headset-specific troubleshooting table, so performance expectations cannot be reduced to a supported or unsupported label.

The headset and PC server must use identical WiVRn versions. This creates a coordinated upgrade requirement. Installing a new server while leaving an older headset client creates a mismatch, while changing only the client has the same constraint. Recent repository activity includes releases `v26.9`, `v26.6.2`, and `v26.6.1`. The last push was on 2026-10-17, and the repository is not archived. Those facts show recent project changes, but the documentation does not define a long-term support period or an automatic compatibility policy across releases.

Another limitation is configuration ownership. Most settings are controlled from the headset app, while server and application behavior can also depend on package method, compatibility libraries, default audio devices, firewall rules, Avahi, Steam metadata, and optional Flatpak filesystem access. A failure can therefore come from discovery, runtime selection, audio routing, permissions, sandboxing, or the headset application rather than from WiVRn's streaming path alone.

## Conclusion

WiVRn is suitable for Linux users who want to run Steam VR and other OpenXR or OpenVR applications on a supported standalone Android headset, particularly Quest models. It is not appropriate for non-Android headsets, Android devices without VR support, Play for Dream, or users who require features excluded by Flatpak sandboxing. Verify headset model support, native package availability, required firewall access, and exact client and server versions before adoption.

## FAQ

### Which headsets are supported by WiVRn?

The README lists Quest 1, Quest 2, Quest 3, Quest 3s, Quest Pro, Pico Neo 3, Pico 4, HTC Vive Focus 3, HTC Vive XR Elite, and Samsung Galaxy XR. Support for other Android VR devices is uncertain, while Play for Dream, non-Android VR, and non-VR Android devices are unsupported.

### How do I install WiVRn on Linux?

WiVRn recommends a native package when one is available for the distribution and also provides a Flathub Flatpak. The README lists package sources for Arch, Fedora, Gentoo, NixOS, and Ubuntu, then directs users to launch `wivrn-dashboard` for initial setup.

### Why can my headset not find the WiVRn server?

The headset relies on Avahi for discovery, so `avahi-daemon` must be running. The firewall must allow `5353/UDP` for Avahi and `9757/UDP+TCP` for WiVRn, and SteamOS also requires the Avahi configuration described in the linked issue.

### Why should the PC server and headset app use the same version?

The README explicitly warns that the VR client and PC server must run the same version of WiVRn. A mismatch can prevent the two halves from working together as intended.

### Does the WiVRn Flatpak support Lighthouse devices and forwarded inputs?

Not necessarily. The README says Flatpak sandboxing may make SteamVR tracked Lighthouse devices unavailable, as well as virtual gamepads, keyboards, and input devices forwarded from the headset. Native installation is the documented option to examine when those features are required.

## Sources

- [Issues](https://github.com/WiVRn/WiVRn/issues)
- [License: GPL-3.0](https://github.com/WiVRn/WiVRn/blob/master/LICENSE)
- [README](https://github.com/WiVRn/WiVRn/blob/master/README.md)
- [Releases](https://github.com/WiVRn/WiVRn/releases)
- [WiVRn/WiVRn on GitHub](https://github.com/WiVRn/WiVRn)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wivrn-wivrn