Bridging CrossOver to OpenXR-OSX via wineopenxr (and the walls I hit)

[celestial-rose]

First of all, thank you so much for bringing hope to the Mac VR scene !
What you have built with OpenXR-OSX is incredible, and it inspired me to see if I could push the boundaries a bit further to support Windows PCVR games running on Apple Silicon for my Vision Pro

(Note: I am opening this as an issue since the Discussions tab isn't enabled on the repository, also this latter post is mostly AI inspired since I used Gemini for this R&D project - but this is not slop !)

Naively, I took the "AI route" (working heavily with Gemini CLI) to see if I could build a bridge between Windows VR games running in CrossOver (via D3DMetal) and your native macOS OpenXR-OSX runtime.
I wanted to share the architecture I came up with, the massive compilation walls I hit, and ask your thoughts on whether this path is actually viable.

The Architecture I Attempted

Since a Windows game in CrossOver can't load a macOS .dylib, I attempted to use Valve's wineopenxr (from the Proton repository) as a Universal Translator.

The idea was to build a "Triple-Bridge" leveraging Valve's PE/Unix Split architecture:

1. The Client (Windows): Compile wineopenxr.dll and inject it into the CrossOver bottle via the ActiveRuntime registry key.
2. Graphics Marshalling: Intercept xrEndFrame, use CrossOver's D3DMetal hooks to query the underlying Apple IOSurface ID backing the fake DirectX 12 texture.
3. The IPC Thunk (macOS): Instead of piping OpenXR calls through Wine's network stack, the Unix-side thunk (wineopenxr.so) would communicate directly with OpenXR-OSX using native macOS IPC:
   • Telemetry: POSIX Shared Memory (shm_open) for zero-latency head/hand tracking reads.
   • Pacing: Mach Semaphores (semaphore_wait) to block the game thread during xrWaitFrame.
   • Frame Handoff: Unix Domain Sockets (AF_UNIX) to pass the tiny IOSurface ID integer directly to OpenXR-OSX for presentation.

The Roadblocks (Why it's not finished)

While the C code, IPC headers, and Python thunk-generators were relatively straightforward, compiling a PE/Unix split DLL for macOS turned out to be an absolute nightmare:

1. macOS Native Compilation is Impossible: CodeWeavers strips the developer toolchain (winebuild, winegcc, and headers like <wine/unixlib.h>) from all consumer builds of CrossOver. Attempting to use a standalone llvm-mingw cross-compiler natively on the Mac results in fatal header collisions between standard MinGW Windows headers (windef.h) and Wine's internal headers.
2. Valve's Container Wall: Valve's wineopenxr relies heavily on their custom Proton build system, which uses a massive Podman container (sniper) with heavily patched compilers to bypass those exact header collisions.
3. The Apple Silicon Trap: The sniper SDK container is strictly compiled for AMD64/x86_64. It instantly crashes on an ARM64 Ubuntu VM (even with qemu-user-static, because tini uses unsupported kernel subreaper calls).
4. Software Emulation: Booting a full x86_64 Ubuntu VM in UTM via software emulation works, but forcing it to unpack and compile the millions of lines of Wine source code just to link this one .dll at the end takes days and dies to hyper-specific cross-compilation quirks (like nsiproxy.sys macro collisions).

My Questions for You

Since I am currently blocked purely by the Wine build system infrastructure, I wanted to ask:

1. Is this architecture viable? If I successfully compile wineopenxr.dll, is grabbing the IOSurface ID from D3DMetal and handing it to OpenXR-OSX over a Unix socket actually going to work with your presentation pipeline? Or will synchronization/ownership rules prevent a clean zero-copy render path?
2. CrossOver Integration: Have you ever considered a native CrossOver integration on your roadmap? (Perhaps CodeWeavers themselves would be interested in supporting your host runtime natively?)

Thank you again for all the hard work you've put into OpenXR-OSX. I'd love to hear your thoughts on whether this D3DMetal bridge is worth continuing to pursue!

[demonixis]

Hey,
Sorry for the long reply I don't had the notification! Feel free to ping me next time.
I need to go deeper into this architecture, but maybe we can do even more simple? How communicates wineopenxr.so with the runtime? Do you compile this lib? Because if you do, we can compile the runtime directly into the lib right? it's probably faster and allows custom code.

About your questions

1. It seems right on a first read but i'm not familiar yet with wine as a dev
2. Yes, I would like to fork wine and integrate a native bridge or something like that. The idea is to do what Valve did with Proton.

[celestial-rose]

Thanks for your reply !
I tried really hard to compile the lib on my M4; but on Silicon it doesn't natively build and with a VM it simply fails with other libs - I might need some real machine that I don't have (maybe a x86 machine or even a Windows). But it does feel like this layer is the only thing missing to run it on a Wine bottle; probably.

Thanks also for the questions; let me know if I can help in anyway; I own a Vision Pro with CrossOver full of VR-ready games to try on it

[demonixis]

Hey,
Wine/Crossover is a long term vision, because there are many things to solve before. But your work is impressive and I think we need to keep that here to continue the work later.
For help, sure, run the Vision Pro app and tell me if it works and how does it works.

• Can we use the dev strap as USB wiring system?
• How is the lantency in Wifi compared to Quest?

I'm going to expose more streaming parameters into the home to help tweak the streaming.

[monofunc]

I have a working wineopenxr for macOS and CrossOver, originally built for my Monado fork to run Beat Saber.

https://github.com/monofunc/wineopenxr

It forwards D3D11 OpenXR games to any x86_64 runtime that exposes XR_KHR_metal_enable, so an x86_64 build could probably work as the backend without changes.

[demonixis]

Hey @monofunc that's sounds great, are you this guy too https://x.com/giodotblue/status/2062893278891278504 ?
So do we need to compile the runtime into an universal lib to be able to make it works? Do you think there is a way to translate stuff to arm64 directly? Because Apple is dropping Rosetta in the next major release

[monofunc]

@demonixis no, I'm not this guy. 😄

1. Probably yeah. Strictly it only needs an x86_64 slice, since the loader dlopens the runtime into the Rosetta, but a universal build gives you that plus native arm64 for free
2. I don't think so

As for Rosetta's deprecation, Apple said:

Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.

So there's a decent chance it keeps working, but nobody knows yet what that subset will actually cover (well, maybe the CrossOver team does?).

[demonixis]

Thanks for the clarification. I've forked your repo and will try some experiments next week! If we can make it work with this runtime, this will allow us to play every OpenXR games, that's big

[monofunc]

I just tested and it works in simulator with some changes:

1. Apparently H.265 hardware encoding is not supported under Rosetta, so I added H.264
2. Server discovery wasn't working with Beat Saber for some reason, added loopback + subnet broadcast

[demonixis]

That's awesome! Feel free to submit your changes. It's good if you can test it on a Quest, but if you can't, submit on develop

[celestial-rose]

Oh wow ! I'm trying to understand the achievements made here, would that allow to bridge any OpenXR (like F1 22) Games already from Crossover to a Vision Pro ? Can I help in any way ?

[demonixis]

@celestial-rose now that @SBudarin fixed the vision pro app, I guess yes, and same for the Quest and any client supported by the runtime. But it seems that it requires a change to add h264.
@monofunc how easy it is to setup that? I can sign/notarize if needed

[SBudarin]

Would be nice to have an enum for that like VD has, and I could bring in also h.265 10bit from my test branch - helps with color banding

[demonixis]

@SBudarin we've an enum https://github.com/demonixis/oxrsys/blob/main/common/protocol/include/oxrsys/protocol/Protocol.h#L222 ;)

[demonixis]

Juste to let you know, I'm implementing the ffmpeg backend for linux/windows (we can enable it on mac too for testing) and I'm adding h264 support too. You can expect something on develop today. Also because there are some OpenGL games, I'm adding on windows and Linux OpenGL support. We can't do that for Mac I guess because there is no extension for it, juste metal and vulkan.

[monofunc]

@celestial-rose bad news for you: F1 2x doesn't use OpenXR, so that one won't work, at least for now. Maybe some other games interest you? Just make sure they actually have native OpenXR support and no anti-cheat. https://db.vronlinux.org/ with Monado/WiVRn filter is a good starting point. I wanted to test Euro Truck Simulator 2 myself later.

@demonixis it integrates with CrossOver, so it needs something like CXPatcher.