Summary
The runtime's colour contract (displayxr-runtime docs/adr/ADR-021-color-management-encoding-state-invariant.md) has the runtime declare the atlas encoding and the vendor display processor adapt to it. In this plug-in only the D3D11 display processor does so: src/drv_leia/leia_display_processor_d3d11.cpp drives the weaver's sRGB conversion from ldp->atlas_encoding (see the ADR-021 comment near line 1377).
The other arms do not:
src/drv_leia/leia_display_processor_d3d12.cpp (~line 1603): "variant declares no color capability and no set_atlas_encoding (Model-A …)"src/drv_leia/leia_display_processor_gl.cpp (~line 1233): same comment- the Vulkan arms (Windows Vulkan, Linux) and Android: nothing declared
The 11 September capability audit therefore reads the colour row as done on Windows D3D11 and not yet everywhere else, and the Lenovo prep notes list "the colour contract on D3D11 only" among the plug-in's named holes.
Ask
Declare the colour capability and implement set_atlas_encoding on the D3D12, GL, Vulkan (Windows and Linux) and Android display processors, matching the D3D11 behaviour: when the runtime composes in linear, the weaver decodes and re-encodes as a matched pair; when it composes encoded, passthrough. The vendor curve, if any, stays inside the DP after the runtime hands off standard sRGB bytes (ADR-021 §2).
Why now
This is the one row of the plug-in audit that is a Leia gap on every path but one, and it decides whether colours match across a picture that mixes 2D regions, 3D regions and transparent overlays on the non-D3D11 paths.
Summary
The runtime's colour contract (displayxr-runtime
docs/adr/ADR-021-color-management-encoding-state-invariant.md) has the runtime declare the atlas encoding and the vendor display processor adapt to it. In this plug-in only the D3D11 display processor does so:src/drv_leia/leia_display_processor_d3d11.cppdrives the weaver's sRGB conversion fromldp->atlas_encoding(see the ADR-021 comment near line 1377).The other arms do not:
src/drv_leia/leia_display_processor_d3d12.cpp(~line 1603): "variant declares no color capability and no set_atlas_encoding (Model-A …)"src/drv_leia/leia_display_processor_gl.cpp(~line 1233): same commentThe 11 September capability audit therefore reads the colour row as done on Windows D3D11 and not yet everywhere else, and the Lenovo prep notes list "the colour contract on D3D11 only" among the plug-in's named holes.
Ask
Declare the colour capability and implement
set_atlas_encodingon the D3D12, GL, Vulkan (Windows and Linux) and Android display processors, matching the D3D11 behaviour: when the runtime composes in linear, the weaver decodes and re-encodes as a matched pair; when it composes encoded, passthrough. The vendor curve, if any, stays inside the DP after the runtime hands off standard sRGB bytes (ADR-021 §2).Why now
This is the one row of the plug-in audit that is a Leia gap on every path but one, and it decides whether colours match across a picture that mixes 2D regions, 3D regions and transparent overlays on the non-D3D11 paths.