fix(cursor): halve the depth-cursor margin to 0.015 eye baselines (ADR-046 A.2)

[dfattal]

What

David's Windows Leia panel check: with the 0.03 default the depth cursor floats visibly in front of the content. This halves the default margin (ADR-046 Amendment 2 A.2) to 0.015 eye baselines, about 1 mm of crossed on-screen disparity at a 63–65 mm IPD instead of about 2 mm.

• u_cursor_depth.h: U_CURSOR_DEPTH_DEFAULT_MARGIN 0.03 → 0.015, plus comments in u_cursor_depth.{h,c}. It is the single source: the in-process runtime draw (Metal/VK/GL, and D3D11/D3D12 once feat(cursor): the runtime draws the depth cursor — D3D11 + D3D12 (ADR-046 Amendment 2 §B) #1944 lands), the zones path, feat(lift): depth-aware cursor on lifted content (ADR-046 Phase 3c) #1908's lifted-video cursor (comp_d3d11_service.cpp) and the XR_DXR_cursor_depth placement in oxr_session.c all get it from u_cursor_depth_tuning_defaults(). A tree-wide grep found no other hard-coded 0.03 cursor margin (service, u_lift_cursor, test apps, docs). The other 0.03f values in the tests are explicit per-call margins in geometry tests and stay as they are.
• XrCursorDepthOptionsDXR::margin still overrides the default. An app that wants the old look passes margin = 0.03.
• No SPEC_VERSION bump. The struct is unchanged and the margin is a default, not a contract. The spec has no rule that forces a bump, so the spec's version-history table gets a dated 6 (2026-10-11) row, and §2.4 and §3 now say 0.015. The comments in XR_DXR_cursor_depth.h are updated (they mirror to displayxr-extensions).
• ADR-046: the §3 parameter table, A.2 and "§A as built" now say 0.015, with the dated note "halved 2026-10-11 after the Windows Leia panel check: 0.03 floated visibly off the content". The original 0.03 wording is kept as history.
• Rebased on feat(cursor): the runtime draws the depth cursor — D3D11 + D3D12 (ADR-046 Amendment 2 §B) #1944 (a6df80c, D3D11/D3D12 runtime draw). The D3D paths have no local margin. Placement happens in the state tracker (oxr_session.c → u_cursor_depth_tuning_defaults()), so the D3D draws take 0.015 from the shared constant. feat(cursor): the runtime draws the depth cursor — D3D11 + D3D12 (ADR-046 Amendment 2 §B) #1944's new tests pass with 0.015.
• Log nits from the feat(cursor): the runtime draws the depth cursor — D3D11 + D3D12 (ADR-046 Amendment 2 §B) #1944 Windows run:
  • "4 views": the last commit of feat(cursor): the runtime draws the depth cursor — D3D11 + D3D12 (ADR-046 Amendment 2 §B) #1944 already capped the request to the active views in the state tracker. This PR also makes the D3D11/D3D12 one-time notice print the views actually drawn (min(request, layout tiles), the same cap the draw loop uses), as Metal (below), GL and VK do.
  • "default look mirrors the OS cursor" never logs: already fixed in feat(cursor): the runtime draws the depth cursor — D3D11 + D3D12 (ADR-046 Amendment 2 §B) #1944 as merged. comp_cursor_look_win.c makes the first mirror a process-wide one-time WARN, because INFO never reached the log file. Nothing more to change. On macOS the mirror line is already a WARN, logged once per shape change (seen in the capture run below). Linux has no mirror, so the arrow fallback logs a WARN.
• Log nit (Metal): the one-time cursor_draw: Metal compositor drawing the cursor (…, N views) line printed the locate's view count (4) for a 2-view app. It now prints the views actually drawn (n = min(view_count, tiles)), the same as the GL and Vulkan notices.

Evidence

• Unit tests (build-tests, macOS): tests_aux_cursor_depth passes 24521 assertions in 38 test cases. tests_aux_lift_cursor passes 62 assertions in 7 test cases. The default-margin test now pins U_CURSOR_DEPTH_DEFAULT_MARGIN and tuning().margin to 0.015, and it checks the behaviour too: with default tuning, content at d = −0.2 gives a target of −0.215.
• Mutant: with the default restored to 0.03, tests_aux_cursor_depth fails 1 of 38 test cases (all 3 assertions at lines 475, 476 and 481 fail).
• ./scripts/build_macos.sh passes.
• Headless capture, same session, both builds: SIM_DISPLAY_OUTPUT=sbs DISPLAYXR_CURSOR_DEPTH_UV=0.5,0.5 run_cube_handle_metal.sh, /tmp/dxr_atlas.png, a 1×2 atlas with 823 px tiles:

margin	runtime target d	arrow disparity (white-bbox left edge)	arrow disparity (mean x of white pixels)	cube bottom rail under the arrow (patch correlation)
0.03 (baseline rebuild)	−0.066	−20 px	−20.9 px	−13 px
0.015	−0.051	−16 px	−15.0 / −16.9 px (2 captures)	−10 to −12 px

Content under the cursor is d ≈ −0.036 in both runs, so the target moves exactly by the margin change. At about 317 px per baseline in this atlas that predicts a shift of about 4.8 px toward the cube, and the arrow moved about 4–5 px. The cube rotates, so its per-capture number varies by about ±1 px.

• In the same run the Metal one-time notice now reads … (default look, 8.0 mm tall, 2 view(s); …), where it said 4 views before. On macOS the "default look = the current OS cursor" mirror line logs once as expected.

Not tested

• On a real panel: the Windows Leia check that motivated this was done at 0.03. Whether 0.015 reads right needs a panel eyeball.
• D3D11/D3D12 were not run on Windows hardware. Only Windows CI (MSVC) compiles the renderer changes: the MinGW check (aux_util displayxr_mcp) passes, but it cannot build the D3D targets.
• The D3D11 service lifted-video cursor (feat(lift): depth-aware cursor on lifted content (ADR-046 Phase 3c) #1908) and the zones path were not run. They take the same constant through u_cursor_depth_tuning_defaults(), and only the build covers them.
• Vulkan and GL capture were not rerun. Their notices already reported the views drawn.

🤖 Generated with Claude Code