feat(server): let the display decline the Display Control channel

[Greg Lamberson (glamberson)]

Summary

• A server that cannot resize, for example one mirroring a fixed-size physical screen, had no way to stop ironrdp-server from offering the Display Control channel. MS-RDPEDISP section 1.3 defines no reject message: When the requested configuration is not possible, the server simply does not update the session. A client that sends a layout the server cannot apply is left waiting.
• Added a default RdpServerDisplay::offers_display_control() method (returns true, matching today's behavior), queried once per connection before the dynamic channels are attached.
• When it returns false, attach_channels skips DisplayControlServer, so the channel is not offered on that connection.

Validation

cargo xtask check fmt/lints/tests/typos/locks all pass. Two end-to-end tests in ironrdp-testsuite-extra connect a real client that registers a Display Control channel and an echo channel: A display that offers Display Control gets the channel created on the client, and a display that declines it does not. The declining test fails if the gate is removed.

Notes

• This is the rule gnome-remote-desktop applies: It creates its Display Control channel only in extend (virtual monitor) mode.
• Additive only: One new trait method with a default body. No existing implementor is affected unless it opts in.

[github-actions]

Additive, low-risk PR: a default-true RdpServerDisplay::offers_display_control() hook gates registration of DisplayControlServer in attach_channels, letting fixed-size displays (e.g., mirrored physical screens) suppress the MS-RDPEDISP offer and avoid the no-reject layout-request hang. Both call sites (serve_negotiated and run_connection_inner) consistently query the hook before channel setup, the conditional dvc construction matches the existing shadowing-builder idiom used for echo/rdpei/rdpeai in the same function, and no capability sets or PDU formats change, so no protocol defect exists. Independently verified against pr-head. Two valid low-severity candidates from specialists are accepted unchanged: the new test only asserts the hook was consulted rather than that the channel is actually omitted from the connection, and serve_negotiated acquires the display mutex twice back-to-back where one held guard suffices.

1. [code-compressor] Back-to-back display mutex acquisitions in serve_negotiated can share one guard — low 🟡 — crates/ironrdp-server/src/server.rs
   serve_negotiated acquires the display tokio Mutex twice in a row (monitor_count, then the new offers_display_control query). Holding one guard across both awaited calls is behaviorally equivalent, removes one lock round-trip, and closes a window where another task could interleave between the two queries. The same pattern in run_connection_inner is separated by pre-existing code and is deliberately out of scope; only the adjacent pair in serve_negotiated is a clean, low-risk cleanup.

[github-actions]

PR #1985 adds a defaulted RdpServerDisplay::offers_display_control() hook queried once per connection, letting a display omit the MS-RDPEDISP Display Control dynamic channel when it cannot honor layout requests. Assessment confirms the change is additive and safe: the true default preserves behavior for all existing implementors, omitting the DYNVC_CREATE_REQ is specification-consistent (MS-RDPEDYC makes dynamic channel creation a server-initiated per-channel decision, and MS-RDPEDISP imposes no obligation to open the channel), and the gate is applied at both connection paths before channels attach. New e2e tests cover both outcomes with a real client. No correctness, protocol, or API defects were found. The remaining candidates are low-severity maintainability items, all independently verified: monitor_count() is awaited and discarded when the display declines (contradicting its documented contract tied to the channel opening), the test re-hardcodes ironrdp-displaycontrol::CHANNEL_NA…

1. [skeptical] monitor_count() is awaited and discarded when the display declines Display Control — low 🟡 — crates/ironrdp-server/src/server.rs
   Both call sites unconditionally await monitor_count() immediately before offers_display_control() (serve_negotiated at server.rs:2049-2050; the TLS path likewise), but when the gate returns false the DisplayControlBackend is never built and the value is unused. The monitor_count doc states it is 'called once, before the Display Control Virtual Channel opens' (display.rs:345-346), so an opting-out display now observes a call whose contract no longer holds, paying any implementation cost for nothing. Conditioning the monitor_count fetch (or folding both queries into attach_channels) restores the documented behavior.
2. [code-compressor] offer_display_control parameter threading and duplicated display-lock query could be folded into attach_channels — low 🟡 — crates/ironrdp-server/src/server.rs
   attach_channels has exactly two callers, both async, and each repeats the same pattern: query the display under its lock, then pass the result as a parameter, with monitor_count already consumed only inside attach_channels. Making attach_channels async and querying monitor_count() and offers_display_control() inside it deletes the parameter threading, the monitor_count parameter, and the duplicated lock-and-query line at both call sites, with identical query timing relative to channel attachment. This would also resolve the discarded monitor_count call when the display declines.

[Greg Lamberson (glamberson)]

Both points are right. monitor_count() was awaited at both call sites and discarded when the display declined, which contradicted its documented contract. attach_channels is now async and asks the display itself: It queries offers_display_control() first and only asks monitor_count() when the channel is offered, so the two parameters and the duplicated query at each call site are gone.

[Greg Lamberson (glamberson)]

The two display queries now share one guard. attach_channels holds the display lock across offers_display_control() and, only when the channel is offered, monitor_count(), so no other task can interleave between them, and it saves the second lock acquisition.