r/Pimax • u/PrestigiousArrival18 • 2d ago
Discussion I reverse-engineered the Pimax Windows service for Unix-based systems, specifically focusing on Omarchy's
So, I have full control over all inputs coming from the headset, and I already have a full application working on Unix/Linux systems (specifically for the Dream Air SLAM for now).
What I currently have access to and working: • All IPD, brightness, and lens adjustments • Full controller input • Camera access • Eye tracking control • Native SteamVR integration • A custom pass-through desktop app that stays fixed in space and supports AI commands
Technical details: I had to patch the latest NVIDIA drivers and work with Monado.
There is still a lot to do, especially regarding support for other devices, but it has a ton of potential. If there's enough interest, I'll open-source it and share the GitHub repo.
What do you guys think? Would anyone want access to this?
UPDATE:
I’m almost finishing the final steps and integrations so everyone can contribute—automating testing and setting up a way for everyone to use Claude, Codex, or whatever text LLM on their machine to submit a PR for compatibility with all headsets.
There’s still a lot to do, but I find this really exciting: we have access to all eye-tracking data, can implement our own foveated rendering, and have full control over tracking. I also implemented a local AI (WhisperVR workspace) so you can work right in there—along with many other features.
This Saturday, I’ll have it ready for everyone! Thanks for your patience.
UPDATE2:
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!
6
u/vr_wanderer 2d ago
Getting closer to not being reliant on Pimax for software updates/fixes sounds nice.
4
u/Decapper Dream⚡AiR 2d ago
Nah as sboys3 said. Pimax has further power to lock the headset down. This might just push them to
2
u/Heliosurge 7 2d ago
Well if you recall Gupyexpress did make a custom firmware iirc for the 7invensun Droolon-pi.
1
u/deyhateuscustheyanus 1d ago
if they locked down a headset that i already paid for... first of all, i doubt anyone would trust them in the future. secondly, i would personally spend the rest of my life trying to convince people that they are worse than EA and sony combined.
i'm already pissed that something i paid for has a DRM and i didn't know, because it was probably in the small print. that should be illegal.
6
6
u/Heliosurge 7 2d ago edited 2d ago
This is awesome news! I will add your post to highlights. I know there are quite a few ppl interested in running in Linux!
4
u/Southern-Aardvark616 2d ago
Yeah, I would, I'm sure the opensource community would help you carry the baton, currently I leave my pimax disabled when in Linux and need to boot back to windows when I want to use vr
3
u/SnooLentils5510 9h ago
Ok thank you for the good idea. I've managed to run my Crystal Super oLED. But then I switched to LH tracking and Sboys3 driver creating a small merge of your ways and Sboys3 way. omarchyvr starts the device, Sboys3 makes it work via steamvr. your kernel patches though won't work with 5090 - different tech, I'll make a PR for you soon, I want to finish SLAM so at least the data from PCS will be there too.
2
2
u/PrestigiousArrival18 9h ago
If you can add those patches from the 5090 so we can suppor that to will be great. I added s3boys integration here to and steam vr runs fine in this version.
9
2
1
u/emil1326 2d ago
Im having problemes getting my 8k+ working with my amd9070xt on Windows, do you think this (or so e other project simillar) could allow me and Claude to mess around a bit and figure out how to actually make it work ? From what I understood, the amd drivers for vr on rdna4 arent quite compatible with the pimax service, except is I use the launch drivers of the graphics card but still crashes often, so im wondering if somehow this could allow me to modify the drivers and service I already had the firmware reverse engineered but didnt quite see much of any flaws
1
u/Frozenkuma 2d ago
except is I use the launch drivers of the graphics card
Please just update your drivers, that is probably a large source of your issues with both the crashing and the incompatibilities with Pimax's services.
2
u/emil1326 2d ago
If i do, the headset dosent connect to the gpu anymore, something abt a fence failing ? Idk, but pimax support only told me best could do is keep the og drivers... I would love to update the drivers tho
1
u/Ell1otA1ders0n 2d ago
REA right...
Didn't pimax want to release theirs for linux anyhow
1
u/Heliosurge 7 2d ago
Since 2016. They had said back then with the p4k. It has been off and on ever since with no reported progress. Just delays, which tbh makes sense with a small team. They would need to fix bugs in 2 platforms and release features in both.
17
u/fakeoptimism 2d ago
Not sure if Pimax would be happy about this.
As their customer, however, I am excited if this leads to more progress with long-standing challenges: better SLAM tracking, smoothness, reducing motion blur etc. Having more tinkerers look into the software and try to improve parts of it would be great.