[Marc-André Moreau (mamoreau-devolutions)]

Display Control (MS-RDPEDISP) was only usable for a single primary monitor at 100% device scale. This lets clients send complete monitor layouts during the session, with real orientation and DPI, and wires it into the viewer and the ActiveX control.

Changes

ironrdp-displaycontrol (breaking)

• DisplayControlMonitorLayout::new now rejects overlapping monitors and, for multi-monitor layouts, monitors not adjacent to another one (MS-RDPEDISP 3.1.5.2). Layouts it previously accepted can now fail.
• fit_to_capabilities enforces the server's MaxNumMonitors and maximum monitor area (MS-RDPEDISP 3.2.5.2): extra monitors are dropped (the primary is kept), a single oversized monitor is scaled down keeping its aspect ratio, and an oversized multi-monitor layout is rejected rather than shrunk (which would move monitors relative to each other).
• DisplayControlClient stores the server capabilities and gains encode_monitor_layout; encode_single_primary_monitor fits to the capabilities too.
• new_single_primary_monitor clamps the desktop scale to 100..=500 and derives the device scale (100/140/180) from it instead of hard-coding 100%; a square monitor is landscape.
• Helpers: capability getters, area, desktop_size, MonitorLayoutEntry::adjust_desktop_scale_factor, DeviceScaleFactor::from_value / from_desktop_scale_factor.

ironrdp-session: ActiveStage::prepare_monitor_layout, encode_monitor_layout, display_control_capabilities.

ironrdp-client (breaking, new enum variant): RdpInputEvent::MonitorLayout shares the resize queue. Without Display Control it reconnects advertising the requested monitors in the GCC Client Monitor Data block. A layout the server capabilities cannot accept is logged and dropped instead of ending the session.

Viewer: handles WindowEvent::ScaleFactorChanged through the debounced resize path, so the session follows the window DPI. The viewer is a single window, so it still sends one primary monitor. The RPC-backed path passes the window scale too (Daemon::try_resize takes a scale; the daemon crate is unpublished).

ActiveX

• Multimonitor sessions no longer reject dynamic updates. Like mstsc, they mirror the local monitors: UpdateSessionDisplaySettings, WM_DISPLAYCHANGE and WM_DPICHANGED (debounced) send the full local topology with each monitor's position, rotation and effective DPI. Explicit scale arguments override every monitor; width/height/orientation/physical size describe a single monitor and are ignored in multimon.
• The sent topology becomes the configured one, keeping it consistent with the GCC monitors advertised at connect time and confirmed by the server's monitor layout.
• Single-monitor updates now accept rotation and 140%/180% device scale (explicit layout). Values MS-RDPEDISP does not define return E_INVALIDARG (was E_NOTIMPL).
• active_multimon_layout_rejects_dynamic_display_updates is replaced by active_multimon_layout_sends_full_display_control_layouts.

Testing

• New ironrdp-testsuite-core tests for overlap/adjacency validation, capability fitting, scale clamping and client encoding; unit tests in session, client and ActiveX.
• cargo xtask check fmt -v and cargo xtask check lints -v pass; tests pass for every touched crate.
• Not tested against a live Windows server.

Known limitations

• WM_DISPLAYCHANGE is only broadcast to top-level windows, so the ActiveX control sees it only when its window is top-level.
• An odd local monitor width is rounded down, which can leave a 1-pixel gap that fails the adjacency check; the update is then logged and skipped.
• The .rdp keys use multimon, selectedmonitors and dynamic resolution are not handled yet.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

Display metadata preservation, reconnect handling, and confirmed topology state have unresolved correctness defects.

6 open issues

• Correct reversed 90/270 monitor rotation mappings · New
• Avoid overriding DPI during automatic renderer resizes · New
• Preserve explicit display scale and orientation metadata · New
• Preserve confirmed topology when layout updates are rejected · New
• Validate GCC monitor limits before fallback disconnect · New
• Clear stale monitor topology on plain resize · New

What changed in this PR

Extends Display Control to support multi-monitor layouts, orientation, and DPI across the session API, client, viewer, and ActiveX control.

Changes:

• Adds layout validation, server-capability fitting, and encoding APIs.
• Integrates monitor updates with resize queues and reconnect fallback.
• Adds DPI handling and regression tests.

File	Description
crates/​ironrdp-viewer/​src/​app.rs	Debounces DPI changes and forwards window scale.
crates/​ironrdp-testsuite-core/​tests/​displaycontrol/​mod.rs	Tests layout validation, fitting, and scaling.
crates/​ironrdp-session/​src/​active_stage.rs	Exposes capabilities and monitor-layout APIs.
crates/​ironrdp-displaycontrol/​src/​pdu/​mod.rs	Adds geometry validation and capability fitting.
crates/​ironrdp-displaycontrol/​src/​client.rs	Stores capabilities and encodes complete layouts.
crates/​ironrdp-daemon/​src/​daemon.rs	Accepts scale factors for resize requests.
crates/​ironrdp-client/​src/​rdp.rs	Queues layouts and adds reconnect conversion.
crates/​ironrdp-activex/​src/​control.rs	Integrates local topology, rotation, and DPI updates.
crates/​ironrdp-activex/​Cargo.toml	Adds the Display Control dependency.
Cargo.lock	Records the ActiveX dependency change.

_{Review effort: Balanced}

[github-actions]

The PR coherently enables full multi-monitor DISPLAYCONTROL_MONITOR_LAYOUT_PDUs with orientation and DPI: pdu-level overlap/adjacency validation and capability fitting, session plumbing via ActiveStage::prepare_monitor_layout, a new RdpInputEvent::MonitorLayout sharing the resize queue with GCC-fallback reconnection, and ActiveX mirroring of the local topology. The protocol reviewer found no wire-conformance defect and independent inspection of fit_to_capabilities, the session/client plumbing and the ActiveX layout code surfaced no session-corrupting bug. Published findings: one unverified spec interpretation in fit_to_capabilities' total-area limit (concrete impact: a server-rejected layout is only logged and dropped), one unresolved behavior question in mirrors_local_monitors for single-monitor 'use multimon' sessions, one overclaimed doc/behavior gap in the capability fitting (refined), and four small behavior-preserving compression nits in the new ActiveX code. The parallel-attrib…

1. [code-compressor] adjust_display_size is computed twice for the same desktop size in update_display_layout_impl — low 🟡 — crates/ironrdp-activex/src/control.rs
   The pure MonitorLayoutEntry::adjust_display_size(desktop_width, desktop_height) is called inside the derived_orientation block and again in the full-layout else branch. Hoisting a single let binding above the event conditional removes the duplicated derivation and the extra block scope with no behavior change.

Push a commit after addressing these findings. If no code change is needed, you may resolve inline threads and comment @github-actions review-ready to request human review.

[github-actions]

The PR is a well-tested, protocol-conformant implementation of multi-monitor Display Control layouts: wire format, overlap/adjacency validation, capability fitting, the GCC reconnect fallback, and ActiveX multimon mirroring all check out against MS-RDPEDISP/MS-RDPBCGR. I independently confirmed the five skeptical findings: Reconnect() routes hardcoded 100% scale factors through the explicit multimon path, an explicit scale override is recorded as the base topology so later DPI refreshes are skipped as unchanged, capability-fit failures silently drop layouts while the ActiveX control has already recorded the topology as configured (and the non-forced refresh skip prevents retries), RAIL is told the unfitted desktop size, and the reconnect fallback doc overstates the code. The two code-compressor findings are confirmed as unused/test-only public API additions; both are low-severity speculative-surface items.

1. [skeptical] Reconnect() forces 100% desktop and device scale on every monitor of a multimon session — medium 🟠 ❓ — crates/ironrdp-activex/src/control.rs
   reconnect() calls update_display_layout with hardcoded scale factors of 100, which forward to update_display_layout_impl(layout, explicit=true). In the new multimon branch, explicit=true treats those hardcoded defaults as caller choices and forces the update, sending the local topology with every monitor's DPI overridden to 100% while the requested width/height is ignored. This is precisely the 'defaults, not caller choices' case explicit=false was introduced for on the renderer path. The lines are pre-existing but the behavior becomes reachable only with this PR; intent (mstsc parity) is unverifiable, hence question=true.

Push a commit after addressing these findings. If no code change is needed, you may resolve inline threads and comment @github-actions review-ready to request human review.

[github-actions]

The PR adds complete multi-monitor Display Control layouts with orientation/DPI, capability fitting, overlap/adjacency validation, an ActiveX local-topology mirroring path, and a GCC Client Monitor Data fallback. All 9 validated candidates were independently confirmed against the head and accepted: one protocol edge case (missing 32,766-pixel virtual desktop bound in the GCC fallback), four behavioral/state-consistency concerns of low severity, and four maintainability items. The two double-fit findings (skeptical and code-compressor) share one root cause at rdp.rs:669-675 and are merged into a single final finding with both sources. No high or critical issues were found; the double-fit and duplicated rejection-handler items are the most actionable maintainability cleanups.

1. [code-compressor] Zeroed 'unspecified scale' DisplayLayout literal repeated at six call sites — low 🟡 — crates/ironrdp-activex/src/control.rs
   The tail {physical_width: 0, physical_height: 0, orientation: 0, desktop_scale_factor: 0, device_scale_factor: 0} is repeated at six DisplayLayout construction sites (plus display_layout_from_renderer_size), each differing only in desktop_width/height. The PR added doc comments documenting the 0-means-unspecified convention, but it still has no single definition; a small constructor such as DisplayLayout::unspecified(desktop_width, desktop_height) would collapse each literal to two arguments so a future field cannot be missed at one site. Behavior is identical.

Push a commit after addressing these findings. If no code change is needed, you may resolve inline threads and comment @github-actions review-ready to request human review.