fix(multi/linux): route a present-owner's hardware 2D/3D request to the weave engine's DP (#1774)

[dfattal]

Fixes #1774. On desktop Linux, switching the DisplayXR browser from an inline-3D tab to a 2D tab left the panel's lens on.

Call chains

Windows (reference): browser tab policy → xrRequestDisplayModeDXR → oxr_session_request_display_mode (IPC branch) → ipc_handle_compositor_request_display_mode → compositor_request_display_mode (comp_d3d11_service.cpp) → service_apply_pending_mode (applied immediately on the IPC thread, #815) → apply_mode_transition → the DP's request_display_mode → broadcast_hardware_state (only after the DP accepts, #961).

Linux before this PR: … → ipc_handle_compositor_request_display_mode → multi_compositor_request_display_mode, which returns false when !mc->session_render.initialized. A present-owner has no window, so that condition is always true for it.

Drop point: the weave engine's DP (mc->weave.dp, created in weave_ensure_engine) is never called, and no HARDWARE_DISPLAY_STATE_CHANGE event is sent anywhere on the Linux service path.

Change

• comp_multi_compositor.c: on desktop Linux with the weave service, a client that has no per-session render is routed to the weave engine.
• comp_multi_weave_linux.c: comp_multi_weave_linux_request_display_mode applies the request immediately, under weave.mutex, the same lock order every submit uses.
  • Before the engine exists, the request is recorded and applied when the engine starts. A later 3D request withdraws a recorded 2D, so start-up applies nothing stale.
  • Event: sent once the DP accepts a change, carrying the requested state (service: panel lease — a single mode/DP owner; non-owners request or are denied with a reason; vetoed requests are dropped, not latched; mode event only after the DP confirms (#761) #961). A DP with no request_display_mode slot counts as accepted, the same rule as dp_request_display_mode_confirmed. A request for the state the panel is already in sends no event.
  • Read-back is logged, not used: the vendor lens can switch asynchronously, so get_hardware_3d_state right after the request can still show the old state.
  • DP call is timed: it runs on the IPC thread under the mutex, so a slow vendor service would stall this client's submits.
  • One WARN per transition, for example: weave(#1699): hardware 3D -> 2D (xrRequestDisplayModeDXR) on the weave engine's display processor (request_display_mode accepted) in N ms[ (slow)]; DP readback: 2D (may lag — the lens switches asynchronously). (slow) is added above 50 ms.
• sim_display Vulkan DP: SIM_DISPLAY_FAKE_LENS=1 turns on a fake lens that records each request, so a headless run can see where the request lands. It is off by default, so default behaviour does not change.
• weave_present_vk_linux --headless N --test-display-mode[=stale|deferred]: sends batches of requests and requires the matching events, in order, with each batch's events present before the next batch.
  • stale (default): 2D then 3D before the first submit (no event at start-up), then 2D, a fast 3D, 2D, 3D within one frame, a repeated 3D (must send no duplicate event), and 2D. Expected events: 2D, 3D, 2D, 3D, 2D.
  • deferred: 2D before the first submit (applied at start-up), then 3D, then 2D. Expected events: 2D, 3D, 2D.

Windows, macOS and Android are unchanged: the new branch only compiles under COMP_MULTI_HAVE_WEAVE && XRT_OS_LINUX_DESKTOP.

Verification (headless, sim_display)

The dev service ran in a private XDG_RUNTIME_DIR with DXR_PLUGIN_EXCLUSIVE=sim-display (log shows active plug-in: id=sim-display), and the client used the same env.

[weave_present] frame 0: xrRequestDisplayModeDXR(2D) -> 0
[weave_present] frame 0: xrRequestDisplayModeDXR(3D) -> 0
[weave_present] frame 20: xrRequestDisplayModeDXR(2D) -> 0
[weave_present] event: hardware display state -> 2D (frame 21)
[weave_present] frame 30: xrRequestDisplayModeDXR(3D) / (2D) / (3D) -> 0
[weave_present] event: hardware display state -> 3D (frame 31)
[weave_present] event: hardware display state -> 2D (frame 31)
[weave_present] event: hardware display state -> 3D (frame 31)
[weave_present] frame 40: xrRequestDisplayModeDXR(3D) -> 0
[weave_present] frame 50: xrRequestDisplayModeDXR(2D) -> 0
[weave_present] event: hardware display state -> 2D (frame 51)
[weave_present]   display-mode: events 2D,3D,2D,3D,2D (no stale 2D, triple, no-op) OK
[weave_present] PASS
service:
 WARN weave(#1699): hardware 2D requested before the weave engine exists — recorded, applied when the engine comes up
 WARN weave(#1699): hardware 3D requested before the weave engine exists — the recorded 2D request is withdrawn, nothing to apply at bring-up
 WARN sim_display: fake lens 3D -> 2D (request_display_mode on DP 0x…)
 WARN weave(#1699): hardware 3D -> 2D (xrRequestDisplayModeDXR) … in 0.0 ms; DP readback: 2D (may lag — the lens switches asynchronously)
 … (one fake-lens + one weave WARN per transition, 5 in total)

• stale with SIM_DISPLAY_FAKE_LENS=1: PASS.
• deferred with SIM_DISPLAY_FAKE_LENS=1: PASS.
• stale with no fake lens (the DP has no mode slot, so it counts as accepted): PASS.
• The plain --expect-anaglyph self-check passes, and fd counts stay flat.
• ctest: 73/75 pass. The two failures (tests_rig_composer, tests_oxr_view_space) also fail on an unmodified origin/main build on this box.

Not yet verified on hardware. sim_display only shows the request reaches the right DP and the events follow. A run on the Leia panel still has to confirm the lens actually drops on a 2D tab and comes back on an inline-3D tab. On the switch, the service journal should show the plug-in's lens OFF (request_display_mode(2D)) line and the new weave(#1699): hardware 3D -> 2D … in N ms WARN. The browser log should show display-mode event: panel hardware is now 2D.

Known scope limit: the event goes only to the session that asked. The Linux service has no arbiter for which session controls the panel, and the Leia lens state is shared across the whole service process, so with two present-owners the last request wins.

🤖 Generated with Claude Code

[dfattal]

Hardware check passed (pre-merge, 2026-10-02) on a Leia 3D display, GNOME 50 Wayland: this branch's hybrid build as the service + a locally built Leia Linux plug-in (real srSDK backend) + the released browser v1.0.10 pointed at it. Switching from an inline-3D tab to a 2D tab turned the lens off, and back on when returning — confirmed by eye. Service log: the plug-in's lens OFF (request_display_mode(2D)) — DisplayXR now owns this SR context's lens preference, then weave(#1699): hardware 3D -> 2D … accepted in 10.3 ms; DP readback: 3D (may lag …) and 2D -> 3D … in 10.2 ms; DP readback: 2D (may lag …) — the readback does lag, so sending the event from the accepted request is the right rule. The browser received display-mode event: panel hardware is now 2D / 3D; no weave failures. Fast back-to-back switching was not specifically stressed in this run.