Standalone player opens on the OS main display — nothing identifies which monitor the DisplayXR panel is

[dfattal]

Reported by a partner integrator (Amazon Lab126 / LeiaViewer port, internal ticket UNITY-133).

Symptom

A standalone build opens on the OS main display rather than on the DisplayXR/SR display. Setting the SR display as the Windows main display makes it launch there — i.e. the app simply follows the OS primary, with no notion of the 3D panel.

Root cause: nothing identifies which monitor the panel is

This is structural, not a small bug:

• XR_DXR_display_info (native~/displayxr_extensions.h:21, XrDisplayInfoDXR) carries displaySizeMeters, displayPixelWidth/Height, nominal viewer position and view scales — but no desktop rect, no monitor handle, no device path. The managed mirror Runtime/DisplayXRDisplayInfo.cs reflects the same fields.
• Even the transparent-overlay path never targets the panel: native~/displayxr_win32.c:1180 and :3137 call MonitorFromWindow(unity_hwnd, MONITOR_DEFAULTTONEAREST) — the overlay follows Unity's window, and is correct today only because Unity happens to be on the right monitor.

So the plugin currently cannot answer "where is the DisplayXR display on the desktop?".

Proposed fix (two parts)

1. Runtime (DisplayXR/displayxr-runtime): extend XR_DXR_display_info with the display's desktop rect and/or a stable device path (\.\DISPLAY1, or the DXGI output device name). Filed separately on that repo.
2. Plugin: once available, expose it as DisplayXRProvider.TryGetDisplayDesktopRect(...) and add an opt-in component / manifest setting that moves the player window onto that monitor at startup (SetWindowPos), before the swapchain settles.

Matching displayPixelWidth/Height against EnumDisplayMonitors is a possible interim heuristic, but it is ambiguous with two same-resolution monitors — prefer the runtime carrying the truth.

Workarounds today

• Set the SR display as the Windows main display.
• Screen.MoveMainWindowTo(Display.displays[i], …) (Unity 2021.2+) from app code.
• Launch the player with -monitor N.

[dfattal]

Runtime-side prerequisite filed: DisplayXR/displayxr-runtime#1301 — add the panel's desktop rect / device path to XR_DXR_display_info. Plugin-side window placement is blocked on that landing.

[dfattal]

PR #275 merged — DisplayXRProvider.MoveWindowToDisplay() plus the opt-in DisplayXRTargetDisplay component, built against XR_DXR_display_info v16, which the runtime already ships. So this works today rather than waiting on runtime#1301.

Deliberately leaving this open, for two reasons:

1. Not hardware-verified. I have no 3D panel and no second monitor, so the placement itself is untested. It needs a rig where the panel is not the Windows primary — the configuration where the bug actually shows.
2. The v18 gate is still to come. v16 reports the origin but cannot distinguish "the panel is genuinely here" from "no position was reported, so this resolved to the primary". runtime#1301 adds isPanelConfirmed for exactly that. Today the ambiguity degrades harmlessly (a fallback origin means the window is already there, so the move becomes a no-op), but on a two-monitor dev box with no panel — where sim_display is the automatic fallback — v16 alone could move the window to the primary for no reason. The move will be gated on isPanelConfirmed == XR_TRUE when I swap to v18.

Closing this needs a hardware pass on a panel-as-secondary rig, and the v18 swap.