Help wanted: validate multi-monitor (negative-X origin) fix on real Windows hardware — we have no local rig

Context

PR #1980 just landed the SendInput half of #1979 — a fence-post in MOUSEEVENTF_VIRTUALDESK normalization that mis-routed clicks at the exact inter-monitor seam in negative-X layouts. 26 unit tests cover the math deterministically across 8 multi-monitor layouts, including the reporter's exact (-1920, 0, 3840×1080) setup.

But the reporter's actual symptom in the original log goes through the PostMessage code path (post_click_screen / MAKELPARAM / ScreenToClient), which #1980 doesn't touch. A code-audit subagent is currently working on a follow-up fix for that path; PR will land separately.

The ask

We don't have a real multi-monitor Windows test rig, and we spent significant time trying to assemble one without success. Honest record of what we tried and where each path broke:

Track A — Virtual Display Driver (VDD) on an Azure Windows 11 VM (server-side virtual displays)

1. Downloaded VirtualDisplayDriver-x86.Driver.Only.zip v25.7.23 from itsmikethetech/Virtual-Display-Driver.
2. pnputil /add-driver MttVDD.inf /install initially failed with "Authenticode publisher not yet established as trusted" — fixed by extracting the SignPath Foundation cert from MttVDD.dll via Get-AuthenticodeSignature, importing into Cert:\LocalMachine\TrustedPublisher and Cert:\LocalMachine\Root, then retrying — driver registered cleanly as oem14.inf.
3. Driver registration created the package but no root-enumerated device. pnputil /add-device in Windows 11 26100 rejected Root\MttVDD (printed help text + exit 1) regardless of syntax variants.
4. Pulled the larger VDD.Control.25.7.23.zip (71 MB) which bundles devcon.exe. devcon install MttVDD.inf Root\MttVDD worked → device created at DISPLAY\MTT1337\1&28A6823A&0&UID256, status=OK.
5. Adapter device however still missing. Reboot — after reboot the adapter device appeared (Display | Virtual Display Driver | ROOT\DISPLAY\0000), monitor too, both status=OK.
6. But SM_CMONITORS=1 still — IddCx attached the framebuffer to the console (session 0) windowstation, not to the live RDP session 1 windowstation. This is the architectural ceiling: VDD is a system-wide IddCx display adapter, can't follow per-session windowstations without a different driver.

Track B — RDP /multimon from a Mac via the Microsoft "Windows App" client

Microsoft's macOS client properly negotiates RDP's multi-monitor extension when the Mac itself has multiple physical displays. Reporter scenario requires a Mac with 2+ physical monitors, and the secondary must be arranged to the left in macOS Display Settings to produce a negative X origin. Confirmed the client passes correct per-monitor origins through the wire when configured this way — but a single-monitor Mac can't fake the second.

Track C — BetterDisplay virtual displays + xfreerdp /multimon

Installed BetterDisplay via brew, created a 1920×1080 virtual display, positioned it via displayplacer at (-2560, 0), then connected with xfreerdp /v:<vm> /u:<user> /p:<pw> /multimon. Connection succeeded but /multimon wasn't honored — xfreerdp on macOS falls back to /span mode (one stretched logical display) because its Cocoa multi-display enumeration is incomplete. The VM session saw SM_CMONITORS=1 virt=(0,0,8192×1407) — a wide virtual desktop but no negative origin.

Net

No path produced a Windows session with SM_XVIRTUALSCREEN < 0 that we could drive cua-driver against from our remote setup.

What we'd love help with

@1mestre — once the PostMessage-path fix lands (will tag the PR in this thread), would you be willing to:

1. Run a fresh install of cua-driver-rs against the fix on your existing multi-monitor setup, and
2. Re-run the reproduction that produced the original (-1795, 383) mis-routed click,

and report back whether the click now lands on the correct monitor?

If yes, we'll get a typed end-to-end PASS on real hardware. If no, your run will tell us exactly where the next bug lives.

Tagging anyone else in the community who has a multi-monitor Windows setup and wants to help test — we'll set up a dedicated MR feedback thread when the fix is ready.

References

• Reported in #1979
• SendInput half: #1980 (merged)
• PostMessage half: PR pending (will edit in when subagent reports)