steam-frame/daniel-lynch--ovrplugin-openxr-shim

0 Fork 0

mirror of https://github.com/daniel-lynch/ovrplugin-openxr-shim.git synced 2026-10-06 00:00:06 +02:00

Files

T

Daniel LynchandClaude Opus 4.8 a72a79ad29 Initial public release: OVRPlugin→OpenXR interoperability shim

An independent reimplementation of Meta's libOVRPlugin ABI on top of OpenXR, so
VrApi-era Meta Quest VR titles can run on non-Meta OpenXR runtimes (Monado,
Steam Frame) instead of being locked to Meta hardware. Original code only — no
Meta/Epic/Capcom binaries, headers, or assets. Includes a desktop harness that
drives the shim against Monado headless.

Scope/legal: interoperability; entitlement handling is out of scope. See README
for the legal/scope section and docs/ for the research trail and design notes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D6sFYGXZPsq3v7xtcDES6g

2026-06-29 00:48:48 -04:00

2.8 KiB

Raw Blame History

Target host platform — Steam Frame

Researched 2026-06-23. Answers "can the dumped APK run on Steam Frame, and do we need Android given SteamOS is Linux?"

Do we need the Android side? YES.

The game is an Android binary, not a Linux one — ARM64==ARM64 does NOT bridge:

libUE4.so links bionic libc (ABI-incompatible with SteamOS glibc).
Depends on Android system libs: liblog, libandroid (ANativeActivity, AAssetManager, input), libOpenSLES; boots via a Java/JNI NativeActivity.
Reads OBB assets via Android AssetManager/storage paths. => Cannot run the .so bare on SteamOS. Must run inside an Android runtime. Only Android-free path = full native source recompile (no source -> not viable).

The host pieces all exist (and are open)

Lepton = Valve's official Android-on-Linux layer; a Waydroid/AOSP fork built specifically to run Quest APKs on Steam Frame, with sideloading. APKs run native ARM64, no emulation (the "Waydroid needs x86" caveat is about Waydroid on x86 PCs; Frame is ARM so it doesn't apply). Walkabout Mini Golf (Quest title) already cited running on it.
Monado = open OpenXR runtime, runs on Linux AND Android, Vulkan compositor using VK_KHR_external_memory_fd / external_semaphore_fd (matches our Vulkan-renderer finding).

Architecture

Steam Frame (SteamOS / Arch Linux, ARM64)
└─ Lepton (AOSP/Waydroid container, native ARM64)
    └─ RE4 VR APK (unmodified bionic Android binary)
        ├─ libUE4.so → [SHIM libOVRPlugin] → OpenXR → Monado → Frame compositor (Vulkan)
        └─ ovr_* Platform SDK → out of scope (no entitlement code ships in this repo —
           a valid entitlement is the user's responsibility; see README "Legal / scope")

Why the shim IS the project

Meta ended VrApi support 2022-08-31; OpenXR is the only supported Quest API and Valve's whole stack is OpenXR (Monado). So:

OpenXR Quest games -> Lepton+Monado likely run them with little/no work.
VrApi games (RE4 VR) -> won't: Lepton/AOSP will never ship Meta's proprietary libvrapi.so, so the unmodified game finds no VR runtime. The OVRPlugin->OpenXR shim is exactly what bridges a dead-API VrApi game to Frame's OpenXR stack.

Remaining real unknowns (gated on Frame shipping ~summer 2026)

Does Lepton expose an OpenXR loader+runtime to apps INSIDE the container? (Almost certainly yes for the OpenXR-Quest-game use case; ride on it.)
Can a SIDELOADED app reach the runtime + compositor (perms across the Waydroid boundary)?
Likely the real technical crux: sharing Vulkan swapchain images from inside the Lepton container out to the host Monado/Frame compositor (VK_KHR_external_memory_fd across the container GPU boundary). May be moot if Monado's compositor runs inside the container.

2.8 KiB Raw Blame History