feat(multi-screen): segments + per-segment views on the service / IPC path (stacked on #1878)

[dfattal]

Stacked on #1878 (feat/win-segments-under-split) — merge that first; this branch is rebased on it and its diff against main includes #1878's commits until then.

Multi-screen segments (ADR-047 D2/D3) on the service / IPC path: an _ipc client composited by displayxr-service.exe whose window straddles two monitors is woven per screen (one DP per screen, each with its own canvas rect, present origin and, with per-segment views, its own viewer), exactly as the in-process D3D11 compositor does since #1857/#1863/#1878.

Design

1. Window geometry. The app's real HWND (the XR_DXR_win32_window_binding handle the service already presents into as the APP_HWND presenter, fc->render.hwnd). The render thread reads its client area with GetClientRect + ClientToScreen in the per-monitor-DPI-aware service, which gives device px, the space the registry's monitor rects use. Both calls work cross-process and send no message. Same source as comp_d3d11_service_get_client_app_window_metrics.
2. Screens registry. It already lives in the service: the server instance's enumerate_displays (target_screens / u_screen_info, plug-in get_display_info_for_monitor), which xrEnumerateDisplaysDXR reaches over IPC today. The client sends only its session's XrSessionDisplayBindingDXR pin (compositor_segments_enable). The IPC handler enumerates the service's own screens and hands the client compositor a heap copy, plus a copy of the system info (the DP registry), as in-process set_screens does.
3. DP creation. One comp_d3d11_segments manager per client. It is the in-process manager, split into a new comp_d3d11_segs static lib (with the output composite unit it blits flat 2D through) so the service links it without the whole in-process compositor, following the comp_xbridge precedent. It is built lazily on the render thread on svc_out_device (the OUTPUT device under the Epic: weave/repaint next to scanout — output-device split for hybrid GPUs #918 split) with the same create_dp_d3d11_for_screen factory slot. The panel DP, bound to the app's HWND, is the primary and keeps drag phase-snap. Only one client's segment DPs exist at a time: a focus change releases the outgoing presenter's set. Teardown runs under render_mutex.
4. Where it weaves. Only the direct single-client pipeline (pipeline_default_policy_render) with an APP_HWND presenter. pipeline_segments_weave replaces that frame's single process_atlas. A hosted client presents into the service window on the panel. A present-owner or CLIENT_TEXTURE client weaves on its own thread. A zones frame keeps the single DP. None of these is segmented.
5. IPC metrics + routing. Two messages are appended to proto.json: compositor_get_segment_metrics (xrt_segment_metrics by value) and compositor_set_view_routing (xrt_segment_view_routing by value). Both are static_asserted to fit IPC_BUF_SIZE, and the protocol stays append-only (a test pins the three new calls at the end). The service fills each segment's eyes at query time: the primary's from the panel DP, the others' from their segment DPs. A table older than 250 ms is not handed out, so a client that lost the panel locates one view set. The client-side get_segment_metrics / set_view_routing are IPC proxies. oxr_session_locate_views then runs unchanged, with two IPC-only differences: a segment locate keeps its client-side Kooima FOVs over the device's single-set answer, and it never takes the server locate_views_rig call, which knows one view set. Routing is sent change-only from xrEndFrame. The service lays a routed commit into the client atlas as the mosaic (comp_segments_route_place, the same rect mapping the crop reads). A routed frame never zero-copies.
6. View-set capacity. On Windows a service session now counts the service's registry, from the by-value copy of xrt_system_compositor_info (the factory pointers are service addresses and are only NULL-tested). On a box with two D3D11-DP screens PRIMARY_MULTIVIEW_DXR doubles, as it does in-process.
7. Compose / shell mode: scoped out, documented as a no-op. multi_compositor_render keeps one presenter, the service window on the panel, so a workspace window is never segmented and its table stays empty. Per-screen workspace presenters are a separate decision, recorded in ADR-047 Amendment 3.
8. Byte-identical: single-screen IPC clients (capacity 1, so no enable, no per-locate fetch, no routing sends, no service-side work), any client that does not opt in, compose mode, Android and Linux (the Linux capacity branch still excludes service mode, and the new client calls are gated on a Windows-only enable).

Not yet on the service path (follow-ups)

• In a routed frame, quad, equirect and cylinder layers are drawn once per tile with that tile's camera. In-process draws them once per segment.
• A second projection layer in a routed frame is routed only where the per-tile pass visits it (segment 0).
• Hosted windows and the workspace get no per-screen presenters (see 7).

Files

• src/xrt/compositor/d3d11/CMakeLists.txt: new comp_d3d11_segs lib (no source edits to comp_d3d11_compositor.cpp / comp_d3d11_segments.*).
• src/xrt/compositor/util/comp_segments_route.h (new): routed placement and change-only publish.
• src/xrt/compositor/d3d11_service/{comp_d3d11_service.cpp,.h,CMakeLists.txt}: segment path, mosaic routing, per-client state, IPC-facing setters and getters.
• src/xrt/ipc/{shared/proto.json,server/ipc_server_handler.c,client/ipc_client_compositor.c,client/ipc_client.h}.
• src/xrt/state_trackers/oxr/{oxr_system.c,oxr_session.c,oxr_session_frame_end.c,oxr_objects.h,oxr_segment_views.h}.
• tests/tests_segments_ipc.cpp (new), tests/tests_ipc_proto.py, tests/CMakeLists.txt.
• Docs: comp-segments.md § Service / IPC path, service-architecture.md §4.3, roadmap/multi-screen.md M6, ADR-047 Amendment 3.

Testing (win box, laptop panel only — no rig run)

• scripts\build_windows.bat build: exit 0 (no new warnings).
• ctest -C Release: 101/104 pass. The 3 failures are tests_oxr_view_space_mode_{floor,pinned,floor_off}, which fail on this box independently of this change. The new tests_segments_ipc (7 cases, 81 assertions) and the extended tests_ipc_proto pass, as do tests_comp_segments and tests_oxr_segment_views.

Rig check (forced IPC, two panels: laptop at (0,0), DS1 at (3840,0))

1. Build the branch: scripts\build_windows.bat build test-apps.
2. Stop the installed service (tray → Quit) so the dev one can own the IPC pipe, then start the dev service at Medium integrity with a bat run through Explorer:

   rem run_dev_service.bat
   cd /d C:\Users\SPARKS~1\Documents\GitHub\displayxr-runtime-wt-segsvc\_package\bin
   start "" displayxr-service.exe

   explorer.exe C:\path\to\run_dev_service.bat. The service reads its own env: put any DXR_* knob, e.g. DXR_SEGMENTS=0 for an A/B, in that bat.
3. Client, from a non-elevated terminal:

   set XR_RUNTIME_JSON=C:\Users\SPARKS~1\Documents\GitHub\displayxr-runtime-wt-segsvc\_package\DisplayXR_win64.json
   set XRT_FORCE_MODE=ipc
   test_apps\handle\cube_handle_d3d11_win\build\cube_handle_d3d11_win.exe

   Drag the window across the seam.
4. Service log (%LOCALAPPDATA%\DisplayXR\DisplayXR_displayxr-service.*.log):
   • segments: IPC client 0x… (pid N) enabled segments — 2 screen(s) in the registry, pinned display 0x0000000000000000
   • segments: 2 screens, plug-in '…' — a window spanning monitors is woven per monitor (multi-screen M6, D3D11)
   • segments: IPC client 0x… (pid N) — a window spanning monitors is woven per screen by the service's direct pipeline; segment DPs on the OUTPUT device 0x… (multi-screen M6, service path)
   • segments: created a segment DP for screen 0x… ('…', plug-in '…') via create_dp_d3d11_for_screen — …
5. Client log (DisplayXR_cube_handle_d3d11_win.*.log): per-segment views: segments=2 capacity=2 active=2 reported=4 -> total=4; [0] … [1] … (WARN, once per change).
6. Eyeball: each half woven on its own panel. The DS1 half renders from its own viewer (the pinned nominal viewer on the untracked panel). Moving the window fully onto one panel returns to the single DP within ~0.5 s (hysteresis).

🤖 Generated with Claude Code