feat(#266): move the window onto the 3D panel on Linux

[byungjul]

Part of #266 (open on the 3D panel), Linux side.

Problem

On Linux a DisplayXR app opens on the OS primary display. When the DS1 isn't the primary, the app shows up on the laptop screen in 2D, with eye tracking paused, until the user drags it onto the panel.

The runtime already knows where the panel is. On Linux it reports the panel rect through XR_DXR_display_info v18, in X root coordinates:

[DisplayXR-PROV] Display desktop rect: (3840,0 3840x2160) confirmed=1 primary=0 dev='HDMI-1' [v18]

But dxr_prov_move_window_to_display returned 0 off Windows, so DisplayXRTargetDisplay / DisplayXRProvider.MoveWindowToDisplay did nothing on Linux.

Fix

• The provider now keeps the panel extent (v18 desktopRect.extent) as well as its origin. A v16 runtime reports no extent; there the panel's native pixel size is used.
• New Linux arm of dxr_prov_move_window_to_display, with the same gating as Windows: it needs an origin and skips an unconfirmed fallback rect (confirmed=0). It calls the new displayxr_linux_move_app_window_to_rect, which:
  • centres Unity's window on the panel with _NET_MOVERESIZE_WINDOW (client origin, StaticGravity), clamped so a window larger than the panel keeps its top-left on it;
  • leaves the window alone if its centre is already on the panel, as Windows does.
• It runs on Unity's main thread, so it uses the main-thread X connection under its mutex, never s_dpy (the THREADS rule from feat(#332): Linux click-through and right-drag move for the transparent overlay #346). In transparent mode the overlay follows Unity's window, as it does for the right-drag.
• Docs: DisplayXRTargetDisplay and MoveWindowToDisplay now say Windows and Linux.

Platforms: Linux behaviour change, and only for apps that use DisplayXRTargetDisplay / MoveWindowToDisplay (opt-in). Windows and macOS are unchanged; the provider only stores one more field.

Testing

Ubuntu 26.04 (GNOME, XWayland), laptop eDP as the primary display, DS1 on HDMI-1 to its right at 200%. App: lenovo-avatar (transparent) with a small bootstrap that adds DisplayXRTargetDisplay at startup. Runtime 2.21.11, plugin = v2.21.0 + this change.

• Two launches. In both the app opened on the laptop screen and moved to the centre of the DS1 once the session was up:

  [DisplayXR-LNX] move_to_display: (1886,232) 840x1448 -> (5340,356) on the panel (3840,0 3840x2160)
  [DisplayXR] TargetDisplay: window is on the DisplayXR panel.
  

  xwininfo confirms that Unity's window and the overlay both end up at (5340,356).

• On the DS1, after the move: 3D on, tracking on, weave correct (checked by eye).

• Clicks after the move are correct (checked by hand on the DS1): the HUD slider follows the cursor, a left-drag on the avatar rotates it, and a click beside the avatar reaches the window behind. LeiaUnitySimpleSDK moves with Screen.MoveMainWindowTo because an X11 move behind Unity's back offset Input.mousePosition there. The DisplayXR pointer path reads the Input System and is not affected.

lenovo-avatar doesn't use DisplayXRTargetDisplay yet. Adding it is a separate app PR, since it also changes Windows (the window moves when the panel isn't the primary).

🤖 Generated with Claude Code

[dfattal]

Reviewed. The Linux arm mirrors the Windows gating (no origin or unconfirmed panel → no move; already on the panel → no move). It runs on the main-thread X connection under s_hit_mutex, never s_dpy, per the #346 THREADS rule, and the panel rect is in X root coordinates, the same space as Unity's window, so there's no DPI conversion. The v16 fallback to native pixel size is sensible. Thanks for verifying the input path after the move. Merging.