enricobuehler
5219107177
`packaging/windows/drivers/*` has run `deny(unsafe_op_in_unsafe_fn)` +
`deny(clippy::undocumented_unsafe_blocks)` for a while, with `forbid(unsafe_code)`
on the modules that need no unsafe at all. The main workspace had no lint config
whatsoever, so nothing stopped a clean crate from quietly growing an `unsafe`, and
nothing distinguished the handful of genuinely-unsafe lines inside a 600-line
`unsafe fn` from the safe ones surrounding them.
Three things, all mechanical:
* `#![forbid(unsafe_code)]` on the eight crates that already contain zero unsafe
(`pf-driver-proto`, `pf-host-config`, `pf-paths`, the three clean clients, both
tools). These were clean by accident, not by contract; now they are clean by
contract.
* `unsafe_op_in_unsafe_fn = "warn"` workspace-wide. `unsafe fn` states a contract
the CALLER must uphold — it was never meant to switch off checking for the whole
body. Measured fallout is 300 sites on Linux, and they are concentrated: six
files carry all of them, while `punktfunk-core`, `pf-frame`, `pf-clipboard` and
`pf-vdisplay` are already at zero. `warn` (not `deny`) so the build stays green
while those six are worked down; it flips to `deny` once they are. This is also
the Rust 2024 default, so it pays off the edition migration early.
* `proc::current_uid()` replaces eight `unsafe { libc::getuid() }` blocks. Each
site had copied out the same SAFETY note verbatim, which is the tell: `getuid()`
is parameterless, always succeeds and touches no memory, so there is no contract
for a caller to uphold and no reason for the unsafe to be visible eight times.
One `unsafe` behind a safe wrapper, none at the call sites.
Verified: `pf-vdisplay` builds clean on Linux (Nobara) at zero E0133; the
macOS-buildable crates build clean locally. No behaviour change.
latency-probe
A glass-to-glass latency measurement tool (punktfunk-planning: implementation-plan.md §10): it renders a
timestamp/QR on the host, reads it back off the client's capture (or a photodiode, for true photons),
and tracks p50/p99 — so latency regressions are quantifiable rather than felt.
Status: scaffold. The measurement harness is stubbed out and not yet wired to a live pipeline. For latency numbers today, use the per-frame capture→…→reassembled percentiles the
probeclient reports over a realpunktfunk/1session.
cargo run -p latency-probe # from the repo root
Companion to loss-harness (FEC loss sweep).
Comparing against other clients (glass-timer.html)
Overlay-vs-overlay comparisons against other streaming clients are apples-to-oranges: their
stats end at decode / render-submit, while Punktfunk's display stage stamps the system's real
on-glass time — a ~2-refresh present tail every composited iOS/tvOS client pays but almost none
can measure. The only fair cross-client number is photon-to-photon, and glass-timer.html
is the host half of that measurement:
- Open
glass-timer.htmlfullscreen on the streamed host display (click for fullscreen). - Stream it, and film the host monitor and the client device in the same shot with a high-speed camera — an iPhone at 240 fps slo-mo gives ~4 ms resolution.
- Scrub the footage: in any single video frame, the difference between the two on-screen counters IS the glass-to-glass latency. Read ~20 spread-out frames for a p50.
- Repeat back-to-back per client (same host, game/scene, network) — Punktfunk, Moonlight, ….
Reading aids, designed to survive motion blur + re-encode: the binary strip encodes centiseconds as fat cells (read it when the last digits smear); the 100 ms sweep bar compares by eye for quick sub-10 ms estimates; the corner parity block flips every host frame — if it ever reads GRAY on the client, the client blended two host frames (repeat/tear tell). A button-to-photon variant needs no page at all: film controller + client screen and count video frames from the physical press to the visible reaction.