DroidXR

01 / The reason for the project

What if the PSVR 2 I already owned could go standalone?

Steam Frame got me thinking about it. I liked the idea of that freedom, but its screen and price weren't what I wanted. I already had a really nice PSVR 2. Its biggest downside for me was simple: it was wired to another machine.

And I wanted to keep what made it good. PSVR 2 has OLED screens and eye tracking. OLED gives you those deep blacks; eye tracking lets software know where you're looking. I wasn't excited about buying another headset and giving up hardware I already liked.

So I started researching how to get away from the PC tether. I considered different platforms, then looked at my own phone. My RedMagic 11 Pro already had a Snapdragon 8 Elite Gen 5. There was a lot of computing power sitting right there. Why not put the work into that, and figure out how to drive the headset?

That's where this started. Let the phone become the computer and the operating system, keep PSVR 2 as the headset, and carry the setup with you. Eventually, I want it to run compatible experiences itself or receive a wireless VR stream from a PC. The headset-to-phone cable and portable power still need to be part of the physical setup. Freeing it from a cable running back to a PC is the point.

02 / Before VR, there was a display problem

First, make the phone send the right picture.

Having a powerful phone didn't mean I could just plug the headset in and start a game. First, the phone had to send the right kind of picture: the right size, refresh rate and arrangement for two eyes. Getting an ordinary second screen working was only the start.

We built an Android app to see what the connection was doing and control it. It reads what the connected display supports, checks the mode actually being used, and handles starting and stopping the experimental display setup. My prototype uses a rooted phone, which gives the app system access that normal Android apps don't have.

Once we could control the output, the next problem appeared: Android and the VR software both wanted to use it.

03 / Giving the display to Linux

Android had to let go without losing its own screen.

I started with Linux running in a container on the phone. Think of it as a Linux workspace using the same phone processor and graphics hardware while Android keeps running. That gave me access to graphics drivers and VR software that already existed, rather than having to write everything from scratch.

But the two systems couldn't fight over the headset's display. Some early attempts froze or crashed the phone. Turning off Android's entire display system wasn't much of a solution either; I still needed to use the phone's own screen.

We worked toward a proper handoff. The app asks Android to release the external screen, Linux gets permission to use that output, and stopping the session gives it back. We also had to clear old connections and processes so one failed attempt wouldn't break the next one.

Now the phone could keep its own screen while Linux drove the external one. That opened the door to VR, but we still needed something that understood PSVR 2's movement and its two eye views.

04 / Turning display output into VR

The picture and the tracking had to meet.

A picture on the headset isn't automatically VR. Turn your head and the view has to follow, at the right time, with a different image for each eye. The piece coordinating all that is called a VR runtime. We used an open source one called Monado.

The Linux graphics stack, including Mesa and its Turnip driver for the phone's graphics chip, handled drawing. Monado handled the headset side. OpenXR gave compatible applications a common way to ask for head movement and submit eye images.

The working route also needed a compatibility bridge to Sony's Windows driver. That driver was built for the x86-64 processors used in many PCs; the phone uses ARM64. Getting those pieces to communicate was another layer of the experiment. Running them on the phone didn't turn them into native Android software.

So the chain was finally coming together: the app prepared the display, Linux could use it, the graphics driver could draw, and the runtime could connect the game to the headset. Then came the part I actually wanted to see.

05 / A game in the headset

Skyrim became visible. Then it had to feel right.

Skyrim VR ran through the phone's container setup, and I confirmed that it was visible inside PSVR 2. Both Sense controllers were switched on. At that first checkpoint, controller tracking and audio still needed their own checks.

Later, performance work exposed a problem a frame counter could hide. A game could report more frames while head turns still produced ghosting: old-looking images trailing the movement. The software doing the final headset update was waiting behind the game's graphics work.

We changed how the phone prioritized those headset updates and passed frames along. In a later comparison, the delay dropped. I put the headset on again: the ghosting was gone, the controllers were fine, and motion felt much smoother. A bigger number on a counter wouldn't have told that story.

Eye tracking was the next connection I wanted to make useful. I confirmed eye tracking and foveation working in my tests, and the recording shows moving gaze overlays. The recovered DXVK source explains the game-side path: it reads Monado's gaze and updates shading-rate maps for selected Skyrim passes. SGSR2 processing in the compositor is a separate step; I tested that on the phone too and found that it improved the image.

The source behind that gaze-enabled build is now recovered and matched to the libraries from the game session. That means I can share the actual patches behind this part of the setup. Here's how we connected eye tracking to the game.

The motion comparison and measurement notes ↗

06 / Why one working game was not the finish

Alyx exposed another layer of compatibility.

Once Skyrim was working, I wanted to see how far the setup could go. Half-Life: Alyx took a different route: an ARM64 Linux version of the game with its own connection into the VR runtime. The headset work still helped, but Skyrim's settings weren't a recipe I could simply copy.

We worked through missing connections and graphics failures. Eventually I could recognize the menu, but the views were distorted and the hands were wrong. I called it unusable. It was progress toward finding the problem, but I couldn't call that playable VR.

That led to a SteamVR comparison. The normal download supplied PC-format binaries. A supplied Steam Frame recovery image contained the ARM64 runtime we were missing, so a separate SteamOS container was investigated. It started, but phone reboots made stability the priority. The next plan was to bring the needed runtime files back to the existing Linux setup instead of depending on the whole SteamOS environment.

I kept the working Linux setup as the baseline. The compatibility experiments were useful, but I also wanted a cleaner way to start a headset session from the phone. That led to the next route.

07 / The native Android route

Keep the phone. Remove the container dependency.

The next thing I'm building is a headset runtime that runs directly in Android. That's what I mean by native: the phone's own software talks to PSVR 2, without needing the Linux container and its Windows-driver compatibility path.

That means connecting the existing headset knowledge to Android's USB access, graphics output and application lifecycle. We can reuse open source work where it already solves a problem and study the remaining driver behavior where it does not. Copying a library from Linux is insufficient because Android expects a different set of system interfaces.

The first tests could connect to the real headset, read its motion sensors and start a VR session. But the code wasn't accepting the complete movement reports it needed to work out the view. A session could start and still have no picture to send to the eyes.

A later test with the headset sitting off my head moved forward. Most of those movement reports were accepted, and the software produced a test picture for both eyes. That was a useful step, but a screenshot by itself couldn't tell me whether tracking would work while I was wearing it.

So I put it on for the next test. That earlier run went black and every complete movement report was rejected. We had to keep working on how the code read the headset's reports.

At 03:40 UTC on 14 October, I confirmed the next native milestone: an image in the headset, with the view following my head. The updates were still arriving unevenly. Now I can see and move the view, the next job is to make that movement feel steady and repeat the result reliably.

This is a separate step from both the earlier DSC breakthrough and the working Skyrim container setup. The display link gets images to the headset; native tracking and presentation have to keep those images lined up with my movement.