v0.9.2 — blank-recovery clean-presentation latch

v0.9.2 — blank-recovery clean-presentation latch

A point release fixing a v0.9.1 regression in the mstsc / Windows-App reconnect-blank auto-recovery. The default runtime path is unchanged — only the blank detector's disarm logic changed.

The fix

v0.9.1 (#172) replaced the older one-way disarm latch (first nonzero decode+render report → detector off for the connection) with a revocable disarm, to catch a client that reported nonzero-EDR while still black after a reactivation. That regressed a client with the mirror behaviour — one that presents the desktop fine but reports timeDiffEDR == 0 mid-session, whose short nonzero-EDR runs (3–14) never reach the "established" bar (40). The aggressive path force-dropped its working ~50-second sessions, and the auto-reconnect cookie reconnected each time → a connect/disconnect loop on a session that was rendering and interactive.

Root cause: QoE decode+render-time is bidirectionally unreliable (one client class reports nonzero-while-black, another zero-while-presenting), so no EDR threshold separates them. The signal that does: when the nonzero run occurs. The fix is a durable presented_clean latch — a sustained nonzero-EDR run seen before any recovery attempt has fired proves the client painted the desktop at connect (it is not the reconnect-blank, which is black from frame one), so the detector latches off for the connection (the pre-#172 behaviour, restored). The "before any recovery attempt" guard preserves #172: the blank client's nonzero-while-black flicker only appears after its reactivation, so the latch is withheld for it and the escalation still recovers it.

Live-verified: a 6-minute session held (previously dropped every ~50 s), and a genuine reconnect-blank still self-healed. Unit-tested. Trade-off: a genuine mid-session blackout on a cleanly-presented connection is no longer auto-recovered (an unconfirmed case) — Ctrl+Alt+Shift+R is the manual A/V-resync lever.

Known issue (deferred, not a regression)

A blank-recovery reactivation un-blanks the --capture-primary physical panel — macOS resets the panels' gamma on the reconfiguration, and the recovery's same-size Resize skips the re-assert the live-resize path runs. Present since blank-recovery reactivation shipped (v0.8.27), only noticed now that sessions stop false-dropping. A gamma-timing reblank fix was flaky and was reverted; the robust fix is a shield-window helper — --shield-primary already avoids the whole class. See docs/known-quirks.md.

Which artifact do I want?

All builds are arm64-only.

• macrdp-0.9.2.dmg — the full build, recommended. Signed (Developer ID), notarized + stapled (passes Gatekeeper offline — no right-click-Open dance), and entitled, so generic USB redirection and camera redirection work in it. Drag-to-install. SHA-256: 8a095b6468b93155f22f9443ffdf7de76a65da60c0834d81636b600a941de7e0.
• …-app.zip / …-.tar.gz — the CI builds of macrdp.app. Not entitled, so USB + camera redirection are inert (controller unavailable / no camera to feed); everything else — --shield-primary, virtual display, H.264, audio, clipboard, drive + smart-card redirection — works. Covered by SHA256SUMS (shasum -c SHA256SUMS).

Builds on v0.9.1 (the lockable-headless release). See docs/release-history.md for the full narrative and per-feature caveats.