V-key 2D toggle: cube shifts left + right eye goes black

[dfattal]

Summary

Pressing V (the 2D/3D toggle) makes the rendered content shift laterally to the left and the right eye goes black — the panel ends up showing a single, laterally-offset view instead of a clean 2D (averaged/centre) image.

Pre-existing — NOT a #573 regression

Confirmed present in the released v3 stack (runtime v1.17.1 + Leia v1.7.1), so it is independent of the #573 chroma-key removal / ABI-v4 work. Surfaced while validating the v4 stack; filing standalone so #573 can close on its own scope.

Suspected root cause

This is the #542 family — "the atlas recipe (grid/dims) must follow the active MODE, not the submitted view_count/imageRect." See the recurring note that xrLocateViews always returns the MAX view count and zone rects are zone-sized, so deriving the atlas grid from submitted views yields a 2D left-shift.

On the V-key 2D toggle, the atlas grid/dimensions for the content path should clamp to the active mode (2D = single centred view), but something downstream still derives a 2-view / offset layout — producing the left-shift and the dead right eye.

Likely areas to inspect:

• The 2D-mode atlas recipe vs. the submitted view layout (clamp submission to mode; a divergence should only ever come from a hardware override).
• Eye-position handling in 2D mode (the DP averages L/R to a midpoint — confirm the content/atlas side agrees and a single centred tile is sampled, not the left tile).

Repro

1. Launch any 3D cube app on the Leia display (e.g. cube_handle_*, or the zones app).
2. Confirm correct 3D.
3. Press V to toggle to 2D.
4. Observe: content shifts left; right eye black.

Related

• Decouple hardware 2D/3D from content tile-count across all native compositors (D3D11/D3D12/GL/Metal/VK-native) #542 (decouple hardware vs content; "atlas recipe = MODE")
• ADR-028

[dfattal]

Additional observation — shell (Ctrl+V) reproduces it, and it's per-APP not per-API

Pressing Ctrl+V (2D toggle) in the shell shows the same left-shift, but only on some apps:

App	Graphics API	Shifts left on 2D toggle?
cube_handle_d3d11_win	D3D11	Yes
cube_handle_vk_win	Vulkan	Yes
cube_handle_d3d12_win	D3D12	No
modelviewer (demo)	Vulkan	No

The decisive clue: the VK cube shifts but the VK modelviewer does not — same graphics API, same runtime VK compositor path, different result. So this is app-side render/submit behavior in 2D mode, not the runtime compositor or a per-API issue. (Consistent with this being pre-existing in released v3 — not a #573 regression.)

What the code review found (and didn't)

• It is not the EndFrame submit-count: D3D11 submits a consistent eyeCount=1 in mono yet shifts, while D3D12 and VK use identical submitViewCount logic yet differ. So the count argument isn't the discriminator.
• In the three cube test apps the mono render path looks structurally identical: tileX = monoMode ? 0, vpX = tileX*renderW = 0, single view submitted at imageRect offset (0,0). Static reading does not reveal why D3D11/VK shift but D3D12 doesn't — the divergence must be in a runtime-observable detail (renderW / swapchain width / imageRect extent / monoPose+monoFov), so it needs an atlas-capture diff (3D vs 2D, D3D11-that-shifts vs D3D12-that-doesn't) to pin the actual pixel difference.

Next step

Capture the projection-only atlas on the 2D toggle for a shifting app (D3D11) vs a clean one (D3D12) and diff — that should expose whether the single 2D view lands in the left tile vs centered, and which input (offset/extent/pose/fov) drives it.

(This is the #542 "atlas recipe = MODE" family; the per-app divergence here suggests one or two of the cube test apps' mono submission/render is slightly off vs the D3D12 reference, rather than a single runtime fix.)

[dfattal]

Complete per-app table (user-verified on the live display)

App	Graphics API	Shifts left on 2D (V/Ctrl+V) toggle?
cube_handle_d3d11_win	D3D11	Yes
cube_handle_vk_win	Vulkan	Yes
cube_handle_d3d12_win	D3D12	No
cube_handle_gl_win	OpenGL	No (GL switches 2D cleanly, no shift)
modelviewer (demo)	Vulkan	No

So the shifters are D3D11 + VK cube; the clean ones are D3D12 + GL cube + VK modelviewer. Per-app (the VK cube shifts but the VK modelviewer + GL cube don't), so it's app-side mono-render/submit, not the runtime compositor or a per-API issue. Pre-existing (present in released v3).

Starting point for the fix session

1. Repro on a clean installed stack (lesson from OpenGL cube app does not render in shell since #573 transparency changes #578 — don't trust hand-deployed binaries). Box is currently on clean v1.18.0 + v1.8.0.
2. Atlas-capture (%TEMP%\workspace_screenshot_trigger) a D3D11 cube (shifts) vs D3D12 cube (clean) at 3D and right after the V→2D toggle; diff to see exactly where the single 2D view lands (left tile vs centered).
3. The cube apps' mono path looked structurally identical in static reading (tileX = monoMode ? 0, vpX=0, single view at imageRect offset 0) — so the divergence is a runtime-observable detail (renderW / swapchain width / imageRect extent / monoPose+monoFov). The capture diff should expose which.
4. Family: Decouple hardware 2D/3D from content tile-count across all native compositors (D3D11/D3D12/GL/Metal/VK-native) #542 "atlas recipe = MODE" (see also the recurring feedback_atlas_recipe_is_the_mode note). Likely fix is in one/two cube test apps' mono submission/render vs the D3D12+GL reference, not a single runtime change.

[dfattal]

Validated on Metal (macOS) + Android — closing #575

PR #580 was hardware-validated on D3D11 / VK / D3D12 / GL (Windows). This pass covers the two remaining platforms. Both green; #575 fix now confirmed across all five graphics APIs + Android + Metal.

Metal — cube_handle_metal_macos, in-process, sim_display (DisplayXR runtime @ current main)

Cell	Result
(a) 2D centered, no left-shift	✅ 2D atlas = single full-window view, cube centered. HUD reports Eye[0]=(0.000, 0.100, 0.600) — the 2D view originates from the center eye (x=0.000), vs ±0.030 in 3D. No left-shift, no black half.
(b) ADR-030 crop / zero-copy	✅ Atlas dumps are content-sized: 3D = 3024×823 (2×1512×823), 2D = 3024×1646 — not the 3024×1964 worst-case swapchain → crop path. Windowed app (content < swapchain) → zero-copy ineligible, as ADR-030 requires.
(c) demote / re-promote	Clean mode transitions both directions (3D↔2D over the V cycle; hardware_display_3d toggles true↔false). Auto-demote-on-eye-tracking-loss is N/A on the macOS sim in-process path (no eye-tracking HW; sim honestly advertises none; the app's eye-tracking event handler only updates state, and there is no runtime auto-demote — that's a vendor/Leia policy). The correctness criterion a demote depends on — a 2D drop landing centered — is exactly what (a) proves.
workspace V-key reject	N/A — shell is Windows-only.

Also applied the identical app-side fix from PR #580 (mono extent = window × view_scale) to cube_handle_metal_macos so it matches the four validated Windows apps. It's a behavioral no-op on sim_display (2D mode scale = 1.0×1.0) but keeps the recipe consistent.

Android — cube_handle_vk_android, out-of-process (service), Leia CNSDK DP, NP02J (Lume Pad)

Regression pass — PR #580's runtime changes are gated to the Windows D3D11 service; the Android center-eye collapse already lived in ipc_try_get_android_view_poses (#521). Confirmed unchanged and correct:

Cell	Result
(a) 2D centered	✅ Decisive pose/fov evidence from HW_DBG_APP: 3D → views[0]: pos=(-0.053, …) fov=(L=-0.168 R=0.291) (left eye, off-axis asymmetric frustum). 2D → views[0]: pos=(0.000, …) fov=(L=-0.231 R=0.231) (center eye, symmetric fov). Both pose and fov collapse to the center eye — exactly the #575 fix (the bug paired a center pose with a left-eye asymmetric fov).
(b) V toggles 2D/3D over IPC	✅ CONTENT rendering mode 0 arrived over IPC (grid 1x1) → Rendering mode changed 1 → 0 → app submits 1 view; reverse mode 1 arrived over IPC (grid 2x1) → 0 → 1 → 2 views. Single-app OOP, app owns the mode (#518).
(c) zero-copy never engages	✅ App swapchain = 3840×2560 (worst-case across orientations, #518); 2D atlas = 1600×2560, 3D atlas = 2400×1920. Swapchain ≠ either mode's atlas → u_tiling_can_zero_copy() false in both modes → always crops, exactly the ADR-030 Android consequence.

(Android visual is inferred from the runtime's computed pose/fov rather than a screenshot — screencap cannot see the Vulkan overlay. The pose/fov data proves the center-eye collapse at the source.)