I published Quest PCVR on Apple Silicon Mac via CrossOver and Virtual Desktop / CrossOver Findings, two notes that document the same dead end from slightly different angles. One explains why Quest PCVR from macOS through CrossOver fails at the runtime/compositor layer, and the other captures the bottle-level evidence from Virtual Desktop Streamer, SteamVR, and OpenXR probing. Together they are the version I wish I had before spending more time treating this like a tweakable game-config problem.
I published Minimal OpenXR-OSX MVP: hello_xr on Quest from macOS, then turned it into a real end-to-end proof instead of leaving it as a plan. The note now covers the successful native macOS -> OpenXR-OSX -> Quest run, includes a short clip of the headset result, and explains that the runtime's built-in streaming server brought the Quest out of its blue standby screen into the actual hello_xr cubes scene before a later retest negotiated a real 90Hz path too. The visible drops and patchiness are documented with the important caveat that my wireless network environment was not tuned for this test, so I do not want to over-attribute those artifacts to the runtime alone.
I published Can CrossOver OpenXR Talk to OpenXR-OSX?, a follow-up note to the earlier Quest and Virtual Desktop dead-end notes. The useful part is that Elite reaching a Windows OpenXR runtime boundary in CrossOver does prove the app side is alive, but the bad news is that handing that off to OpenXR-OSX would need a custom Windows runtime shim, IPC bridge, and host-side adapter rather than a simple runtime switch.
Notes from testing Virtual Desktop Streamer inside CrossOver bottles, including launch failures, unstable OpenXR sessions, and why the setup still collapses even after fixing .NET.
Findings on trying to use a Meta Quest headset for PCVR from an Apple silicon Mac through CrossOver, and why the missing runtime stack is the real blocker.
Notes on whether a Windows OpenXR app running in CrossOver can be bridged into OpenXR-OSX on macOS, and why that turns into a custom proxy-runtime problem instead of a simple runtime switch.
Published Bypassing the Meta Horizon Link Drive Check in CrossOver, a write-up of the narrow binary patch that got Meta Horizon Link past its CrossOver drive eligibility check. The interesting part is that the patch did work, but only revealed the deeper problem: the installer depends on Windows service identity, driver, and runtime behavior that CrossOver does not provide cleanly.
I patched the Meta Horizon Link installer just far enough to bypass its CrossOver drive eligibility check. It got past preflight, downloaded, asked for a restart, and then revealed the real problem: nothing usable had actually installed.