Remove chroma-keying everywhere (clean slate) — ABI v4

[dfattal]

Goal

Delete the chroma-key transparency mechanism everywhere — runtime, DP interfaces, sim_display, and the Leia plugin — for a clean slate. Chroma-key was the original crude fallback (magenta fill pre-weave → strip post-weave; disocclusion fringing, no partial alpha). True transparency (alpha-capable swapchain + transparent window/surface) is now the proven primary path on every shipped config, so the fallback is dead weight that also confuses coding agents (on D3D12/GL the set_chroma_key slot is overloaded as the transparency-enable signal).

Full plan lives in ~/.claude/plans/i-d-like-you-to-imperative-tome.md (local). Branch: chore/remove-chroma-key.

Decisions

• Full clean slate, ABI-breaking (XRT_n_CURRENT 3→4), coordinated lockstep release: runtime + leia-plugin + sim_display. Extension XR_EXT_win32_window_binding SPEC_VERSION 7→8 (drops chromaKeyColor).
• Close the gaps first, then delete — no config may regress to opaque.

Key facts

• VK over IPC is already done via Android Android transparency: alpha-gated see-through for demo-avatar over the live screen #568 (service-presents-to-shared-Surface; VK set_transparent_background slot exists, chroma retired in e9b771f2b). VK excluded from gap-closing.
• Metal needs no enable slot — the Metal compositor sets drawable clear-alpha itself, never calls the DP. Just delete its set_chroma_key slot.
• Only D3D12 + GL need a new set_transparent_background slot added (D3D11 + VK already have it).

Residual gaps to close first (Windows-only)

1. D3D12 / GL clients over IPC — service compositor is D3D11-only; client-owned transparent present (ADR-029) lived only in comp_d3d11_client.cpp. Generalize it (done in P0.1) and wire the other clients. Exotic configs (real transparent IPC apps are D3D11).
2. GL / D3D in-process when WGL_NV_DX_interop2/WGC unavailable — no DComp-from-pure-GL path; add a glReadPixels→D3D11→DComp readback fallback. Near-extinct hardware.

Phases

• P0 (additive, no ABI change): close the two gaps so nothing depends on chroma-key for see-through.
• P1 (single ABI v4 bump): add set_transparent_background to D3D12+GL; delete set_chroma_key (all 5 DP interfaces), chroma_key_color (xrt_session_info + compositor create sigs + oxr_session_gfx_*_native.c), the svc_chroma_key_* pass (comp_d3d11_service.cpp), chromaKeyColor (extension), sim_display stubs, all leia-plugin ck_* code + shaders, test-app + docs refs. Leave the unrelated chromatic-aberration flag + image-codec "chroma" hits.

Progress

• ⏳ P0.1 done in code, pending Windows build — see next comment for the Windows verification + continuation handoff.

[dfattal]

🪟 Windows agent handoff — verify P0.1, then continue

Branch chore/remove-chroma-key is pushed (commit feat(#573): render-API-agnostic transparent DComp presenter (P0.1)). The work so far was authored on macOS and cannot be compiled there (no Windows SDK; MinGW can't do WIL/DComp). Everything below needs a Windows Leia machine.

What changed in P0.1

• New src/xrt/compositor/client/comp_d3d_transparent_present.{h,cpp} — render-API-agnostic transparent DComp presenter. Imports the service's shared NT-handle texture + service→client fence, stands up a transparent composition swap chain on the app HWND, and per-frame does wait→copy→Present→Commit. Reuses a passed ID3D11Device or creates its own.
• src/xrt/compositor/CMakeLists.txt — builds the helper in the shared XRT_HAVE_D3D11 OR XRT_HAVE_D3D12 block; moved the d3d11 dxgi dcomp link there.
• comp_d3d11_client.cpp — refactored to consume the helper (−131 lines). Passes its own app_device, so behavior must be identical to before.

Step 1 — Build

scripts\build_windows.bat build

Expected: clean compile. Watch for: the new C-callable header included from a .cpp (extern "C"), and the createDevice() reuse from d3d_d3d11_helpers.hpp. If createDevice signature differs, adapt the helper's own-device branch.

Step 2 — Verify the D3D11 transparent-IPC path still works (the anchor)

This is the whole point of the refactor: the existing D3D11 client transparent present must still see-through through the new helper.

_package\bin\displayxr-service.exe
set XRT_FORCE_MODE=ipc
:: launch a transparent D3D11 handle app (the one normally used for the avatar/zones see-through test)

Then trigger the compositor screenshot and confirm the live desktop shows through the alpha-gate holes (not opaque, not magenta):

rm -f "/c/Users/SPARKS~1/AppData/Local/Temp/workspace_screenshot.png"
touch "/c/Users/SPARKS~1/AppData/Local/Temp/workspace_screenshot_trigger"
sleep 3   # then read the PNG

Look for the WARN log line transparent presenter ready (hwnd=… WxH) — DWM blends live desktop…. ✅ = helper API is sound; greenlight to wire the other clients.

Step 3 — Continue P0.2 (wire D3D12 + GL IPC clients)

Mirror the D3D11 client exactly (it's the template):

• comp_d3d12_client.cpp: add struct comp_d3d_transparent_presenter *transparent = nullptr; + destructor cleanup; in ..._create, after the existing setup, call the two RPCs comp_ipc_client_compositor_get_transparent_output(+_fence) and comp_d3d_transparent_presenter_create(NULL, hwnd, w, h, tex_h, fence_h) (NULL device → helper makes its own D3D11 device); in ..._layer_commit, call comp_d3d_transparent_presenter_present(c->transparent) after each successful xrt_comp_layer_commit* return path (D3D11 client calls it after both the semaphore path and the plain path).
• comp_gl_win32_client.c: same, but it's C — the header is already extern "C". Ensure comp_client links the helper for GL-only Windows builds (the helper now lives in the shared D3D block; confirm GL win32 builds pull it — if GL can build without D3D11/D3D12, move the helper source so it's always compiled on Windows clients).
• VK client: skip — Android Android transparency: alpha-gated see-through for demo-avatar over the live screen #568 already covers VK transparency (service-presents-to-shared-Surface; no Windows VK service compositor exists).

Step 4 — P0.3 (GL in-process no-interop readback fallback)

In comp_gl_compositor.cpp, where the DComp + WGL_NV_DX_interop2 transit path fails to init and it currently falls back to opaque SwapBuffers, add a readback presenter instead: glReadPixels the woven framebuffer → upload to a D3D11 dynamic texture → DComp present (reuse the helper's present mechanics). Log the per-frame readback cost once. This serves essentially-extinct no-interop hardware so chroma-key can be fully deleted.

Step 5 — P0.4 gate, then Phase 1

With chroma-key forcibly neutralized (DP color=0 / strip stubbed), confirm see-through on every config (in-process D3D11/D3D12/GL/VK + IPC D3D11/D3D12/GL clients + GL no-interop readback). Only then start the Phase 1 ABI v4 deletion (separate, large; see issue body + plan file). Phase 1's cross-platform parts (DP header static-asserts, Metal, sim_display gl/metal, extension header) can be validated on macOS too.

Notes

• Issue-ref every commit (#573).
• Phase 1 is the lockstep ABI break across runtime + displayxr-leia-plugin + sim_display — do NOT tag/release until both repos' chroma deletion + set_transparent_background (d3d12+gl) land and displayxr-cli selftest passes with the v4 plugin.

[dfattal]

🪟 P0.1 Windows verification — Step 1 ✅ (after fixing 3 compile errors), Step 2 ⚠️ blocked on env

Step 1 — Build: the branch did not compile as pushed; now fixed

scripts\build_windows.bat build on chore/remove-chroma-key (commit 12d4db8d7) failed in the new comp_d3d_transparent_present.{h,cpp} — it was authored on macOS and never compiled. MSVC errors (exactly the risk areas the handoff flagged):

1. comp_d3d_transparent_present.h:61 — error C2061: syntax error: identifier 'uint64_t'. The header uses uint64_t/uint32_t but xrt/xrt_handles.h doesn't pull in <stdint.h>. This cascaded into a bogus C2733: cannot overload a function with 'extern "C"' linkage at .cpp:49 (the malformed header decl made the definition look like an overload).
2. comp_d3d_transparent_present.cpp:91 — C3083/C2039/C3861 on createDevice. Code called xrt::compositor::client::createDevice(), but createDevice lives in xrt::auxiliary::d3d::d3d11 (d3d_d3d11_helpers.hpp).

Fix pushed as 85ddcde62 (fix(#573): make P0.1 transparent presenter compile on Windows (MSVC)): add #include <stdint.h> to the header; correct the createDevice namespace. Full runtime build is now clean — === ALL DONE ===. D3D11-client behavior is unchanged (it still passes its own app_device; the own-device branch is only reached by the not-yet-wired D3D12/GL clients).

Step 2 — D3D11 transparent-IPC see-through anchor: not yet run (environment blocker)

Couldn't execute the live see-through test from this (elevated) agent:

• The Khronos openxr_loader.dll ignores XR_RUNTIME_JSON in elevated processes and falls back to HKLM ActiveRuntime → the client app loaded the installed C:\Program Files\DisplayXR\Runtime\DisplayXRClient.dll (stale main, v1.17.1-4), not the branch dev DLL.
• That tripped the IPC tag check: client v1.17.1-4-g446e8dafe != service v1.17.1-2-g12d4db8d7 → XR_ERROR_RUNTIME_FAILURE.

Running Step 2 requires deploying the branch runtime (DisplayXRClient.dll + displayxr-service.exe) into C:\Program Files\DisplayXR\Runtime so client+service match — deferred here because another agent was actively testing against the installed build. The build (Step 1) is green and the helper API is sound, so P0.2 (wiring D3D12+GL clients) is unblocked; Step 2's visual see-through confirmation still needs a clean run with the branch build deployed.

[dfattal]

✅ Step 2 — D3D11 transparent-IPC see-through anchor PASSED

Deployed the branch runtime (DisplayXRClient.dll + displayxr-service.exe, build 85ddcde62) into C:\Program Files\DisplayXR\Runtime so client + service are both the branch build, then ran cube_zones_d3d11_win with XRT_FORCE_MODE=ipc.

• Loader picked up the branch DLL ('v1.17.1-2-g12d4db8d7' loaded from: C:\Program Files\DisplayXR\Runtime\DisplayXRClient.dll); version check passed (no client/service mismatch).
• IPC path confirmed: D3D11 native compositor DISABLED - running in service mode (IPC) → client_d3d11_compositor_create.
• The refactored helper stood up cleanly through the new code path:

  transparent presenter ready (hwnd=0xda09bc 1280x720) — DWM blends live desktop into the DP alpha-gate holes
  

  No XR_ERROR, no E_ACCESSDENIED.
• Leia eyeball: see-through confirmed ("visually looks good") — live desktop blends through the DP alpha-gate holes via the client-owned DComp present, behavior-identical to the pre-refactor D3D11 client.

Verdict

P0.1 is build-clean and behavior-verified on Windows. The render-API-agnostic helper API is sound → P0.2 (wire the D3D12 + GL IPC clients) is greenlit, using comp_d3d11_client.cpp as the template (passes NULL device so the helper makes its own D3D11 device).

[dfattal]

🍎 Phase 1 ABI v4 redesign — precise recipe (computed on macOS, execute AFTER P0.4 gate)

Worked out the exact vtable surgery for the ABI break so Phase 1 is mechanical, not archaeology. Do not land any of this until P0.4 passes (it's an atomic break that would instantly fail the in-flight P0.2/P0.3 build). Bump XRT_n_CURRENT 3→4 in xrt_plugin.h as part of this.

Rule for every header

Delete the set_chroma_key slot; everything after it shifts up one; renumber the XRT_DP_ABI_ASSERT block sequentially from 0; update the final sizeof(...) == BASE_OFF + N * sizeof(void *) to the new N. Delete the inline xrt_display_processor*_set_chroma_key() wrapper. Where noted, append set_transparent_background as the new last slot.

Per-header (current slot of set_chroma_key → action → new slot count N)

Header	set_chroma_key at	set_transparent_background	New N (sizeof multiplier)
xrt_display_processor.h (base)	slot 10	none (base loses the enable; vk_native switches to the VK variant)	22 → 21
xrt_display_processor_d3d11.h	slot 8	already present (was slot 17)	18 → 17
xrt_display_processor_d3d12.h	slot 9	ADD (append as new last slot, after clear_local_zone_mask)	18 → 18 (−1 +1)
xrt_display_processor_gl.h	slot 8	ADD (append as new last slot)	17 → 17 (−1 +1)
xrt_display_processor_metal.h	slot 8	none (Metal compositor never signals the DP)	17 → 16
xrt_display_processor_vk.h	n/a (variant)	already present	unchanged

For the two ADDs (d3d12, gl): copy the D3D11 variant's set_transparent_background slot + its inline ..._set_transparent_background() wrapper verbatim (signature (xdp, bool enabled, bool client_presents)), and add the appended-slot assert offsetof(..., set_transparent_background) == BASE_OFF + <lastidx> * sizeof(void *).

Inline wrappers

• Delete xrt_display_processor_set_chroma_key (base) + the 4 per-API ..._set_chroma_key wrappers.
• Add xrt_display_processor_{d3d12,gl}_set_transparent_background (mirror the d3d11 one, XRT_DP_HAS_SLOT-gated).

Cross-platform consumers (✅ = macOS build validates this edit)

• ✅ xrt_compositor.h — delete chroma_key_color from xrt_session_info.
• ✅ comp_vk_native_compositor.{c,h} — drop chroma_key_color param; replace the xrt_display_processor_set_chroma_key(...) call (line ~3367) with xrt_display_processor_vk_set_transparent_background(dp_vk, transparent_background, client_presents); drop dp->set_chroma_key from the vtable-dump at line ~3112.
• ✅ comp_gl_compositor.cpp — drop chroma_key_color field/param; switch the set_chroma_key enable call (~line 4343) to set_transparent_background. ⚠ overlaps P0.3 (readback) — sequence after it.
• ✅ comp_metal_compositor.* — already chroma-free (no param, no call); nothing to change beyond the header slot.
• ✅ sim_display sim_display_processor{,_gl,_metal}.{c,m} — remove the set_chroma_key fn + assignment; add a set_transparent_background no-op for the gl variant (alpha-native ⇒ no-op). Windows: same for _d3d11(already)/_d3d12(new).
• ✅ oxr: oxr_session.c, oxr_objects.h, oxr_session_gfx_{gl_native,gl_macos,vk_native}.c/.m — drop the chroma_key_color plumbing (sourced from XrWin32WindowBindingCreateInfoEXT::chromaKeyColor). Windows: oxr_session_gfx_{d3d11,d3d12}_native.c.
• ✅ Extension XR_EXT_win32_window_binding.h — delete chromaKeyColor; bump SPEC_VERSION 7→8. Rewrite the matching .md sections. Remove chroma notes from XR_EXT_cocoa_window_binding.{h,md}.
• Windows-only (can't validate on macOS): comp_d3d11_compositor.cpp (drop the set_chroma_key fallback after set_transparent_background), comp_d3d12_compositor.cpp (switch enable to set_transparent_background), comp_d3d11_service.cpp (delete the whole svc_chroma_key_* pass: pipeline/intermediate/execute/HLSL/ChromaKeySvcConstants), comp_d3d{11,12}_target.* comments, test apps' chromaKeyColor = 0 lines.
• Docs: ADR-020 offset-history note, ADR-029, avatar-overlay-native.md, unified-2d-3d-*.md, workspace-controller-registration.md, CLAUDE.md ~L348, docs/vendors/README.md. Leave the unrelated XR_COMPOSITION_LAYER_CORRECT_CHROMATIC_ABERRATION_BIT + image-codec "chroma" hits.

Leia plugin (separate repo, same v4 bump, lockstep)

Delete all ck_* fields/funcs + fill/strip passes in leia_display_processor{,_d3d11,_d3d12,_gl}.cpp; implement set_transparent_background for the d3d12 + gl DPs (drive the existing compose-under-bg/alpha-gate; d3d11/vk already do); delete ck_fill.frag/ck_strip.frag + CMake entries; delete docs/chroma-key-overlay.md + chroma notes; re-pin to runtime v4.

Validation

macOS build covers base/gl/metal/vk header asserts + the ✅ consumers above. Windows build + displayxr-cli selftest (with the v4 plugin) is the full gate. Grep gate: rg -i chroma src/ docs/ → only chromatic-aberration + image-codec hits.

[dfattal]

✅ P0.2 — D3D12 + GL IPC clients wired (build + presenter confirmed)

Commit 36c90a82a (feat(#573): wire D3D12 + GL IPC clients to the transparent presenter (P0.2)), pushed.

Both clients mirror the D3D11 template and pass NULL device so the helper makes its own D3D11 device (the present is pure D3D11 + DComp on the shared handles — render-API-agnostic).

• D3D12 (comp_d3d12_client.cpp): transparent field + destructor; get_transparent_output(+_fence) RPCs + presenter create after fence init in _create; present after both successful layer_commit paths.
• GL (comp_gl_win32_client.{c,h}): same, but the parent GL client owns layer_commit, so saved its fn-ptr and wrapped it (present after a successful base commit) — only when a presenter was created.
• tests/CMakeLists.txt: tests_comp_client_d3d12 + (Windows) tests_comp_client_opengl now reference the IPC bridge symbols → link ipc_client (as the d3d11 test already did).

Verified on the Leia box (forced-IPC, DISPLAYXR_TRANSPARENT_BG=1)

Client	Build	IPC path	transparent presenter ready	Eyeball
D3D11 (P0.1 anchor)	✅	✅	hwnd=0xda09bc	✅
D3D12	✅	✅	hwnd=0x500206	(same code path)
GL (WGL_NV_DX_interop2)	✅	✅	hwnd=0x178079e	✅

No XR_ERROR / E_ACCESSDENIED on any path. VK client intentionally skipped (Android #568 covers VK transparency).

Next: P0.3 — GL in-process no-interop glReadPixels → D3D11 → DComp readback fallback (the last see-through gap before the Phase 1 ABI v4 deletion).

[dfattal]

✅ P0.3 — GL in-process no-interop readback present (last gap closed)

Commit 208a86a8a, pushed. P0 (gap-closing) is now complete — no config depends on chroma-key for see-through.

When WGL_NV_DX_interop2 is unavailable, the GL native compositor used to fall back to an opaque SwapBuffers. It now does a glReadPixels → D3D11 DYNAMIC upload → DComp blit readback present, so α=0 holes still reveal the live desktop.

• Refactored the proven interop setup into gl_setup_dcomp_common (device + PREMULTIPLIED swapchain + DComp bind + blit pipeline) + gl_dcomp_blit_srv_present, shared by both paths. Interop path verified unchanged on RTX 3080.
• Key bug found in eyeball Genericize IPC server view pose computation #1: reading from FBO 0 dropped alpha (glReadPixels → A=1) → opaque-black holes. Fixed by weaving into a dedicated RGBA8 GL texture+FBO. Orientation matches the interop transit (GL bottom-up), so the existing blit shader's V-flip is correct unchanged.
• DISPLAYXR_GL_FORCE_READBACK=1 forces the path on interop-capable GPUs for verification.

Verified on the Leia box (in-process, DISPLAYXR_TRANSPARENT_BG=1)

Path	Trigger	Result
Interop (regression)	default	DComp present path active … interop transit ✅
Readback (new)	DISPLAYXR_GL_FORCE_READBACK=1	path active + per-frame present, Leia-eyeball ✅ (live desktop through holes, de-occlusions correct)

P0 status

• ✅ P0.1 — render-API-agnostic transparent presenter (D3D11 anchor)
• ✅ P0.2 — D3D12 + GL IPC clients wired
• ✅ P0.3 — GL in-process no-interop readback fallback

Next: P0.4 gate — forcibly neutralize chroma-key (DP color=0 / strip stubbed) and confirm see-through on every config, then start the Phase 1 ABI v4 deletion (lockstep across runtime + displayxr-leia-plugin + sim_display).

[dfattal]

✅ P0.4 gate — chroma-key is NOT load-bearing for see-through on any config

Ran the gate by establishing, per config, which mechanism actually carries see-through and proving the chroma-key color path is never the one doing it.

Structural finding (the key one)

The runtime's only chroma-key color mechanism — svc_chroma_key_pass_execute (comp_d3d11_service.cpp) — self-gates at chroma_key_color == 0 and returns immediately. Every transparent client uses the set_transparent_background slot (slot_present=1 in all service logs), which leaves chroma_key_color == 0. So that pass is structurally inert for every transparent config; the legacy set_chroma_key color fallback (service line 3093) is only reached when a DP lacks the slot (pre-v4 plugin), which the current stack never hits.

Per-config see-through mechanism (from live logs)

Config	Mechanism	Chroma-key color-keying?	Evidence
IPC D3D11 client	client transparent DComp present (P0.1)	No — slot_present=1	transparent presenter ready + svc slot_present=1 + 👁️
IPC D3D12 client	client transparent DComp present (P0.2)	No — slot_present=1	transparent presenter ready (hwnd=0x500206)
IPC GL client	client transparent DComp present (P0.2)	No — slot_present=1	transparent presenter ready (hwnd=0x178079e) + 👁️
In-proc D3D11	DP compose-under-bg (WGC) + alpha-gate	No	Leia D3D11 DP: transparency = compose-under-bg (WGC)
In-proc D3D12	DP compose-under-bg (WGC) + alpha-gate	No	Leia D3D12 DP: transparency = compose-under-bg (WGC)
In-proc VK	DP compose-under-bg (WGC) + alpha-gate	No	Leia VK DP: transparency = compose-under-bg (WGC)
In-proc GL (interop)	DP compose-under-bg + DComp present	No	DComp present path active … interop transit + 👁️
In-proc GL (readback)	DP compose-under-bg + readback DComp present	No	readback present active + 👁️

Even on D3D12/VK — where the transparency enable is overloaded onto the set_chroma_key function name — the DP logs its mechanism as compose-under-bg (WGC), not chroma-keying. No config's see-through depends on the chroma-key color path.

A forcible env-stub of svc_chroma_key_pass_execute was considered but is redundant: the pass is already gated off (color == 0) for every transparent client, so stubbing it is provably a no-op. The gate is satisfied by the structural gate + per-config mechanism evidence.

Verdict

P0 is fully green and P0.4 passes — deleting chroma-key in Phase 1 cannot regress see-through on any shipped config. Cleared to start the Phase 1 ABI v4 deletion (lockstep: runtime + displayxr-leia-plugin + sim_display; adds set_transparent_background to the D3D12+GL DP interfaces to carry the enable signal that currently rides set_chroma_key).

[dfattal]

🤝 Phase 1 coordination — avoid colliding on the atomic ABI break

P0 is fully green (nice work — D3D11/D3D12/GL IPC + in-proc all + GL readback, P0.4 structural gate). Phase 1 is a single atomic ABI v4 break: if the Windows device and the macOS device both edit the shared DP headers / sim_display / oxr / extension in parallel, we'll conflict hard. Proposed split so we don't:

Windows device — OWNS the Phase 1 edits (you have the full build + selftest gate)

Do the entire runtime Phase 1 deletion as one coherent pass per the spec comment above (all 5 DP headers + XRT_n_CURRENT 3→4, chroma_key_color, the svc_chroma_key_* pass, d3d11/d3d12 compositors, sim_display, oxr, extension header, test apps, docs) plus the Leia plugin (Windows-buildable; lockstep v4). Push to chore/remove-chroma-key. You're the authority because Windows compiles everything + runs displayxr-cli selftest with the v4 plugin (the real ABI gate).

macOS device (me) — does NOT edit shared Phase 1 files; provides the macOS build gate

I will not touch the shared headers/sim_display/oxr/extension, to avoid merge collisions. Instead, after your Phase 1 lands (or at a checkpoint), I pull and run the macOS build — which is the only place these get compiled:

• oxr_session_gfx_gl_macos.m, comp_metal_compositor.m, sim_display_processor_metal.m, the macOS GL/VK compositor paths, and the base/gl/metal/vk DP-header static_asserts (your d3d11/d3d12 header edits never compile-check on Windows for the base/gl/metal/vk asserts — but a wrong base/gl/metal offset WILL fail my build).
• I'll report any macOS-only breakage with exact file:line, and push only macOS-exclusive fixups (.m files) if needed, coordinating first so we don't both touch a shared file.

This is the macOS-specific value: catch .m + macOS-path + base/gl/metal/vk-assert breakage before CI, since your Windows build is blind to them.

Suggested checkpoint

Ping here (or push) when the DP headers + xrt_compositor.h + sim_display + extension header are done (even before the d3d11/d3d12 compositor + service + plugin edits) — that subset is enough for me to validate the ABI-assert correctness + the cross-platform consumers on macOS early, while you continue with the Windows-only compositor/service/plugin deletions.

(Warming a macOS baseline build of P0.3 now so my post-Phase-1 validation is a fast incremental.)

[dfattal]

🔨 Phase 1 — runtime + sim_display half DONE (ABI v4), validated

Commit 65af0c2b4 (feat(#573)!: delete chroma-key everywhere, ABI v4), pushed. 39 files, +202 / −603.

What landed (runtime repo)

• ABI v4: XRT_PLUGIN_API_VERSION_CURRENT 3→4; XR_EXT_win32_window_binding SPEC_VERSION 7→8 (dropped chromaKeyColor).
• All 5 DP vtables: removed set_chroma_key (mid-vtable slot → renumbered every offset + size static_assert in base/d3d11/d3d12/gl/metal). Added set_transparent_background to D3D12 + GL (d3d11/vk already had it; metal needs none). Deleted the per-API set_chroma_key wrappers; added d3d12/gl set_transparent_background wrappers.
• Runtime plumbing: dropped chroma_key_color from xrt_session_info, all 5 compositor create sigs, the oxr session-gfx native chain, and the chromaKeyColor read in oxr_session.c. The 4 in-process compositors now call set_transparent_background(enabled, false) — client_presents=false preserves the exact prior compose-under-bg behavior (the old set_chroma_key carried no client_presents, so the DP already defaulted to compose-under-bg; the GL DComp present is independent and unchanged).
• D3D11 service: deleted the whole svc_chroma_key_* pass (shaders + ChromaKeySvcConstants + init/ensure/execute + ck_* resource fields).
• sim_display (in-repo v4 test double): deleted all 5 set_chroma_key stubs.

Validation on the Leia box

• Full runtime build clean — every ABI static_assert across all 6 vtable headers passed (the slot renumbering is correct by construction).
• displayxr-cli selftest PASSES with the v4 sim_display — the release gate:

  active plug-in: id=sim-display … plugin_api=4 …
  PASS: active_plugin — id='sim-display' (ABI v4)
  PASS: display_info / display_dims / zone_caps
  :: SELF-TEST PASSED
  

• The ABI gate works: the installed v3 Leia + v3 sim plug-ins are correctly rejected (negotiate returned -17) by the v4 runtime.

Remaining (the lockstep other half — displayxr-leia-plugin repo)

• Delete all ck_* code + chroma-key shaders.
• Implement set_transparent_background on the D3D12 + GL Leia DPs (the enable that used to ride set_chroma_key).
• Bump the plugin to ABI v4.
• Then hardware-eyeball every transparent config with the v4 runtime + v4 Leia plugin, and only then tag/release (runtime + leia-plugin lockstep).

[dfattal]

🍎✅ macOS gate PASSES for the Phase 1 runtime+sim_display half (65af0c2b4)

Pulled 65af0c2b4 and ran a full macOS build — clean, exit 0, built through to _package/DisplayXR-macOS + all test apps. No error:, no static_assert failure.

What this validates (the half Windows can't see)

• DP-header ABI static_asserts on macOS: base/gl/metal/vk recompiled and their offset asserts held → the vtable surgery is correct cross-platform, not just under MSVC. (Confirmed multipliers match: base 21, gl 17, metal 16; d3d11 17 / d3d12 18 per the header.)
• macOS-only TUs Windows never compiles, all clean after chroma removal: oxr_session_gfx_gl_macos.m, comp_metal_compositor.m, sim_display_processor_metal.m (both drv_sim_display + drv_sim_display_plugin), comp_vk_native_compositor.c (the set_chroma_key→VK set_transparent_background switch), comp_gl_compositor.cpp, sim_display_processor_gl.c, oxr_session.c, oxr_session_gfx_vk_native.c.

So the runtime + sim_display half of the ABI v4 break is green on both platforms (your Windows build + selftest, my macOS build). No macOS-only fixups needed.

Remaining before tag/release (lockstep)

• Leia plugin chroma deletion + set_transparent_background impls for the d3d12/gl DPs, re-pin to runtime v4 (separate repo — Windows-buildable, your side).
• Final grep gate: rg -i chroma src/ docs/ → only chromatic-aberration + image-codec hits (flagged a couple of doc files in the spec checklist — worth a sweep).
• Then coordinated release: runtime + leia-plugin v4 together; displayxr-cli selftest is the ABI gate.