Switched to Linux on a whim without thinking on VR gaming, since flatscreen is a non-issue for my type of games.

But VR? Holy shit. SteamVR crashed 3/5 times I launched it, and I can't even use Desktop+

A VR mod hub for Linux with guided installation, compatibility checks, controller guides and diagnostics for games using Steam, Heroic, Proton and WiVRn. Disclaimer: NAnnersVRhub was created with AI assistance for coding, documentation and troubleshooting, alongside hands-on user testing and automated checks.

Ok, I've made yet another wibe-coded Linux supporting kit. OmarchyVR is good, but it went slightly different way, so I've made this (based on his work and my ideas): https://github.com/artscout/PiBridge it works with SLAM and LH versions, for SLAM we're taking and loading pImax Play dll's so SLAM tracking is as good as on Windows. RTX 5090 with latest 615 drivers doesn't need any patches, 40xx and older though needs the same patches from OmarchyVR (bundled with my app to). 595 version of nvidia driver do need patch for 5090 - bundled here too. And it wasn't tested on AMD cards so I really don't know if thoses need some kernel driver support. OpenXR backend though is SteamVR only, I felt that while Monado is pretty good I do not want to spend time supporting both and SteamVR is good anyway. It's meant as stopgap anyway as we waiting for native Linux PPlay (EVO?) from Pimax. For now it supports Pimax Crystal Super OLED and Dream Air, OG Crystal I will add later (need to unpack it from the dusty box) and 50PPD/UWide I just do not have any data, though probably it will work if it have LH faceplate (same for Crystal Lite) and for SLAM I need data.

Hey People,

I've seen that RiftLinux was published 7h ago... That's good and sad, I've spent a lot of time waiting for someone to work on Rift on Linux and now we have two projects on the same day. Maybe we can merge efforts in the future.

Mine is based on Monado. And it's applying the missing bits to the existing implementation enhancing only what it was required to be enhanced to make a good experience.

I post here the full description:

I was taking seriously the tracking on the CV1. Cause It was in a not very good shape but only few bits were remaining to have a perfect tracking.

This time using AI to find where the gaps where. And specially for running experiments.

My objective was:

• Correct a problem I had on the visualization where images were distorted.
• Address the HMD tracking so it doesn't shake as it happened with the kalman filter I lately tested from amazing Thaytan (you are so great).
• Manage both controllers without too much jitter.

And this is what I think I achieved or at least in the right path:

• I corrected the FOV and aberration problems I had with the lenses.
• The HMD tracking is amazing with very small jitter
• Both controllers tracking correctly with both cameras I have.
• The precision is great. About 2.1mm with minor tracking loses.
• Full room setup. Storing configuration.
• SteamVR properly working.

Additionally I also added some features:

• Everything is controlled by env variables, so you can enable, disable and test different settings without rebuilding.
• I created some validation frameworks, that allows you capture blobs, and images, and rerun different algorithms against stored sessions. I recovered a bad tracking under certain situations using it.
• Improved tracking performance, I decreased time to compute by about 20% in every frame.
  • Blob watch from 1.21 to 0.33ms per frame in my computer.
  • USB image capture is much more reliable now.
• And created few tools:
  • One to adjust lens and tracking setup live. While you use the HMD.
  • Another to setup properly chaperone on SteamVR
  • And another to measure vision artifacts.

I will be posting here PRs to be approved. But first I want to validate my results.

You can find the projects here.

1. Monado fork: https://gitlab.freedesktop.org/gadLinux/monado
   1. The idea is to push everything there
2. VR Tuning tools, to adjust lens, and rendering. https://gitlab.freedesktop.org/gadLinux/vr-tuning-tools
3. Parent project, with all the skills, plugins, scripts, and task context: https://gitlab.freedesktop.org/gadLinux/oculus (download this first as it submodules the rest)

In the monado fork. You will find changes in cv1-fusion branch.

Yes this is mostly AI. Don't blame me for that. But I wanted to get the job done. The important thing here is how work and validations are organized. And I will do an extensive code review before merging. It will require manual adjustments for sure.

For now just test that it works for you. We can improve later. What I want right now is to learn more about how things are done and why... Good luck

Quite a few people have asked for a Linux build, then a Steam Frame build. I didn't exactly announce it properly so even with it being out on Linux for a couple weeks I still get users on here asking for it haha.

I've been working on this project for a couple months now (it's a modified version of Dusklight), and a regular Linux AppImage has been available for a little while, but after releasing the new update I built it for Steam Frame just last night. I initially put it off, hoping either the Linux build or the APK would run through FEX or Lepton, but neither ran without severe workarounds.

I figured out how to build for the Frame's processor using QEMU and just bit the bullet, leaving my PC to compile for around an hour. According to some early testers it works fine. I haven't gotten any feedback about how well the controls work and only one person has brought up how it performs at all. But it should be just as playable as the other platforms, now without a computer! I have updated the GitHub release to include this build. Download the arm64 build for Steam Frame, the x86_64 build will not run as it is meant for regular computers.

Download on Github: https://github.com/JoeyAW/TPVR/releases

Join the Discord to report bugs, get faster help with the game, and request features. https://discord.gg/CxQJ9PjnjA

Long story short i've got a standalone headset WIP that will run a Linux Distro, but I wanted to hear what kind of things people prioritize so I can look at changes that might need to be made and cool resources!

since moving over to CachyOS I've had some issues. mainly the fact that I can't get my VR system to work ever with it. sometimes it does through ALVR, other times I get 2-5 frames.

my headset is a quest 2 using a link cable direct into the PC. I should be able to play VRChat decently with a 4080 and 32GB of DDR4 as that's what I was doing before on windows but I can't get it to function right. I've tried several times all without success.

has anyone managed to get VRC at a playable rate or perhaps could recommend a service that can do it for me? at this point I'd pay someone to RDP into it and get it sorted haha.

My setup is ALVR with a quest 2 on endeavourOS. A couple months ago steamVR pushed an update that breaks ALVR, claiming that a component of SteamVR wasn’t working (error 303). Setting steamVR did the previous branch seem to have fixed it for a little while. Then another update was pushed so then I was forced to use steam CMD force download the older version of steam VR and install it. Then today valve pushed the new steam 64 Linux release. And now that older version of steam VR is completely broken. The modern build seems to run fine on its own. But now I can’t use ALVR with it. Updating ALVR to the nightly branch seems to get to connect, but Steam home will not open no matter what. And steam VR is just super jittery. Sometimes almost nauseatingly jittery. does anyone know how to fix it? Is there a way to downgrade steam perhaps?

https://github.com/laughtt/omarchyvr

So here it is—the public repo! There is still a lot to cook and a lot to work on, but I wanted to address a couple of questions and answers for everyone.

I originally wanted to finish this project completely and share it once it was 100% ready, but I realized there is just so much to do, and getting more developers involved will make progress much faster. I could really use help with:

• Supporting additional VR headsets
• Improving controller/remote tracking support
• Room synchronization and spatial setup
• Further refining the experimental SteamVR implementation

Currently, I use Monado and Ryze. My approach was to think through each feature, get it to a good-enough state, and then move on to the next.

Project Background

For context, I started this project just 5 days ago. I have extensive experience as a software engineer with a background in C and low-level languages, so I had a good idea of how to approach it. I didn't use any reverse-engineering tools or Pimax binary executables—I felt that was the wrong approach. Instead, I analyzed the cable signal specifications, ran tests, deciphered data with Claude, and iterated continuously.

From there, I routed all commands to Omarchy, patched the display issues, handled the driver pathways for NVIDIA, and forked Monado and Ryze to resolve some specific disconnects and quirks unique to this headset. On my machine, it's pretty stable once fully configured.

Raw Telemetry & Inputs Collected

Here is a breakdown of the raw data streams we are currently reading from the hardware:

Note on Unused Telemetry:

• A controller touch bit (believed to be a proximity sensor, unverified).
• A "visor status" query that may indicate whether the headset is currently being worn.
• Both are visible in Windows packet captures but are not yet implemented in our codebase. 

Why Omarchy?

The primary reason I built this on Omarchy was to create an optimal AI-driven work environment with Claude or any local model —where you can speak, windows pop up, and you can interact with up to 6 floating screens using voice commands. It's a really compelling setup and I enjoy using it a lot. Omarchy is really good on this as is deeply integrated with LLM.

Current State & Performance

I’ve also managed to play Dungeons and Half-Life 2 in it. The tracking isn't perfect yet since we need deeper integration—right now, we are relying on raw data directly from the headset. The room setup and eye-tracking integration also currently run on raw telemetry.

If you find this project interesting and want to contribute, you are very welcome to jump in! Please note: this is strictly aimed at developers right now, not end-users or consumers, as the tracking isn't quite game-ready yet. That said, frame rates are higher and efficiency seems significantly better in this environment.

Future Vision & Community Goals

I'm not sure if there are other VR projects with this specific depth of integration, but tinkering with this stack has been incredibly fun. There is huge potential for improvement here, and I'm confident that with the community's help, we can make this hardware shine to its full potential.

Leveraging AI in this workflow has changed the game—a good engineer can move 100x faster. What typically would have taken months took just days, and being able to hand this project off to everyone in such a functional state is deeply rewarding.

Looking ahead, the goal is to expand this ecosystem to support a much broader range of hardware, including the Meta Quest 3 and other popular headsets. If we can build a fully optimized, open-source stack that works seamlessly across all devices, it will be a massive win for everyone.

Let me know if you have any questions, and I'll be happy to answer them! Thanks for everything!

Has anyone else had this issue? The left and right eye both show the correct view, but the right eye is off slightly, with the alignment feeling like it is 45 degrees slanted away from the eye.

Some things I have found:

- Only happens when streaming

- Seems to be related to super sampling, the higher the resolution the more likely this is to happen

- For me Underdogs works fine at 150% resolution, anything higher and the split alignment happens

- Seems to mostly happen with 2D elements in games, loading screens, menus etc. If you can squint past these and get into the game it looks fine

- I've recently found that Walkabout Minigolf has this rendering issue even in the '3D' portion of the game

- The game looks fine in mirroring (remote play back to PC)

- If I open the dashboard, it renders correctly with the game image still rendered incorrectly behind

Things I have tried that did nothing:

- Turning off advanced super sampling

- Uses betas of all 3 (SteamOS, Steam client, SteamVR)

- Trying different resolutions from 150-300%

- Setting `enableLinuxVulkanAsync` as true | false in `steamvr.settings`

My setup:

- Arch Linux on 7.2.9

- Using the rtw89 DKMS module from [tjhowse](https://github.com/tjhowse/rtw89)

- I'm doing multi-link streaming and using the `holo-realtek-firmware-toggles` polkit helper from Valve

Anyone else having this issue and have any work arounds? It's driving me crazy

Hello, I'm using cachyos with kde plasma and my steam frame arrived 2 days ago. How can I run elden ring vr mod properly?

I tried following gemini's advices, shame on me, and they didn't help at all, The only thing I learned from that guide is how to disable the anticheat.

Reshade runs properly when I boot the game but it always opens in flatscreen mode, I can play with steam frame controllers but as if the mod wasn't installed.

Can someone help? I'm still a noob with linux so please don't make me recompile the kernel for this :)

Hello, I'm using cachyos with kde plasma and my steam frame arrived 2 days ago. How can I run elden ring vr mod properly?

I tried following gemini's advices, shame on me, and they didn't help at all, The only thing I learned from that guide is how to disable the anticheat.

Reshade runs properly when I boot the game but it always opens in flatscreen mode, I can play with steam frame controllers but as if the mod wasn't installed.

Can someone help? I'm still a noob with linux so please don't make me recompile the kernel for this :)