Summary
A RDP client connecting with /multimon (multi-entry MonitorDefArray) into a RemoteApp (RAIL) session that rdprrap has multi-session-enabled → input stops registering entirely (the window paints, but mouse/keyboard are dead). A single wide monitor (/span, one MonitorDefArray entry) works fine.
This blocks true per-monitor multi-monitor downstream in winpodx (kernalix7/winpodx#544): under /span Windows sees one wide monitor, so apps maximize across both physical displays. /multimon would fix it but currently kills input under rdprrap.
Repro
- Windows 11 client SKU, rdprrap multi-session enabled (
MaxInstanceCount>1, fSingleSessionPerUser=0).
- Launch a RemoteApp via FreeRDP with
/app:... /multimon from a host with ≥2 same-scale monitors.
- Window renders; clicks/keys do nothing. Swap
/multimon → /span: input works.
Suspected cause
The multi-session RAIL / input-routing path likely assumes a single monitor — it drops the extra TS_MONITOR_DEF entries, or computes the input virtual-desktop rectangle from single-monitor geometry, so pointer coordinates fall outside the routed region and input is discarded. Fix direction: parse + honor the full MonitorDefArray (primary flag + per-monitor rects) in the multi-session RAIL window/input mapping.
Acceptance
- A RAIL app launched with
/multimon into a multi-session-enabled guest keeps mouse + keyboard working across all monitors.
- Windows reports the correct monitor count to the RAIL app (so per-monitor maximize/snap works).
- Tested on ≥2 same-scale monitors (mixed-scale is a separate FreeRDP / XWayland limitation, out of scope).
Context
Found empirically in kernalix7/winpodx#401 (/multimon was tried first, killed input, so winpodx defaults to /span). Downstream issue: kernalix7/winpodx#544.
Summary
A RDP client connecting with
/multimon(multi-entryMonitorDefArray) into a RemoteApp (RAIL) session that rdprrap has multi-session-enabled → input stops registering entirely (the window paints, but mouse/keyboard are dead). A single wide monitor (/span, oneMonitorDefArrayentry) works fine.This blocks true per-monitor multi-monitor downstream in winpodx (kernalix7/winpodx#544): under
/spanWindows sees one wide monitor, so apps maximize across both physical displays./multimonwould fix it but currently kills input under rdprrap.Repro
MaxInstanceCount>1,fSingleSessionPerUser=0)./app:... /multimonfrom a host with ≥2 same-scale monitors./multimon→/span: input works.Suspected cause
The multi-session RAIL / input-routing path likely assumes a single monitor — it drops the extra
TS_MONITOR_DEFentries, or computes the input virtual-desktop rectangle from single-monitor geometry, so pointer coordinates fall outside the routed region and input is discarded. Fix direction: parse + honor the fullMonitorDefArray(primary flag + per-monitor rects) in the multi-session RAIL window/input mapping.Acceptance
/multimoninto a multi-session-enabled guest keeps mouse + keyboard working across all monitors.Context
Found empirically in kernalix7/winpodx#401 (
/multimonwas tried first, killed input, so winpodx defaults to/span). Downstream issue: kernalix7/winpodx#544.