fix(pf-inject): the DualShock 4 Windows backend never imported OFF_INPUT #105
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: unom/punktfunk#105
Reference in New Issue
Block a user
Release blocker for v0.25.0 — the Windows host does not build. One word in a
use. No behaviour.What happened
dualshock4_windows.rswrites the neutral report straight toOFF_INPUTin its bootstrap path — correctly, and exactly as the DualSense and Steam Deck backends do: the devnode does not exist yet at that point, so there is no reader to race and no seqlock to take. Its steady-state path already goes throughpublish_input, the v2.3 seqlock.But the import list only names
publish_input.steam_deck_windows.rsimportsOFF_INPUTexplicitly for the same bootstrap write; this one was missed when the list was edited to addpublish_input.Why it matters
pf-injectis step 1 ofwindows-host.yml's build. Av0.25.0tag would have produced no Windows host binary, no installer, and no host asset on the release page.Why nothing caught it
pf-inject's Windows backends compile only for*-pc-windows-msvc, and the crate is host-side — sowindows.yml, which gates the client, never touches it. The Mac-side cross-check that usually stands in for this cannot help either:pf-injectpullspunktfunk-coreand thereforering, whose C build wants MSVC headers, socargo check --target x86_64-pc-windows-msvcdies incc-rslong before reaching this file.Verification — A/B on the CI runner itself
Ran
windows-host.yml's own lines on .133 (home-windows-runner-1) against the v0.25.0 release tree, before and after this commit:cargo build --release -p punktfunk-host --features nvenc,amf-qsv,qsvcargo clippy --release -p punktfunk-host --features nvenc,amf-qsv,qsvcargo clippy --release -p pf-encode --all-targets --features nvenc,amf-qsv,qsvcargo clippy --release -p pf-encode --all-targets(featureless — the shape that broke #86)cargo clippy --release -p pf-capture --all-targetscargo clippy --release -p pf-vdisplay --all-targetscargo clippy --release -p punktfunk-trayEverything
--releaseon purpose: a debug second-build of openh264 reliably C1069s that runner.The Windows host does not build: error[E0425]: cannot find value `OFF_INPUT` in this scope --> crates\pf-inject\src\inject\windows\dualshock4_windows.rs:65:48 error: could not compile `pf-inject` (lib) due to 1 previous error `dualshock4_windows.rs` writes the neutral report straight to `OFF_INPUT` in its bootstrap path — correctly, and exactly as the DualSense and Steam Deck backends do: the devnode does not exist yet at that point, so there is no reader to race and no seqlock to take. Its steady-state path already goes through `publish_input`, which is the v2.3 seqlock. But the import list only names `publish_input`. `steam_deck_windows.rs` imports `OFF_INPUT` explicitly for the same bootstrap write; this one was missed when the list was edited to add `publish_input`. One word in a `use`. No behaviour. WHY CI DID NOT CATCH IT: `pf-inject`'s Windows backends compile only for `*-pc-windows-msvc`, and the crate is host-side, so the client Windows workflow never touches it. A cargo check from a Mac cannot stand in either — pf-inject pulls punktfunk-core and therefore ring, whose C build wants MSVC headers, so the cross-check dies in cc-rs long before it reaches this file. FOUND BY: running windows-host.yml's own build line on the CI runner (.133) against the v0.25.0 release tree before tagging — `cargo build --release -p punktfunk-host --features nvenc,amf-qsv,qsv`. It fails at `pf-inject`, which is step 1 of the host job, so a v0.25.0 tag would have produced no Windows host binary, no installer, and no host asset on the release.