Repository navigation
chore: displayxr-common v2.6.1 -> v2.7.0, and re-sync vendored OpenXR headers - #6
Merged
Merged
Conversation
Brings this repo onto the same common tag as every other consumer, closing the last of the pin spread the weekly drift audit had been detecting since 2026-07-06 and silently failing to report (displayxr-runtime#1185). Purely additive between the two tags -- five new header-only files, +5 lines of CMakeLists, +44 of smoke test; no existing header modified or removed. Note this repo builds /MT via CMP0091 and the new headers are header-only, so the CRT-matching constraint in the comment above is unaffected. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ua8CevgSHNqoyiy7ziZjHk
…e@main The repo's own header-sync job fails on main's current state -- four headers had drifted: XR_DXR_weave (spec 6 -> 9), XR_DXR_display_info (16 -> 17), XR_DXR_view_rig and XR_DXR_spatial_workspace (comment-only). Not caused by the common bump in the parent commit. This job only runs on push/PR, the last push to main was 2026-08-10 (the commit that ADDED the check, green at the time), and the runtime has shipped three weave spec revisions since. This PR is simply the first thing to run it. Purely additive: the only removed lines across all four files are a comment, a reserved-range note, and the two SPEC_VERSION macros being replaced. No declaration is removed or changed shape, so nothing this repo compiles against moves. Note this raises the floor the runtime's consumer_floors audit derives for this repo from v2.1.0 to v2.9.0, which is correct -- the vendored header is what that floor is computed from, and it now genuinely wants a spec-9 runtime. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ua8CevgSHNqoyiy7ziZjHk
dfattal
changed the title
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.
Two drift fixes in this repo, both surfaced by the org-wide clean-up in DisplayXR/displayxr-runtime#1185.
1.
displayxr-commonv2.6.1 → v2.7.0Brings this repo onto the same tag as every other consumer, closing the pin spread the weekly drift audit had been detecting since 2026-07-06 and silently failing to report.
Purely additive between the tags — new header-only files plus a CMakeLists line and a smoke test; no existing header modified or removed. This repo selects the static MSVC runtime (
CMP0091+MultiThreaded) so the FetchContent'd common honours the CRT choice CEF forces; the added files are header-only, so that constraint is unaffected.2. Vendored OpenXR headers re-synced
The repo's own
header-syncjob failed on this PR — four headers had drifted fromdisplayxr-runtime@main:XR_DXR_weave.hXR_DXR_display_info.hXR_DXR_view_rig.hXR_DXR_spatial_workspace.hNot caused by the common bump.
header-synconly runs on push/PR; the last push tomainwas 2026-08-10 — the commit that added the check, green at the time — and the runtime has shipped three weave spec revisions since. This PR is simply the first thing to run it. Left unfixed, it would have blocked the next PR here too.Purely additive: the only removed lines across all four files are a comment, a reserved-range note, and the two
SPEC_VERSIONmacros being replaced. No declaration removed or reshaped. Verified byte-for-byte identical to runtimemainafterwards.One consequence worth recording: this raises the floor
consumer_floorsderives for this repo from v2.1.0 to v2.9.0. That's correct — the vendored header is what that floor is computed from, and it now genuinely wants a spec-9 runtime. This repo isgate: none(a reference to read, not a shipping product), so nothing enforces it at install time.Not verified
No local build. The
windowsjob passed on the common bump alone; it re-runs here over the new headers and is the real gate.