enricobuehler
13438b1287
The Xbox-pad-on-Windows programme is a five-row matrix — classic XInput, WGI `Gamepad`, WGI
`RawGameController`, GameInput, and the HID/DirectInput/Steam family — and nothing in this tree
measured any of it. Every reading in the handoff came from ad-hoc off-tree tools, which is why
several could not be reproduced later and why one was a false positive. `win-input-matrix` makes
the matrix a command you can run twice and diff.
Two traps are baked into it because both have already cost this programme a wrong conclusion.
`--watch` samples repeatedly and reports LIVE vs MUTE per device, because an API listing a pad that
never reports is the exact failure mode here — worse than not listing it, since a title that binds
the first gamepad latches a dead one. And the doc comment insists on a baseline with the virtual pad
STOPPED: a real Xbox pad owns XInput slot 0, which is how `rc=0 LX=-885` was once read as success
with our pad already killed.
⭐ `wake_wgi()` is not optional and is commented as such. `Gamepad::Gamepads()` and
`RawGameController::RawGameControllers()` return a cache filled by WGI's device-watcher, which a
GUI app has already started and a console app has not. Without subscribing to the Added events
first, BOTH collections come back empty with real controllers attached — measured here: a DualSense
sitting in the HID interface class, `RawGameControllers` count=0. A probe missing this reports "WGI
cannot see the pad" when WGI could not see anything.
WHAT IT FOUND (full record in measurements/2026-08-09-xbox-hid-xinputhid-busfilter.md): with
`UpperFilters=xinputhid` on the pad's PARENT devnode AND `DevicePropertyFlags=1` in that parent's
SOFTWARE key, the HID Xbox pad is promoted for the first time — the child gains the `IG_00` token,
an XUSB interface appears, classic XInput admits it, and WGI `Gamepad` lists it. All four had never
happened on this backend. A one-value A/B proves `DevicePropertyFlags` is the decisive half:
removing it alone reverts all four. That retro-explains the earlier "the filter installs fine and
produces nothing" result — the filter was loading without ever being put in bus-filter mode, which
is what `BusDevice = 0x1` means in Microsoft's own comment in `xinputhid.inf`.
Not a workspace member, for the same reason as `hid-descriptor-dump`: it is a Windows-only
bring-your-own-hardware tool with no business on a CI leg.
VERIFIED
* `cargo fmt --check` clean; `cargo clippy --target x86_64-pc-windows-msvc --all-targets
-- -D warnings` clean (cross-checked from macOS; the target is installed).
* Builds and runs on .173 (Win11 26200).
* Self-checked against known-good hardware before any conclusion was drawn from it: baseline
reads the USB DualSense as LIVE in both WGI collections and the resting 8BitDo as MUTE.
* The A/B was run in both directions on the same box in one session.
* `cargo metadata` on the root workspace resolves and does NOT list this crate.
* .173 fully reverted: registry values removed, devnodes removed, oem100.inf deleted, both certs
delstored, 6 pre-existing pf_gamepad packages and the production service untouched.
NOT VERIFIED
* GameInput — no binding in the `windows` crate, needs hand-written COM vtables. Not covered;
the doc comment says so.
* That the promotion survives a reboot or a devnode re-create from a shipped INF `AddReg` rather
than a hand-written registry value. Nothing is shipped: `pf_gamepad.inx` is UNCHANGED and still
contains no AddReg of any kind.
* WHY the promoted pad still translates no data. Enumeration is fixed; translation is not. The
evidence points at the report descriptor, which is gated on the §3.3 decision.
114 lines
5.2 KiB
TOML
114 lines
5.2 KiB
TOML
[workspace]
|
|
resolver = "2"
|
|
members = [
|
|
"crates/punktfunk-core",
|
|
"crates/punktfunk-host",
|
|
"crates/punktfunk-host/vendor/usbip-sim",
|
|
"crates/punktfunk-tray",
|
|
"crates/pf-bitstream",
|
|
"crates/pf-bitstream/vendor/cros-codecs",
|
|
"crates/pf-client-core",
|
|
"crates/pf-clipboard",
|
|
"crates/pf-presenter",
|
|
"crates/pf-console-ui",
|
|
"crates/pf-driver-proto",
|
|
"crates/pf-paths",
|
|
"crates/pf-update",
|
|
"crates/pf-update-check",
|
|
"crates/pf-host-config",
|
|
"crates/pf-gpu",
|
|
"crates/pf-zerocopy",
|
|
"crates/pf-frame",
|
|
"crates/pf-win-display",
|
|
"crates/pf-encode",
|
|
"crates/pf-capture",
|
|
"crates/pf-inject",
|
|
"crates/pf-vdisplay",
|
|
"crates/pf-vkdecode",
|
|
"crates/pf-dxvadec",
|
|
"crates/pf-vaadec",
|
|
"crates/pyrowave-sys",
|
|
"crates/libvpl-sys",
|
|
"clients/probe",
|
|
"clients/cli",
|
|
"clients/linux",
|
|
"clients/session",
|
|
"clients/windows",
|
|
"clients/android/native",
|
|
"tools/cursor-probe",
|
|
"tools/display-disturb",
|
|
"tools/latency-probe",
|
|
"tools/loss-harness",
|
|
]
|
|
# Standalone PoC (built on its own; pulls usbip/tokio/libusb we don't want in the workspace).
|
|
# The vendored `ndk` is a [patch.crates-io] source, not a member: it only compiles for the
|
|
# `*-linux-android` targets, so workspace membership would break host `cargo build --workspace`.
|
|
exclude = [
|
|
"packaging/linux/steam-deck-gadget/usbip-poc",
|
|
"clients/android/native/vendor/ndk",
|
|
# Bring-your-own-hardware measurement tools. `hid-descriptor-dump` pulls `hidapi`, a C library
|
|
# wanting libudev on Linux; `win-input-matrix` is Windows-only and asks the live input stacks
|
|
# what they can see. Neither belongs in `cargo build --workspace` or on a CI leg with no pad.
|
|
"tools/hid-descriptor-dump",
|
|
"tools/win-input-matrix",
|
|
]
|
|
|
|
# ndk 0.9.0 verbatim from crates.io plus ONE visibility change (and two warning fixes — an
|
|
# unnecessary `std::` qualification and a feature-gated `Result` import): `MediaCodec::as_ptr` made public
|
|
# (upstream keeps it private and exposes no frame-rendered binding), so the Android client can
|
|
# call `AMediaCodec_setOnFrameRenderedCallback` via ndk-sys for the HUD's `display` stage
|
|
# (design/stats-unification.md). Drop the patch when upstream exposes the pointer or the callback.
|
|
[patch.crates-io]
|
|
ndk = { path = "clients/android/native/vendor/ndk" }
|
|
|
|
[workspace.package]
|
|
version = "0.26.0"
|
|
edition = "2021"
|
|
rust-version = "1.82"
|
|
license = "MIT OR Apache-2.0"
|
|
authors = ["unom"]
|
|
repository = "https://git.unom.io/unom/punktfunk"
|
|
|
|
# The `unsafe` discipline the `packaging/windows/drivers/*` crates already run, extended to the
|
|
# workspace. `unsafe fn` marks a CONTRACT the caller must uphold; it is not a licence for the whole
|
|
# body to skip checking. Without this lint an `unsafe fn` body is unchecked end to end, so a 600-line
|
|
# function hides which handful of lines are actually the unsafe ones — exactly the reviewer-hostile
|
|
# shape we are working down. (This is the Rust 2024 default; adopting it early also pays off the
|
|
# edition migration.)
|
|
#
|
|
# `deny`, not `warn`. `warn` was never actually a softer setting: CI runs `cargo clippy … -D
|
|
# warnings`, which promotes it to a hard error anyway — that is how adopting this lint turned main
|
|
# red on every platform for a day without the level in this file ever saying `deny`. A level that
|
|
# lies about its own severity is worse than a strict one, so this now states what CI already does,
|
|
# and the exemptions are written down per file instead of hiding in a 689-warning wall nobody reads.
|
|
#
|
|
# THE EXEMPTIONS. Fourteen GPU/FFI backend files carry `#![allow(unsafe_op_in_unsafe_fn)]` with a
|
|
# one-line reason each. They are not "not done yet" — they are where this lint stops paying:
|
|
# their bodies are ash/CUDA/AMF/libav calls almost line for line (measured: 64% of the sites are a
|
|
# single third-party FFI call, and of the 44 `unsafe fn`s in them only 4 have a body containing no
|
|
# unsafe operation at all). Narrowing them means one `unsafe {}` per line plus, since pf-encode also
|
|
# denies `clippy::undocumented_unsafe_blocks`, one hand-written SAFETY comment per line that could
|
|
# only ever restate "an ash call on a live device" — the precise noise that made `unsafe` stop
|
|
# meaning anything here before (see the header of `pf-win-display/src/win_display.rs`).
|
|
#
|
|
# Everything else in the workspace is at zero and enforced. Removing one of those allows, file by
|
|
# file, is real work with a real payoff; blanket-narrowing all fourteen is not. Prefer DELETING an
|
|
# `unsafe fn` marker over wrapping its body: keep the marker only where a caller can actually break
|
|
# something (a raw pointer, a borrowed HANDLE, a GPU object that must not be in flight).
|
|
[workspace.lints.rust]
|
|
unsafe_op_in_unsafe_fn = "deny"
|
|
|
|
[profile.release]
|
|
opt-level = 3
|
|
lto = "thin"
|
|
codegen-units = 1
|
|
# NOTE: deliberately NOT `panic = "abort"`. punktfunk-core ships as a cdylib/staticlib into
|
|
# third-party apps (Swift/Kotlin/C) and its C ABI catches panics at the boundary
|
|
# (`catch_unwind` → `PunktfunkStatus::Panic`). `panic = "abort"` would make that guard a
|
|
# no-op and let a stray panic abort the embedding application. Unwinding keeps the
|
|
# documented isolation guarantee real.
|
|
|
|
# The per-frame hot path must stay fast even in dev builds.
|
|
[profile.dev.package."*"]
|
|
opt-level = 2
|