docs(building): note elevated-prompt ActiveRuntime trap re-triggers the ABI failure#644
Open
leaiss wants to merge 1 commit into
Open
Conversation
…he ABI failure After a correct, ABI-matched plug-in registration, running a test app from an elevated prompt still goes purple / "Failed to initialize OpenXR": the Khronos loader ignores XR_RUNTIME_JSON in an elevated process and falls back to the installed runtime via ActiveRuntime, which then ABI-rejects the freshly- registered plug-in. It reads as if the registration "only applied to one prompt" when registration is actually machine-wide and permanent — what's session-scoped is which runtime the loader picks. Add a third paragraph to the from-source DP-registration callout connecting the elevated-terminal caveat to the ABI-rejection trap, and point at the two fixes: run non-elevated (XR_RUNTIME_JSON honored) or dev-setup.bat (sets ActiveRuntime). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
leaiss
force-pushed
the
docs/from-source-dp-registration-elevated
branch
from
b8f921c to
5feb3dc
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #642.
What this adds
A from-source dev (Cyrus) followed the #642 guidance correctly —
register_dev_plugin.bat+displayxr-cli selftest→ SELF-TEST PASSED — but launchingcube_hosted_d3d11_win.batfrom a fresh elevated prompt still went purple / "Failed to initialize OpenXR". It looked like the registration "only applied to the one prompt where I ran it."It didn't. Two separate scopes were being conflated:
HKLM\Software\DisplayXR\DisplayProcessors) is machine-wide and permanent — not per-session.run_*.batsetsXR_RUNTIME_JSONto the from-source runtime, but the Khronos loader silently ignoresXR_RUNTIME_JSONin an elevated/admin process and falls back to the installed runtime viaActiveRuntime. That older runtime then ABI-rejects the freshly-registered plug-in — re-triggering the exactnegotiate returned -17failure docs(building): clarify from-source DP registration (ABI-stale plug-in case) #642 documents.This is not a runtime bug — the ABI gate, registry-only discovery, and the loader's elevated env-var refusal are all working as designed. It's a docs/ergonomics gap: the existing callout didn't connect the elevated-terminal caveat to the ABI-rejection trap.
Change
One paragraph appended to the from-source DP-registration callout in
docs/getting-started/building.md, pointing at the two fixes: run non-elevated (soXR_RUNTIME_JSONis honored), ordev-setup.batonce (setsActiveRuntimemachine-wide so any prompt works with no env var).Docs-only.
🤖 Generated with Claude Code