enricobuehler
ae35e8b4d7
`XBOX_RDESC` is the only report descriptor in `pf-gamepad` that was hand-written rather than
captured off hardware, and its own provenance warning has now come true three times. The fix for
that class of bug is not another careful reading — it is a tool that goes and asks the device.
`tools/hid-descriptor-dump` does that: it dumps a real HID device's report descriptor, decodes it
into an annotated item listing plus a bit-offset LAYOUT TABLE, and can decode a blob we already
ship through the same decoder (`--rust-source <file> --symbol <NAME>`) so the two are diffable
line for line. `--read N` pulls live wire bytes, which is the only ground truth a reconstructed
descriptor cannot give you.
Deliberately NOT a workspace member — it pulls `hidapi`, a C library wanting libudev on Linux,
which has no business in `cargo build --workspace` or on a CI leg with no pad attached. It is a
bring-your-own-hardware tool and it is excluded in the root manifest, so CI never sees it.
The captured Elite disagrees with our blob in four ways, and the dangerous one is field ORDER:
the real pad reports sticks, ONE combined 16-bit Z trigger, then BUTTONS, then the hat, in an
UNNUMBERED 15-byte report; ours declares Report ID 1, two Simulation-page trigger axes, then the
hat, then 15 buttons. Since we claim a genuine Microsoft VID/PID and SDL/Steam/Windows all apply
stock mappings keyed on it, that ordering difference is exactly how every control silently lands
on the wrong action. The driver comment now records the diff and the two blockers that stop the
capture from simply being pasted in.
VERIFIED
* `cargo fmt --check` clean, `cargo clippy --all-targets -- -D warnings` clean (macOS).
* The tool builds and runs on macOS and on .173 (Windows 11 26200, cargo 1.96, MSVC, no WDK).
* TOOL VALIDATED AGAINST A KNOWN-GOOD CONTROL: pointed at the live DualSense on .173, it
reproduces the real `DUALSENSE_RDESC` layout exactly (input 0x01, 64 B, X,Y,Z,Rz,Rx,Ry at
bytes 1..6, hat 8.0, 15 buttons 8.4, output 0x02, the full feature ladder), and `--read`
returned live len=64 reports with sticks centred at 80 80 80 80 and the counter incrementing.
* `cargo metadata` on the root workspace still resolves and does NOT list this crate.
* The Elite capture is reproducible: `--vid 045E --pid 0B22`.
NOT VERIFIED
* That the capture equals the pad's NATIVE report map. Windows exposes no API for a device's
literal descriptor bytes, so hidapi reconstructs from `HidD_GetPreparsedData` — faithful in
structure, item order and bit offsets, not byte-exact (measured: the DualSense's real 273-byte
descriptor reconstructs to 467). `xinputhid` also filters that pad, and the captured shape is
the legacy DirectInput view. A byte-exact answer needs Linux hidraw.
* Why the Elite returned ZERO input reports across two runs (72 s and 90 s) while the DualSense
streamed fine on the same code path — untouched pad, or exclusive claim by the XInput
translator. Unresolved.
* Nothing here was built on Windows as a driver: `XBOX_RDESC` itself is UNCHANGED, so no
behaviour changes. The only edit to the driver is its provenance comment.
112 lines
5.1 KiB
TOML
112 lines
5.1 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 tool: pulls `hidapi`, a C library wanting libudev on
|
|
# Linux, which has no place in `cargo build --workspace` or on a CI leg with no pad attached.
|
|
"tools/hid-descriptor-dump",
|
|
]
|
|
|
|
# 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
|