enricobuehlerandClaude Opus 5
b6acbd096e
android / android (push) Failing after 2s
apple / swift (push) Successful in 1m21s
ci / rust-arm64 (push) Successful in 1m49s
ci / web (push) Failing after 1s
ci / docs-site (push) Successful in 1m32s
ci / rust (push) Successful in 6m38s
apple / screenshots (push) Successful in 5m55s
arch / build-publish (push) Successful in 8m58s
deb / build-publish (push) Successful in 6m38s
docker / apps (., web/Dockerfile, punktfunk-web) (push) Successful in 1m11s
docker / builders (ci/fedora-rpm.Dockerfile, punktfunk-fedora-rpm) (push) Successful in 3m19s
docker / apps (docs-site, docs-site/Dockerfile, punktfunk-docs) (push) Successful in 1m9s
deb / build-publish-host (push) Successful in 4m57s
docker / builders (ci/rust-ci-noble.Dockerfile, punktfunk-rust-ci-noble) (push) Successful in 3m43s
docker / builders (ci/rust-ci.Dockerfile, punktfunk-rust-ci) (push) Successful in 3m59s
docker / builders (--build-arg FEDORA_VERSION=44, ci/fedora-rpm.Dockerfile, punktfunk-fedora44-rpm, -f44) (push) Successful in 12s
windows-host / package (push) Successful in 12m4s
windows-host / winget-source (push) Skipped
docker / deploy-docs (push) Successful in 55s
windows-host / canary-manifest (push) Successful in 1m30s
docker / builders (ci/arch-ci.Dockerfile, punktfunk-arch-ci) (push) Failing after 10m36s
docker / builders (ci/android-ci.Dockerfile, punktfunk-android-ci) (push) Failing after 10m55s
deb / build-publish-client-arm64 (push) Failing after 11m12s
docker / builders-arm64cross (push) Skipped
rpm / build-publish (44, fedora-44, punktfunk-fedora44-rpm) (push) Failing after 11m56s
rpm / build-publish (43, bazzite, punktfunk-fedora-rpm) (push) Successful in 15m27s
A woken Windows host refused every connection with "pf-vdisplay driver interface not found", on a box where the driver was installed and running. Resuming re-enters D0 and re-registers the IddCx control interface while the rest of the resume storm is still going. A client reconnecting a second after wake lands inside that gap. `ensure_available` probed exactly ONCE, so it read the gap as a dead driver and answered a device that was seconds from ready by disabling and re-enabling it — then gave the interface 4 s to come back, which a contended post-resume PnP does not meet. The session failed, and the log blamed a missing install. The recovery also could not tell whether it had recovered anything. It ran the whole cycle under `SilentlyContinue` and reported `(Get-PnpDevice).Status` — the DEVICE's status, not the cycle's outcome — so a disable that was REFUSED left the adapter untouched, started, and reading `OK`. That is the reporter's `cycled the adapter device … status=OK` line: a recovery that never happened, announcing success. And a refusal is the expected case here, not the exotic one: reset-pf-vdisplay.ps1 stops the host service first precisely because the host holds the driver's control device open, a step an in-process cycle structurally cannot take. - Distinguish a devnode MID-TRANSITION (interface registered, not started yet, or the open refused) from one genuinely ABSENT. Wait the first out; only the second earns a reload. `Probe` carries the counts. - Report what the reload DID, not what the device looks like afterwards: every failable step is `-ErrorAction Stop` in a `try`, and `pnputil /restart-device` is the fallback for the in-use device that `Disable-PnpDevice` refuses. Failure paths re-enable, so a half-cycle can never strand the adapter DISABLED. - Give the interface 15 s to arrive after a reload, not 4 — under a 30 s hard ceiling so a permanently wedged devnode still fails predictably. - Serialize recovery: N sessions racing in after a wake perform ONE reload, not N interleaved ones. The lock is taken only where no manager lock is held, so the order stays one-way. - Retire the manager's cached control handle when a reload runs, instead of letting the next session discover it via a failed IOCTL. - Surface the real reason. `ensure_available` returns `Result`, so the log names how long it waited, whether a reload ran, and how many interface instances were seen in what state — the detail that would have identified this from the field report's log alone. `VdisplayDriver::open` now shares the wait (brief, no reload) instead of carrying a second, drifted copy of it — that path is also reached by `hw_cursor_capable` mid-handshake, where a reload would be the wrong trade for one capability bool. Windows-gated, so verified with scripts/xcheck.sh (check + clippy -D warnings, --all-targets) and cargo fmt; on-glass wake test still owed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>