[dfattal]

Problem

During a resize, a present-owner keeps sending its old overlay buffer for a frame or more after the window has changed size. That buffer is still the old window's size, while the input and the woven output already have the new size. On the DS1, the browser's whole-page v4 overlay showed a black border and black 2D content on maximise and unmaximise.

Where the black margin comes from: the runtime's own post-weave blend, not the display processor. The DP offer (set_overlay_2d) only takes a layer that is exactly the output size. A mismatched layer is never offered to the DP. It falls through to the runtime's v4 overlay atlas post-weave blend (vk_local2d_composite_flatten_draw), which draws the smaller layer over the whole output as if it were window-sized.

The stage-A OPAQUE_FD path had a worse version of the problem. It imported the overlay at the window's size (have_geometry ? win_w : in_w) whatever the buffer's real size was:

• A smaller allocation failed the import, and since fix(weave/linux): an overlay that cannot be imported refuses the submit (XR_DXR_weave v16) #1825 that refused the submit.
• A larger allocation was read with the wrong memory layout.

Fix (comp_multi_weave_linux.c)

• A mismatched overlay counts as absent for that frame. It gets no DP offer, no post-weave blend and no off-panel or flat-region redraw. The content is woven normally.
• The submit is accepted, not refused. Refusing would hold frames through every resize. fix(weave/linux): an overlay that cannot be imported refuses the submit (XR_DXR_weave v16) #1825's rule is unchanged: a submit is refused only when its overlay cannot be imported.
• Logging: one WARN when the overlay goes stale and one when it matches again:

  weave: stale overlay 960x540 vs output 1280x720 — ignored until it matches
  weave: overlay 1280x720 matches the output again — composited (2 frame(s) ignored)
  

• Window size used as the reference:
  • batch submit: the input size;
  • otherwise: the bound geometry;
  • legacy single rect without geometry: rect offset + extent;
  • v6 without geometry: no reference, so the overlay is not checked. The v6 output is one content view, so it cannot serve as the reference.
• v14 "layer unchanged": after a frame whose overlay was ignored, the next overlay offered to the DP is sent with layer_unchanged = false, because the DP's cached layer is older than the ignored frames. The DP contract is already stateless per frame (no set_overlay_2d call means no layer), so an ignored frame never composites the cached layer.

What the handle path (stage A) carries

No size at all. XrWeaveSubmitOverlaysDXR has no extent field and an fd carries no dimensions. Adding a field to ipc_arg_weave_submit would not help, because the app-facing stage-A call has nothing to fill it from. So the wire is unchanged, and tests_ipc_proto and the IPC size accounting are untouched. The engine recovers the size another way:

• Identity: stage-A slots are keyed by the fd's inode, and the import cache keeps the allocation alive. An inode already imported at W1×H1 is therefore a W1×H1 buffer, because an allocation never changes size. This is exact for every buffer the engine has seen.
• Allocation size: an fd the engine has never seen that is smaller than W×H×4 bytes cannot hold a window-sized BGRA8 image in any tiling.
• Not covered: a never-seen stage-A buffer that is larger than the window cannot be detected. The spec documents this; a caller that needs that case covered uses dma-buf, whose descriptor declares the size.

The dma-buf path compares the descriptor's declared width × height and does not import a mismatched overlay at all.

Spec: XR_DXR_weave v17 (no new structure)

v16 told a caller whose overlay is its whole 2D that "accepted with an overlay chained" means "composited", and such a caller gates on that. v17 qualifies the guarantee: it holds only for a window-sized overlay. A mismatched overlay is now dropped (woven without it, still accepted). Older desktop-Linux runtimes stretch it instead. Callers need to tell those two behaviours apart, so this is a version bump rather than a silent change. The update is in the spec doc (§5d and the version history) and the header comment. The doc header's Spec Version field was stale at 13 and is now 17. The macOS, Android and D3D11 engines are unchanged.

Test

weave_probe_vk_linux now runs the resize-race case in both runs. Everything was headless on sim_display: DXR_PLUGIN_EXCLUSIVE=sim-display (active plug-in confirmed in the service log), with a private runtime-dir socket. The DS1 panel and the installed displayxr.socket were not used.

The stale overlay is opaque green everywhere, so any composite of it shows up at every probe point.

run	step	this branch	main
stage A	never-seen 960x540 under 1280x720 (allocation path)	ignored, accepted	REFUSED
stage A	then the matching 1280x720 overlay	magenta bar back	—
stage A	cached 1280x720 under 1600x900 (identity path)	ignored, accepted	—
stage A	matching 1600x900, then back to 1280x720	composited	—
dma-buf	2 frames with a declared 960x540 overlay	ignored, accepted	opaque green over the whole output (stretched)
dma-buf	then the matching overlay, declared "unchanged"	magenta bar back	—

• On this branch, both runs PASS, and the dma-buf run also passes with --linear.
• Fd counts stay flat over 600 frames (probe 20→20 and 21→21, service 25→25 and 24→24).
• The fix(weave/linux): an overlay that cannot be imported refuses the submit (XR_DXR_weave v16) #1825 unreadable-overlay refusal still refuses, and the woven output is left untouched.
• ctest -R "ipc|weave": 6/6 pass.

🤖 Generated with Claude Code

[dfattal]

Cross-session review (browser-linux): no blocking findings. Treating a size-mismatched overlay as absent for the frame (no DP offer, no post-weave blend, submit still accepted, one WARN per transition) is the right contract — it is exactly the failure the first Linux browser panel run hit (an overlay staged at the pre-resize size blended as if window-sized → black margin; see browser-pvt#238's panel-run-1 notes). The v14 reset after an ignored run is correct: the DP's cached layer predates it. The handle-path inference (first-import size kept exact; smaller allocation caught; larger undetectable) is acceptable since the browser uses dma-buf only, and the spec says so. Spec v17 bump is warranted. From the browser side: the Linux page mode in #238 already validates the overlay against the frame's window size in Viz and in the provider before sending, so it never relies on this drop; I will gate nothing on v17 but will document that an older runtime stretches a mismatched overlay.