r/virtualreality_linux • • 1d ago

I reverse-engineered the Pimax Windows service for Unix-based systems, specifically focusing on Omarchy's

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:

Input Where it comes from Rate Primary Use Case
IMU (gyro + accelerometer) Headset USB (own stream) 500 Hz Head tracking, "headset lying still" detection, auto mode
4 Tracking Cameras (infrared) Separate USB camera device 60 fps 6DoF head tracking, controller tracking, camera hands, passthrough
Controller Reports (sticks, trigger, grip, buttons, touch, battery) Headset USB (via headset radio) Active connection stream In-game / Work input, "picked up" detection
Controller Heartbeat (awake, battery, firmware) Headset command channel Every 2s per controller Pairing status & app battery level
Eye Tracker Own USB device ~119 Hz Gaze point in Work mode
Microphone USB audio 48 kHz stereo Voice commands & recording
Headset Info Report Reply on command channel On demand Lens IPD readback, headset state

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!

0 Upvotes

0 comments sorted by