1510 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	bfed711921	Merge remote-tracking branch 'origin/main' into audio/latency-overhaul	2026-08-08 00:16:02 +02:00
enricobuehler	12a5318397	fix(audio): place audio with the picture instead of wherever the ring settles ... The host stamps `pts_ns` on every audio datagram and the client decoded it into `AudioPacket` — and then never read it. Video's `pts_ns` is used end to end (the presenter computes a true glass-to-glass `displayed + clock_offset − pts`), so audio free-ran at whatever depth its jitter ring happened to reach, video was presented on an independent path, and nothing ever compared them. The A/V offset was an accident of buffer depths: it moved whenever the ring ratcheted under underrun pressure, and it got WORSE every time video got faster, because a quicker decoder lowers the video leg and leaves audio's exactly where it was. That is what a field report on the Steam Deck heard as "the audio delay is way too high", and it is why shaving milliseconds off the audio budget had not helped. Video is the master. In a game streamer the video leg is the input-feel budget and must never be inflated to satisfy the audio clock, while audio tolerates small crossfaded corrections that are inaudible — and `crossfade_drop` already applies them. So audio moves: audio_e2e = (now + buffered_ahead + clock_offset) − pts_ns av_offset = audio_e2e − video_e2e (> 0 ⇒ audio behind the picture) `AvSync` smooths that with an EWMA, ignores what sits inside a deadband no listener can detect, refuses the implausible outright rather than clamping it (a wall-clock step must not steer the ring), and proposes a depth. Continuity outranks sync, always. `JitterPolicy::set_sync_target` only ever takes a REQUEST, clamped between the existing underrun-driven floor and the hard cap. A link whose jitter genuinely needs more buffer than the picture is away keeps its buffer and the residual is reported — sync can never starve the ring into dropouts. `None` is the default and reproduces the previous behaviour exactly, so the four client rings can adopt this one at a time without diverging. Two upstream defects found on the way, both prerequisites: * The host stamped `pts_ns` at ENCODE time, inside the loop draining an already-accumulated chunk, so every frame of a chunk carried near-identical timestamps describing when we got round to encoding. Harmless while nothing consumed it; a sync loop regulating against it would regulate against a fiction. It now comes off the capture clock. * The host did not pace. One capture callback hands over a whole quantum — 5 ms when the graph honours our ask, 21.3 ms on a VM, where stock PipeWire raises `min-quantum` to 1024 — and the loop drained all of it into back-to-back `send_datagram` calls. The wire carried a 4-5 frame burst then ~21 ms of nothing, and a ring can only absorb that by standing a burst period deep. Frames now leave on the audio clock, which costs no average latency. And the reason none of this was visible: `buffer_ms`/`target_ms` existed only as a `tracing::debug!` line, absent from `Stats`. On a Deck the client runs under Steam's `reaper` with stdout on a pipe nobody can read, so the one number identifying a deep ring was unobtainable on the device reporting the latency. The HUD now carries `audio buffer N ms · a/v ±N ms` — both, because a deep ring on a jittery link is correct and only the offset separates that from audio held late. The host also reports its negotiated quantum against the one it asked for, per capture open rather than once per process. Verified: 364 core + 40 presenter tests on Linux, clippy -D warnings clean on punktfunk-{core,host} + pf-{client-core,presenter}, fmt clean. New tests pin the safety invariant (sync cannot pull the target below the continuity floor on any preset), that `None` leaves the policy bit-identical, and that a device quantum exceeding the hard cap does not panic `Ord::clamp` inside a realtime callback. Android and Apple keep today's behaviour (the `None` default) until their presenters publish a video figure to align against; design/audio-latency- overhaul.md carries the plan.	2026-08-07 23:33:45 +02:00
enricobuehler	5a4305c072	merge: bring current main into the gyro correctness branch ... main moved ~60 commits while this branch was in progress, and one of them matters here: PR #88 (the phone-gyro mirror) landed, touching the same motion path. One conflicted file, `GamepadCapture.swift`, in three places — all of them the two changes meeting rather than disagreeing: - **Slot fields.** #88 added `motionSent` + `lastAccel` for its flush-parks-motion fix; this branch removed `lastMotionNs` with the 4 ms drop-throttle. Kept both decisions: the parking state stays, the throttle field goes. - **forwardMotion's head.** #88 added the mirror stand-down (`pad 0` yields while the phone speaks for it); this branch deleted the throttle guard. Kept the stand-down, dropped the guard. - **The send.** This branch converts into the DualSense report frame; #88 records what went out so `flush` can replay it beside a zero gyro. Both, with the recording placed AFTER the conversion — `flush` replays `lastAccel`, so it has to be the vector that actually went on the wire, or a still pad's gravity gets parked in the wrong axis. The two features compose exactly, which is worth stating because it is not luck: this branch gates motion capture on `hasRotationRate`, and #88 engages the phone mirror when `hasRotationRate != true`. They are complements — a pad either drives its own gyro or the phone mirrors for it, never both and never neither. Everything else auto-merged. Note `DeviceGyroRemapTests` is `#if os(iOS)`, so the macOS suite reports the same 215 as before the merge rather than gaining #88's six — checked, not assumed. Gates re-run against the merged tree rather than trusting either side's: Linux fmt + build + `clippy --locked --all-targets -D warnings` + punktfunk-core and pf-inject suites; Apple 215 tests and the iOS-triple typecheck; Android kit + app compile and tests. All green.	2026-08-07 19:34:22 +02:00
enricobuehler	d996449a82	fix(host/pads): a virtual pad at rest said it was in free fall ... G14, unblocked by the frame measurement in efb7f991 — the plan deliberately left this one alone until the up axis was known, on the grounds that a confidently wrong constant would be worse than an obviously wrong zero. It is known now. A virtual DualSense, DualShock 4 or Steam Deck that had received no motion reported acceleration `[0, 0, 0]`. That is not "no data": zero proper acceleration means free fall, which is a definite claim about the physical world and one that is never true of a controller sitting on a desk or held in someone's hands — both read 1 g up. Anything that interprets the accelerometer gets a confident wrong answer rather than a boring right one. It is worst exactly where it is least visible. A pad with no gyro at all — an X-Box controller forwarded as a DualSense, which is what "Automatic" does for anything not Sony or Valve — never sends motion, so it sits on that neutral for the entire session, telling every game that reads it that the controller is falling. `switch_proto` has always done this correctly on its own up axis, which is what made the gap visible in the first place. Which axis, and why it took a measurement. The wire is a unit passthrough into the virtual pad's report, so the wire's up axis is the pad's own, and on 2026-08-07 a real DualSense read over raw HID put `+0.997 g` on report axis 1 at rest, in a frame pinned the same session as (Right, Up, Backward). So `MOTION_NEUTRAL_ACCEL` is `[0, 10000, 0]` — NOT the z-up the notes had assumed from `switch_proto`'s documentation, which is why guessing would have shipped a backend confidently disagreeing with the hardware. The constant lives in punktfunk-core beside the units it is expressed in, and every backend derives from it rather than restating it. The Deck's neutral in particular goes through `steam_remap::motion_wire_to_deck`, the same rescale a real sample takes, so the neutral and the live path can never end up with two opinions about what 1 g is — its `hid-steam` resolution stays in exactly one place. The DS4 needs no separate change: it reuses `DsState`. `switch_proto` is deliberately NOT touched, and the test says so. It is a different device on a different driver, its up axis is its own, and nobody has measured its frame — aligning it to the DualSense for consistency would be the same unmeasured guess this commit exists to avoid, just in the other direction. Non-vacuity proven both ways rather than assumed. Moving the up axis to slot 2 (the old z-up assumption) fails on the wire constant itself, which is what makes the measurement load-bearing rather than decorative; reverting both neutrals to `[0, 0, 0]` fails on the DualSense assertion with the message naming the defect. Each backend is checked in ITS OWN units, because hard-coding "1 g" three times is how the halves of a unit contract drift apart. Gate (Linux CI image): fmt, build, `clippy --locked --all-targets -D warnings` across punktfunk-core / pf-inject / pf-client-core, and both test suites — green, with `Running tests/motion_contract.rs` and the new case's own `... ok` line observed in the log rather than inferred from a green exit (`cargo test` stops after the first failing binary, so a green-looking run can mean the contract test never executed at all).	2026-08-07 19:07:30 +02:00
enricobuehler	a8a4b11f5c	Merge pull request 'HEVC died at 720p and 1080p because we sized the DPB from the level's ceiling, not the stream's need' (#96) from fix/hevc-dpb-level-ceiling into main ... Reviewed-on: #96	2026-08-07 16:21:31 +00:00
enricobuehler	8805a18375	Merge pull request 'A damaged AV1 frame stops killing the whole client (and a BOM stops erasing every setting)' (#97) from worktree-rav1d-single-frame-context-abort into main ... Reviewed-on: #97	2026-08-07 16:20:54 +00:00
enricobuehler	e9ddc3c561	Merge pull request 'AV1 stops shipping half a frame' (#95) from worktree-av1-subframe-truncation into main ... Reviewed-on: #95	2026-08-07 16:19:28 +00:00
enricobuehler	8551e88fcb	merge: bring current main into the audio-substrate branch ... Two conflicts, both unions of independent removals/fixes: main fixed the same three install.rs SAFETY comments this branch fixed (main's phrasing kept), and the runner provisioning drops BOTH env lines — main removed PF_FFVK_VULKAN_INCLUDE (pf-ffvk is gone since the FFmpeg replacement), this branch removed VBCABLE_DIR (the retirement).	2026-08-07 17:49:50 +02:00
enricobuehler	bca63cd9ff	docs(client/video): name the upstream rav1d issue next to the workaround ... memorysafety/rav1d#1497, filed with the one-line fix and a reproducer that needs no capture — any AV1 stream with one temporal unit removed. Written down where the setting is, because the next person to read `av1_settings` and wonder whether the floor is still needed should be able to check rather than re-derive it.	2026-08-07 17:48:54 +02:00
enricobuehler	eb9203b115	fix(client/settings): a byte order mark stops silently erasing every setting ... `Set-Content -Encoding UTF8` writes a UTF-8 BOM, and every Windows how-to reaches for it, so `%APPDATA%\punktfunk\client-windows-settings.json` edited from a shell arrives with `EF BB BF` in front of the `{`. serde_json rejects that at byte 0 — correctly, JSON has no BOM — and `.and_then(|s| serde_json::from_str(&s).ok())` turned the refusal into `Default`. Every setting in the file, gone, with the file plainly correct on screen and not one word anywhere about why. Cost an hour on 08-07: a `codec: "av1"` edit was ignored and the client negotiated HEVC. The obvious suspects — the negotiation, the caps, the host — were all working exactly as designed. So the mark is stripped, which is what every other JSON consumer on Windows does. But the BOM is only the instance; the bug is the `.ok()`, which hides a trailing comma, a truncated write and a hand-edit typo just as completely. Those now cost one `warn!` naming the file and serde's own line and column. A file that cannot be READ at all is reported too, and for the same reason: PowerShell's `-Encoding Unicode` writes UTF-16LE, `read_to_string` rejects it as invalid UTF-8, and that lands in exactly the same hole. The RESULT is deliberately unchanged — `Default`, never an error. Nothing about streaming may hinge on a settings file being readable, and refusing to start because one is malformed would be a worse failure than the one being fixed. A missing file stays silent, because that is just first run. All three of this client's JSON stores share the loader, because all three had the identical line: the settings file, the known-hosts store (where a BOM silently unpairs every host) and the profiles catalog.	2026-08-07 17:45:38 +02:00
enricobuehler	32ff93199f	fix(client/video): a damaged AV1 frame stops killing the whole client ... The software rung aborted the process — not the session, the process — the first time a 4K AV1 stream lost a frame. Reproduced on .21 twice on 08-07, `SIGABRT` a few hundred milliseconds after "first frame decoded". It was never about 4K, and it was never our bitstream. rav1d 1.1.0 kills the process on ANY decode error while it holds a single frame context. `rav1d_submit_frame`'s `c.fc.len() == 1` branch calls `rav1d_decode_frame` inline; that always finishes in `rav1d_decode_frame_exit`, which does an unconditional `mem::take(&mut f.frame_hdr)` (decode.rs:4873); and then, only if the decode returned `Err`, the same branch re-enters a local `on_error` whose first act is `f.frame_hdr.as_ref().unwrap()` (decode.rs:4997) — on the `None` the teardown just left. The panic unwinds into `dav1d_send_data`, which is `extern "C"`, so it is `panic_cannot_unwind` → `abort()`: no `catch_unwind` at our call site, no rung demotion and no `NoSoftwareRung` refusal can catch it. The same code is in upstream `main` today, and 1.1.0 is the newest release, so there is no version to bump to. 4K was only where an error first HAPPENED. The CPU rung cannot keep up at 3840x2160 (35-39 fps against a 60 fps stream), so the receive backlog stopped draining, `pump::data` flushed it and jumped to live, and the next AU referenced frames nobody had decoded. libdav1d gives the identical verdict on the identical capture — 13 frames, then "Invalid data found when processing input" — and simply carries on. At 1080p the rung keeps up, nothing is ever flushed, no AU is ever damaged, and the same code ran for years without anybody seeing this. So the fix is to stop asking rav1d for the configuration whose error path is broken. `c.fc.len() > 1` never calls `rav1d_decode_frame` at all: it hands the frame to `rav1d_task_frame_init` and errors come back through `cached_error` / `task_thread.retval` as ordinary `EINVAL`s, which the pump already answers with a keyframe request. Measured, against the captured 4K stream: n_threads=8 max_frame_delay=1 -> n_fc=1 -> ABORT n_threads=1 max_frame_delay=1 -> n_fc=1 -> ABORT n_threads=1 max_frame_delay=2 -> n_fc=1 -> ABORT <- proves the rule n_threads=8 max_frame_delay=2 -> n_fc=2 -> 13 pictures, EINVAL, survives n_threads=8 max_frame_delay=0 -> n_fc=3 -> survives The third row is why `n_threads` grows a floor of two as well as the delay: `n_fc` is `min(max_frame_delay, n_threads)`, so one decode thread silently puts the whole thing back on the aborting path. That row is also what rules out the theory this investigation started with — pinning threads to 1 was the suspected trigger, and it makes things WORSE, so the tile workers are innocent and the single frame context is the entire defect. Two frame contexts would normally cost a frame of latency, and this does not, because `decode` now drains PAST the first `EAGAIN`. `rav1d_get_picture` only reaches its blocking `drain_picture` on a call whose own `drain` flag is already set, and that flag is set by the PREVIOUS `get_picture` and cleared by every `send_data` that carried bytes — so the first `EAGAIN` after a send does not mean "no picture for this AU", it means "ask again", and this AU's frame comes out of the second call. Stopping at the first `None` is what a single-frame-context reading of dav1d's API teaches, and it would have put the pipeline two frames behind while looking perfectly healthy. Measured over 14 temporal units at `n_fc = 2`: stopping at the first `None` produces nothing at all for units 0 and 1; draining past it produces one frame per unit from unit 0, at 20-42 ms per unit against `n_fc = 1`'s 21-53 ms. Not a trade — same cadence, slightly faster, because the tile workers overlap the drain. `Av1Software::new` then asks rav1d itself, through `dav1d_get_frame_delay`, what those settings actually bought, and refuses to open a decoder that would run with one frame context. That is not a restatement of the arithmetic: it is `get_num_threads`' own answer, so it stays right if rav1d's derivation changes. It is there because the failure it guards is uniquely quiet — an edit that reinstates `n_fc = 1` costs nothing at build time, nothing in the tests and nothing on a clean link, and then kills the client the first time a frame arrives damaged. Losing the rung is recoverable; `abort()` is not. On glass, .21, 35-second sessions, `PUNKTFUNK_DECODER=software`: 4K60 AV1 before: SIGABRT on the second frame, every run after: exit 0, 0 panics, 35-39 fps, 1204 frames, decode_failed=0, and 13 decode errors recovered from across 17 backlog flushes — the exact condition that used to abort, survived thirteen times in one session 1080p AV1 after: 40 fps, decode p50 2.2 ms (2.1 ms before the change) What this does NOT buy: rav1d has other `unwrap()`s, and because its whole public surface is dav1d's `extern "C"` ABI — every internal `rav1d_*` entry point is `pub(crate)` — no in-process guard can turn one of them into anything but an abort. This removes the one we hit and can prove; it does not make the CPU rung panic-proof, and the evidence table says so. Reported upstream with a self-contained reproducer: the in-tree `test-25fps.ivf.av1` vector with one temporal unit dropped aborts rav1d at `n_fc = 1`, survives at `n_fc = 2`, and libdav1d decodes it with 145 error reports and no crash.	2026-08-07 17:45:21 +02:00
enricobuehler	0ee690f8bc	fix(client/hevc): the DPB we demanded was the level's ceiling, not the stream's need ... A punktfunk client streaming HEVC from .21 (RTX 5070 Ti) refused every access unit with "stream needs 17 DPB slots, device caps at 16", flushed, waited for an IRAP, got a fresh IDR that needed 17 too, exhausted the decode ladder and reconnected with HEVC excluded. On a build with no software HEVC decoder — there is no permissively licensed one — that is not a slower path, it is losing the codec. The host was blameless. Reading the SPS it actually emitted: general_level_idc 153 (L5.1 High, which NVENC autoselects at hevcConfig.level = 0 because a 130 Mbps target does not fit L5.0's 100 Mbps ceiling) and sps_max_dec_pic_buffering_minus1 = 5 — six pictures, RFI_DPB references plus the current one. Six, at every resolution. That is already the minimum the encoder can honestly declare, and the only host-side lever, the level, cannot be lowered without signalling a bitrate the stream exceeds. There was nothing to fix there. dpb_limit was reading equation A-2 instead. A-2 is a CEILING on what an SPS may signal — 7.4.3.2.1 constrains sps_max_dec_pic_buffering_minus1 to 0..=MaxDpbSize-1 — not a statement of what a stream needs, and it branches on picture size against the LEVEL's MaxLumaPs. At 1080p the coded 1920x1088 = 2 088 960 luma samples fall under MaxLumaPs(L5.1) >> 2 = 2 228 224, taking the first branch for min(4 * MaxDpbPicBuf, 16) = 16. max(A-2, buffering) then reported 16 where the stream had asked for 6, the backends added one slot for the picture in flight, and 17 is one more than NVIDIA's maxDpbSlots. A resolution sweep on the box drew A-2's branch table exactly, and it is the two commonest streaming resolutions that lost the codec: 720p 1280x720 = 921 600 branch 1 -> 16 frames, 17 slots 82 refusals, HEVC dropped 1080p 1920x1088 = 2 088 960 branch 1 -> 16 frames, 17 slots 41 refusals, HEVC dropped 1440p 2560x1440 = 3 686 400 branch 2 -> 12 frames, 13 slots clean 4K 3840x2176 = 8 355 840 else -> 6 frames, 7 slots clean, decode 1.9 ms One host, one level, one six-picture requirement. Only which branch the picture size landed in decided whether HEVC worked. That is also why this hid for so long: 4K was the resolution it was exercised at, and 4K is the one size that falls through to the honest answer. H.264 escaped for an unrelated reason — its own level-derived ceiling happened to land at 13 for 1080p L5.0 and 5 for 4K L5.2 — but it is the same shape of derivation and would fail the same way if NVENC ever picked a higher level for a smaller picture. So dpb_limit now returns the stream's own sps_max_dec_pic_buffering_minus1 + 1, capped at 16. That is not a workaround, it is what the number means: it is exactly the bound C.5.2.2's fullness clause bumps against, and A.4.1 bounds the total RPS entries by the same value, so `buffering` pictures hold `buffering - 1` references plus the current one with nothing left over. The max() that produced the 16 was written to be generous to malformed streams — "storing their pictures beats erroring the AU" — but it never did that either. Dpb::needs_bumping (C.5.2.2) already keys on the signalled buffering, not on max_num_pics, so a stream referencing more pictures than it declared was ALREADY being bumped below its own declared depth before every store. The widened limit bought no tolerance at all; all it ever did was over-allocate hardware surfaces, by ten pictures per session at 1080p, and on NVIDIA take HEVC away entirely. The fix moves 720p and 1080p onto the pool shape 4K has been running in the field all along (7 slots, 6 references), so it is not a new operating point — it is the one already proven. max_active_references drops from 15 to 6, still above the 5 an RFI_DPB stream can name. The per-AU level gate in pf-vkdecode reads plan.picture.level_idc directly, so dropping A-2 out of NegotiationInfo costs no sensitivity to a mid-stream level change. Two regression tests pin the arithmetic from both ends, because either end drifting back reproduces this: - h265: the field SPS synthesized byte for byte on the fields that matter must plan 6 frames / 7 slots, all four resolutions must agree because the stream does, and every depth the envelope gate admits must leave room for the picture in flight. The one honest residue is pinned too and deliberately left refusing: A.4 does let a conforming stream declare a full 16-picture DPB, and 17 slots genuinely do not fit 16, so that stream is still refused rather than decoded with too few slots and silently corrupted references. - pf-encode: RFI_DPB + 2 <= 16, guarding the producer end. RFI is a real latency win and this does not cap it at today's value — there are nine slots of headroom — it just stops it being raised past the point where clients can no longer decode us at all.	2026-08-07 17:34:17 +02:00
enricobuehler	6348334eff	docs(client/video): the evidence table stops saying AV1 never decoded ... Two of its notes became false the moment the host stopped truncating AV1. native D3D11VA / AV1 said "NEVER decoded a frame on any hardware". It has now decoded 4K60 on an RTX 3500 Ada — and the same run is why the note matters: its warn line named the rung as unproven moments before it failed 72 access units running with "reference picture N holds no DPB slot". That was the host shipping half of every frame, not the rung, so the M7 wiring was right all along. It stays UNVERIFIED regardless. `verified` gates `native_rung_admitted` — whether `auto` may pick this rung ahead of Vulkan Video — and one 25-second session with no frame-hash parity and no soak does not buy that. Promoting it wants a deliberate gpu_parity-style run. The note now says what is true instead of what is convenient. software / AV1 said rav1d had "CPU unit tests only". rav1d has now run on glass: 1080p AV1 decodes, and 4K ABORTS THE PROCESS. It takes an internal error path and panics inside its own on_error (rav1d 1.1.0 decode.rs:4997, unwrap on a None frame header); the panic crosses the extern "C" boundary in dav1d_send_data, so it is panic_cannot_unwind and no rung demotion or NoSoftwareRung refusal can catch it. libdav1d decodes the same 4K stream 715/715, so this is rav1d's own defect and is recorded where the next person to reach that rung will see it.	2026-08-07 17:06:35 +02:00
enricobuehler	ebc2f1cf92	feat(host/audio): the minted microphone returns to tier-0 — pitch-true ... The revert un-reverts, on measurement: with the per-direction stamp sets (render = the pad-proven PCM16-device/float-mix stereo split, capture = device-format only), micpitch reads 440 Hz in as 440 Hz out at exact peak. The octave-low voice was the driver DEFAULT endpoints disagreeing (stereo render vs mono capture), never a raw-crossing design. The user called the wrong verdict — the pad program 4ch success was the counter-evidence that reopened the case.	2026-08-07 16:53:48 +02:00
enricobuehler	c16e07d746	fix(encode/nvenc): AV1 stops shipping half a frame ... Every 4K AV1 frame this host encoded reached the wire truncated to its first tile, and had since AV1 was wired up. Measured on .21 (RTX 5070 Ti, 4K60, split AUTO): each access unit carried a frame header declaring two tile rows and a single Tile Group OBU with tg_start = tg_end = 0, so libdav1d rejected 835 of 836 AUs with "Error parsing frame header". NVIDIA's hardware decoder accepts the truncated stream, which is why native Vulkan Video looked healthy at 60 fps while both conformant software decoders — rav1d in-tree and libdav1d out-of-tree — refused every frame and clients fell to a black screen. The two halves of sub-frame readback are armed by different conditions. build_init_params arms the WRITER (enableSubFrameWrite + reportSliceOffsets) from subframe_on alone; the chunked READER additionally requires slices >= 2, and resolve_slices returns 1 for AV1 unconditionally — before the PUNKTFUNK_NVENC_SLICES override is even read, because AV1 partitions via tiles rather than slices. So an AV1 session asked the driver to publish its output tile by tile and then took only the first tile with one blocking lock_bitstream. resolve_split_subframe — the one arbitration point both direct-SDK backends already call — now disarms sub-frame for AV1 and returns split_mode untouched, so AV1 keeps every engine split encode gives it. Arming the reader instead is not a drop-in alternative: poll_chunk cuts at bitstreamSizeInBytes on the reasoning that "slices are contiguous Annex-B", which AV1's OBUs are not. With sub-frame disarmed and split still AUTO, the same session decodes 654/654 frames clean through libdav1d. The test that pinned this as correct (av1_untouched, "both features are legal together") is replaced by one that pins the disarm, and by one that checks the reader's gate against the writer's — the comparison nothing made. The Linux latch comment claiming the two "can't disagree" is corrected; that claim is what made this invisible.	2026-08-07 16:50:17 +02:00
enricobuehler	52cd42e911	fix(host/audio): capture endpoints get the device format only ... Live bisect on a fresh endpoint: the mix/host format keys are RENDER-engine properties — stamped onto a capture endpoint they broke its shared-mode graph (IsFormatSupported reported 2ch/48k OK while Initialize failed 0x88890008 on a once-stamped fresh endpoint; unstamped it opened fine, S3). The capture now gets ONLY the device-format key — the knob mmsys.cpl itself writes — declaring the stereo the pins actually accept.	2026-08-07 16:49:15 +02:00
enricobuehler	5c4969fd6b	fix(client/pads): the gyro cut-off asked about the session, not the pad ... Supersedes the check 77797a9e shipped an hour ago. The suppression, the log-once, and the "unknown must not suppress" rule all stand; the field it reads does not. 77797a9e read `Welcome.gamepad` — the backend the host resolved for the SESSION — and stopped sending motion when it had no motion plane. But the host does not build pads from that. It builds each virtual device from that pad's own `GamepadArrival` (`Pads::set_kind`) and falls back to the session default only for a pad that never declares one, which is precisely why `declared_kind` exists and why its doc comment says an explicit setting has to be re-declared per pad. So the check had a false negative, and it is an ordinary living-room setup. Under "Automatic" the Hello carries the ACTIVE pad's kind (`auto_pref`), so a couch with an X-Box pad on slot 0 and a DualSense on slot 1 echoes Xbox360 — while the host, reading pad 1's arrival, builds it a DualSense with a working motion plane. The old check read the echo, saw no motion plane, and killed pad 1's gyro. That is the exact failure 77797a9e's own commit message names as the worse of the two ("a false negative kills working motion"), introduced by the fix for the other one. The question is per pad, so the slot now carries what it declared, beside the physical `pref` it already held. The two are deliberately separate fields answering different questions: `pref` is the controller in the user's hands, which is what the local feedback paths must keep reading, and `declared` is the one the host is pretending to have. Three facts decide the predicate, and they are written out in `pad_motion_reaches` rather than at the call site because all three clients need the same reasoning: - the echo is not this pad's answer when the pad declared something else; - the host FOLDS what it cannot build — a Switch Pro on Windows, any UHID backend on a host whose /dev/uhid is unusable — and nothing client-side can predict it; - but the echo IS one observed sample of that fold, for the kind the Hello asked about, so it is authoritative for a pad that declared exactly that. Hence: trust the echo when declared == asked, else fall back to the declaration. That keeps both motivating cases — a generic pad under Automatic (declares X-Box 360, suppressed, the sweep's H5c) and an explicit Switch Pro folded to X-Box 360 by a Windows host (declared == asked, so the echo catches it, H5d) — where either field alone gets one of them wrong. `requested_gamepad` is kept on the client next to `resolved_gamepad` for this: the pair is what makes the echo usable per pad, and a lone field would only tempt the next reader back into the session-level question. The residual gap is a pad whose declared kind differs from the session's AND gets folded: we keep sending and the host keeps dropping. That is the direction to be wrong in, and it is what the session-level check was worth in the first place — wasted datagrams, not a dead gyro. Non-vacuity proven both directions rather than assumed. Reverting to `resolved.has_motion()` fails on the mixed-pad row; reverting to `declared.has_motion()` (no echo at all) fails on the Switch-Pro-on-Windows row. Each case in the table is a session someone can actually sit down to, and the comment on each says which of the three inputs decides it. Gate (Linux CI image, pf-lxcheck2): fmt, `build -p punktfunk-core`, `build -p pf-client-core`, `clippy --locked --all-targets -D warnings`, and both test suites — green, with the new case observed in the run's own `... ok` line rather than inferred from a green gate, and pf-client-core's 163 unchanged.	2026-08-07 16:46:06 +02:00
enricobuehler	8c274d6256	fix(host/devtest): the probe asks stereo — its mono ask WAS the unopenable endpoint ... Measured resolution of the 0x88890008 mystery: IsFormatSupported said the capture accepts 2ch/48k shared while Initialize kept failing — because the probe itself had switched to a MONO ask for frequency counting, and this stack does not bridge channel counts on capture even under autoconvert. Every unopenable-endpoint verdict after that switch was the instrument, not the endpoint. Stereo ask restored; crossings counted on channel 0.	2026-08-07 16:44:01 +02:00
enricobuehler	16e506f943	feat(host/devtest): audio-probe micpins — the driver-capability map ... Exclusive+shared IsFormatSupported across {1,2}ch x {16,32}bit x {44.1,48,96}kHz on both minted mic pins. Interrogates the DRIVER, bypassing every endpoint-store stamping question: what the pins truly accept decides whether the mic leg has any coherent configuration, and whether an exclusive-mode mono open is an escape hatch. (The pad program made its own breakthrough with exactly this instrument on the sibling SSS driver.)	2026-08-07 16:39:48 +02:00
enricobuehler	2eed9823e5	fix(host/audio): the mic pair gets the pad-proven coherent stereo stamp set ... The user challenged the format-locked-pins verdict, and the pad program is the counter-evidence: it hit the SAME 0x88890008 unopenable-endpoint signature and cured it with a COHERENT stamp set, after which the same driver family served 4ch happily. This branch previous attempts were contaminated twice over — a float device-format (the pad bisect proved the split must be PCM16 device / float mix+host) and no AudioEndpointBuilder restart (Restart-Service Audiosrv never touches its dependency, so endpoint configs were never rebuilt). Both mic endpoints now get one identical coherent stereo set; the octave-low hypothesis shifts from "raw crossing by design" to "the two endpoint stores disagreed (stereo render default vs mono capture default)".	2026-08-07 16:33:20 +02:00
enricobuehler	cc53b3d6b0	fix(host/audio): unwire the minted microphone — the driver mic path is unusable ... Final pitch-probe verdict on the SSM driver pair: the render pin is stereo-only, the capture pin mono-only (stamping either differently makes the endpoint unopenable), and the crossing between them is a RAW byte pass — so voice fed through the render endpoint reads back an octave low and no format stamp can fix it. S3 peak-based PASS = false pass; per the design doc revert clause the mic falls back to the name ladder (a virtual cable), pending the user re-decision. The SPEAKERS substrate keeps tier-0 (no driver crossing — a plain engine loopback tap, measured clean). minted_ids() publishes speakers only; the mic endpoints stay minted and recorded (provisioned()) for the micpitch probe and a possible future non-render transport, and their format stamps now pin each side to its pin one true format — healing the endpoints this branch earlier mis-stamped.	2026-08-07 16:06:56 +02:00
enricobuehler	5922cbe325	fix(host/audio): the minted mic pair declares stereo on BOTH sides ... Second measurement round: the driver render pin is STEREO-ONLY — the mono render stamp turned the endpoint unopenable (0x88890008 on every open, the incoherent-stamp signature the pad program documented). Since the crossing is raw, the coherent choice inverts: the CAPTURE side now declares the stereo float stream that actually crosses (fixing the octave-low voice), and the render has its stereo float default stamped explicitly — pinning the pair AND healing any endpoint a previous build left mono-stamped.	2026-08-07 16:01:39 +02:00
enricobuehler	ed98814145	fix(host/audio): the minted microphone renders MONO — voice was an octave low ... Measured with the new pitch probe: 440 Hz into the minted mic render came back as 220 Hz off its capture side. The driver forwards the render stream RAW into its mono capture, so a stereo-declared render (the driver-default we inherited) turns every stereo frame into two mono samples — half speed, octave down, exactly the field report. The mic render now gets a coherent MONO 48 kHz format set stamped alongside its name (PCM16 device format + float mix/host formats), making the engine downmix before the driver crossing. The mic pump keeps pushing stereo; shared-mode autoconvert handles the rest.	2026-08-07 15:57:19 +02:00
enricobuehler	0cf76af0c2	feat(host/devtest): audio-probe measures pitch, not just peaks ... Field report through the minted microphone: voice plays back an octave low. Peaks are pitch-blind — S3 passed while a potential half-rate link hid in the numbers (288k samples fits both the honest and the half-speed story). Every probe measurement now estimates the dominant frequency by zero crossings over the signal span, and `audio-probe micpitch` runs the decisive experiment against the LIVE minted pair: 440 Hz in, frequency out — ~440 = pair innocent, ~220 = the stereo render stream is forwarded raw into the mono capture.	2026-08-07 15:53:00 +02:00
enricobuehler	b166c53cc2	fix(vkdecode): a refused device says what the refusal costs, and about which format ... Three things the Intel Arc measurement showed were wrong or unhelpful in the refusal path. The message named NV12 whatever the stream was. A Main 10 session refused over P010 was told about NV12, which sends the reader to look up the wrong format's support. Both variants now carry the format the driver's own entry reported. A missing SAMPLED now says what it costs. "does not advertise usage SAMPLED" is accurate and tells a field reporter nothing: the consequence is that no shader can read this device's decoded pictures, so the zero-copy path cannot exist on it at all — which is a different conversation from a device that is merely slower. The line points at --probe-decode for the driver's own words. And the probe's second opinion no longer claims to be one. Measured on both vendors, vkGetPhysicalDeviceImageFormatProperties2 answers "creatable" for combinations the video-format query rejects — on NVIDIA too, for SAMPLED alone, which is not a legal video image usage at all. So it does not honour the chained profile list and must not be read as permission; it is still printed, because otherwise everyone who reads a refusal asks the question again, but it is labelled as not authority. Also names the three video ENCODE usage bits, which NVIDIA advertises on decode pictures and the probe was printing as "unrecognised 0xC000".	2026-08-07 15:44:07 +02:00
enricobuehler	c06ee55b61	diag(vkdecode): --probe-decode reports what the driver says about video images ... The Intel Arc refusal moved one step down the caps query and stopped again: the coincide NV12 entry does not advertise SAMPLED. That sentence is punktfunk's, not the driver's, and the last two times a conclusion was drawn from a sentence of ours the conclusion was wrong. So --probe-decode now prints the driver's own answers instead. For every profile the client can negotiate (H.264 High, H.265 Main and Main 10, AV1 Main 8- and 10-bit) it asks vkGetPhysicalDeviceVideoFormatPropertiesKHR in six usage combinations — the three the image pools really create with, plus DPB|DST without sampling, SAMPLED alone and DST alone, which are what localise a refusal to a half. Each answer is printed as the driver gave it: format, usage and create flags named AND in hex with unrecognised bits called out, image type, tiling. A failed query prints its VkResult rather than vanishing into an empty list. It goes through pf-vkdecode's own query rather than a copy of it, which meant splitting query_formats into a physical-device form — the call never needed the VkDevice the old signature demanded. VideoFormat gains imageType and imageTiling to carry the whole record; VUID-VkImageCreateInfo-pNext-06811 compares both for equality, so they were being assumed rather than read. And because a driver that under-reports usage would be indistinguishable from one that genuinely lacks it, the probe asks a second, independent question — vkGetPhysicalDeviceImageFormatProperties2 over the same profile list — and prints it only where the two disagree. A disagreement is the finding. No behaviour change to any decode path: derivation reads the same fields it did.	2026-08-07 15:34:12 +02:00
enricobuehler	7993386900	feat(host/audio): the minted endpoints get their names — 'Punktfunk Speakers/Microphone' ... Field-measured necessity, not cosmetics: unstamped, the minted instances read 'Lautsprecher (2- Steam Streaming Microphone)' and even the box's owner picked the wrong device out of the Sound settings zoo (as did the S1 probe's name match before it). The provider now stamps device-desc + device-name through the pad program's proven machinery — write_stamps/ stamps_served, extracted from the pad-only stamp functions — with the same store-first/registry-fallback routes and settle/re-pass discipline. Names only: a wider stamp set makes AudioEndpointBuilder re-mint the endpoint under a new GUID (measured on pads). Stamping is best-effort (SYSTEM ACL route); the wiring never depends on names — identity stays the recorded id.	2026-08-07 15:33:52 +02:00
enricobuehler	ca667cb79a	fix(vkdecode): the pNext order decided which struct got the decode caps ... Intel Arc never used Vulkan Video decode on Windows. The rung refused every session with "driver advertises neither DPB_AND_OUTPUT_COINCIDE nor DISTINCT" and fell back to D3D11VA — and that refusal was ours. vkGetPhysicalDeviceVideoCapabilitiesKHR was called with the codec capability struct chained BEFORE VkVideoDecodeCapabilitiesKHR (push_next prepends, so the chain was caps -> h265_caps -> decode_caps). On Arc/Windows 101.8724 the driver fills those two by POSITION, not by sType, and returned them SWAPPED. Measured, on glass, both ways: before: decode_flags_raw=12 max_level_idc=1 after: decode_flags_raw=1 max_level_idc=12 12 is STD_VIDEO_H265_LEVEL_IDC_6_2 and 1 is DPB_AND_OUTPUT_COINCIDE. We were reading an H.265 level as a decode-capability bitmask; 12 contains neither 0x1 nor 0x2, so the check concluded the device had no DPB mode. It had one all along. The base struct was fully populated throughout — 15 DPB slots, 8192x8192 max extent — which is what gave the lie away: a driver that answers in that much detail is not declining. NVIDIA and RADV dispatch by sType and do not care about the order, which is exactly why the fleet stayed green and this reached the field. Both orders are spec-legal for us to write; only one survives a driver that assumes the conventional one, and the conventional one — decode caps first, as every Vulkan sample writes it — is now what all three codecs use. ⚠ This does NOT yet give the Arc Vulkan Video. It moves the refusal one step down the same function: the device advertises only COINCIDE (no DISTINCT), and its NV12 coincide entry does not advertise SAMPLED usage, which the zero-copy presenter path needs. Whether that is a second bug of ours or a real Intel constraint is not yet established, and this commit does not claim it either way. Found because the user disbelieved my "Intel driver bug" conclusion. He was right: I had reasoned from our own error message, which is the same circularity the caps logging added in fb1a0a61/a183cac8 now exists to break. Gates: fmt clean; clippy -D warnings; 187 pf-vkdecode tests. The GPU parity legs that cover this code cannot run here (no GPU on the build host) — the evidence is the on-glass A/B above.	2026-08-07 15:07:48 +02:00
enricobuehler	a183cac8aa	diag(vkdecode): log maxLevelIdc beside the decode flags ... The Arc returned decode_flags=0b1100 = 12 with a fully populated base struct (15 DPB slots, 8192x8192 max extent). Neither COINCIDE (0x1) nor DISTINCT (0x2) is set, and 0x4|0x8 are not defined for that field at all — but 12 IS STD_VIDEO_H265_LEVEL_IDC_6_2, and VkVideoDecodeCapabilitiesKHR and VkVideoDecodeH265CapabilitiesKHR have identical layouts (sType, pNext, one u32). So the suspicion is that we are reading H.265's maxLevelIdc where the decode flags belong. Logging both settles it: if max_level_idc comes back as 1 or 2 the two structs are crossed, and the refusal is ours rather than the driver's.	2026-08-07 14:55:27 +02:00
enricobuehler	fb1a0a61e9	diag(vkdecode): log the driver's video capabilities verbatim ... Nothing in the caps module logged anything, so when a device refused with "advertises neither DPB_AND_OUTPUT_COINCIDE nor DISTINCT" there was no way to separate two very different situations that present identically as a zero: the driver filling the chain and genuinely declaring no DPB mode, versus our own pNext chain never reaching VkVideoDecodeCapabilitiesKHR at all. Printing the BASE VkVideoCapabilitiesKHR beside the decode flags is the discriminator. A populated max_dpb_slots next to decode_flags: 0 means the driver traversed the chain and answered; zeros across both mean the query never landed and the refusal is ours, not the driver's. Raised by the Intel Arc result on .221, where I concluded "driver bug" on the strength of our own code's report — which is precisely the circular reasoning this line exists to break.	2026-08-07 14:50:08 +02:00
enricobuehler	c34e1412fb	fix(client): a decoder pin with a stray space was silently ignored ... Found on glass, and it cost a whole session to find. PUNKTFUNK_DECODER was read untrimmed, so "native-vulkan " — ONE trailing space — matched no arm of native_vulkan_gate, fell through to `auto`, and on an Intel box `auto` takes d3d11va first. The operator's pin never ran and NOTHING said so. Read against a log, that is indistinguishable from the rung being refused for a hardware reason, which is precisely the ambiguity the rest of this module's logging was just rewritten to remove. The space is not exotic. A Windows .cmd produces it for free: `echo x>> file` keeps the space before the redirect, so every line written that way carries one. PUNKTFUNK_VK_ADAPTER already trimmed; this did not, and the inconsistency is what made it invisible — the GPU override obeyed while the decoder override did not. The rule now lives in one pure function, resolve_decoder_pref, called by BOTH readers. decode_pinned_to_software had the identical untrimmed expression, and its own doc comment says a second reading of the same two inputs is a second place for them to drift — fixing one and not the other would have proved it right. Whitespace-only counts as ABSENT rather than as a pin to "", because an exported-but-empty variable means "no override" and "" is a value the gate happens to accept. Tested as a pure rule (no process environment), including the end-to-end leg that matters: the trimmed pin reaches native_vulkan_gate and is admitted. Like the create-array tests in dee97e89 its before-state is a compile error rather than a failing assertion, because the function is new — what it guards going forward is real, and an editor who drops the trim fails it. Gates: fmt clean; clippy -D warnings over pf-client-core, punktfunk-client-session and pf-presenter in the Linux container; 164 pf-client-core tests.	2026-08-07 14:34:59 +02:00
enricobuehler	cbfa03b7ad	docs(host/pads): the SC2's bInterval is already 1 kHz — don't "fix" it to 250 Hz ... Working G14/G18 turned up two sweep findings that do not survive contact with the code. Neither is implemented; one is now guarded. The 2026-08-07 sweep read the Triton (Steam Controller 2) usbip endpoint's `bInterval: 1` as 125 µs — an 8 kHz duplicate storm — and the plan's G14 says to raise it to 4 "like the Deck". That reading assumes a high-speed device, where bInterval is the 2^(n-1) × 125 µs exponent. Both Triton devices declare `UsbSpeed::Full`, and on a full-speed device the field is a plain frame count in milliseconds: 1 means 1 ms, which is the 1 kHz the existing comment claims. Raising it to 4 would mean 4 ms — a 4× cut to the motion rate a passed-through SC2 delivers, in the name of fixing a problem it doesn't have. The endpoint now carries the reasoning so the next reader doesn't repeat it. G18's first bullet ("bound/rate-cap the host's rich-input channel; motion is unbounded") is stale rather than wrong — it was true of the tree the sweep read. Current main already routes rich input, motion included, through a 1024-deep `sync_channel` whose `offer()` helper `try_send`s and drops on full, ending the loop only on Disconnected. That is the same bounded-queue pattern the mic plane adopted for security-review S6. Nothing owed. G14's remaining bullet — DS/Deck neutral accel should read 1 g on the up axis instead of 0 g free-fall — is deliberately NOT done here. Which axis is up is precisely what G16's on-glass session measures: `switch_proto` documents the wire as z-up and its neutral ships +Z, but the Deck's kernel negates Z/RZ, so guessing would leave one backend confidently disagreeing with another. A wrong constant is worse than the current obviously-unset 0. Gate: fmt, build, clippy --all-targets -D warnings, and the test suites — green.	2026-08-07 14:00:30 +02:00
enricobuehler	77797a9e20	feat(client/pads): stop streaming gyro into a session that cannot receive it ... G8 of the gyro program, SDL-client half. The `Welcome` has always carried the backend the host actually RESOLVED, which is not necessarily the one the client asked for — Auto lands on Xbox 360 for anything not Sony/Valve/Xbox, and a Switch Pro on a Windows host folds to X360 too. No client read the field. So a player with an 8BitDo, or a Switch Pro on Windows, got a controller whose gyro did nothing, with nothing anywhere saying why: the client shipped ~250 Hz of Motion datagrams and the host parsed and discarded every one. `GamepadPref::has_motion()` answers whether a backend has a motion plane at all. The SDL client checks it on the first gyro sample: it logs one line naming the resolved backend and pointing at the fix (pick a DualSense-class controller type), then stops sending. Once per slot, not per sample — this path runs at the pad's sensor rate. `Auto` deliberately answers true. It means "unknown" — an old host that omitted the echo, which may well have resolved a DualSense — and suppressing motion on unknown would silently break working gyro, a worse failure than sending datagrams nobody reads. The predicate is an exhaustive match so a new backend has to state its answer rather than inherit one, and a table test pins both halves: a false negative kills working motion, a false positive keeps the void open, and both are silent. Owed: the plan wants this surfaced as a one-line UI hint, not just a log line. Apple already stores `resolvedGamepad` and Android needs the plumb; neither is done here, and both want their own gate. Gate (Linux CI image): fmt, build, clippy --all-targets -D warnings, and the test suites — green, with the new capability test observed running.	2026-08-07 13:52:27 +02:00
enricobuehler	c0f8f051c3	fix(client): the probe printed a device index the env var does not take ... --probe-decode printed its DISPLAY position and called it the PUNKTFUNK_VK_DEVICE value. It is not. pick_device resolves that variable against the RAW vkEnumeratePhysicalDevices order (setup.rs, `devices.get(i)`) BEFORE any ranking runs, while the probe sorts discrete-first for readability. Those two orders disagree precisely on the hardware this flag exists to diagnose. pick_device's own comment records why the ranking is there: "enumeration order puts the iGPU FIRST on some hybrids (observed: Ryzen iGPU ahead of an RTX dGPU)". So on a hybrid laptop the number the probe printed for the iGPU could well be the number for the dGPU — a diagnostic handing out an actionable value that selects the other GPU, which is worse than printing none. Measured on the Arc + RTX 3500 Ada laptop, which is also where the first output went out with the wrong claim in it: three adapters, and the same Arc iGPU enumerated TWICE. So AdapterDecode now carries the raw enumeration index, captured before the sort, and the printer uses it; the "default presenter" marker stays on the first LISTED entry, because sorted-first is what pick_device lands on when nothing overrides. The duplicate is why the trailing hint names PUNKTFUNK_VK_ADAPTER as the safer knob and admits its limit: two adapters sharing a marketing name cannot be told apart by it, and a name match resolves to whichever enumerates first. The hint also states the thing this whole output invites a reader to get wrong — that a capable GPU in the list does not mean the decoder will use it, because Vulkan Video decodes on the presenter's device and PUNKTFUNK_DECODER does not move the presenter. Gates: fmt clean; clippy -D warnings on punktfunk-client-session and pf-presenter.	2026-08-07 13:52:23 +02:00
enricobuehler	ce5047f3ad	fix(host/pads): the Windows driver stops halving motion and stops serving torn reports ... G6 + G15 of the gyro program. G6 — the UMDF gamepad driver's input path. Its timer ran at 8 ms and completed one pended READ_REPORT per tick, so a game could observe at most ~125 Hz while clients stream motion at ~250 Hz: every other sample was overwritten in the slot before anything read it, and the ones that survived carried up to 8 ms of extra latency. For gyro, a dropped sample is not a dropped frame — it is rotation that never reaches the game. The timer now ticks at 2 ms (about a real DualShock 4's Bluetooth cadence). Only the cheap half runs on every tick: read the input slot, complete one pended read. The channel handshake and the health marks stay on their historical ~8 ms, because they cost more, nothing wants them faster, and `driver_heartbeat`'s documented "+1 per ~8 ms tick" is what the host reads as liveness. The same slot is a single unqueued buffer that both sides touch without a lock, so a driver read landing mid-copy handed the game a report that was half the previous frame and half the next. For a button that is a one-tick glitch; for motion it is a spike in angular velocity, which an integrator turns into aim movement. `PadShm` gains an `input_gen` seqlock (v2.3, carved from reserved space inside the v2 legacy region): the host takes it odd, fences, writes the 64 bytes, and stores it even; the driver samples it either side of its read and retries once. The old code's own comment called this out as a known residual — it is now closed rather than documented. Version posture matches the ring's, with one simplification: no capability stamp is needed, because an old host never writes the field and a constant 0 is indistinguishable from "no write in flight", so a new driver against an old host behaves exactly as it does today, and an old driver ignores the field entirely. The Steam Deck write path had neither the seqlock nor even the trailing Release its DualSense sibling carried; all three Windows backends now publish through one `publish_input`. G15 — motion-cadence observability. The host already computed the measurement a "gyro feels floaty" report needs (client inter-arrival percentiles), but kept ONE global accumulator, so two motion-capable pads in a session interleaved into each other's gaps and produced a number describing neither. It also sat at `debug` behind a `tracing::enabled!` check, so a field log arrived with nothing in it and the only way to get the measurement was to ask for a re-run. Now per-pad and always on, summarized at `info` when the session ends — the moment a field report is being written. It costs one subtraction and one array increment per sample: percentiles come from a fixed log2 histogram instead of a growing sorted Vec, so there is no allocation, no per-window sort, and no way for a client streaming as fast as the link allows to make the instrument expensive. Percentiles are reported as bucket upper bounds (`_le`), which is a factor-of-two answer to a question whose answers are orders of magnitude apart. Gaps of 500 ms or more are counted as stalls rather than folded into the percentiles — an interruption is not a cadence, and averaging it in would report a healthy feed as a terrible one. Gates. Windows CI runner .133, the drivers workspace on the real WDK: cargo build, clippy -D warnings (which enforces the unsafe-audit lints), and fmt — all green, against a source whose SHA-256 matches this commit's. Linux CI image: fmt, build, clippy --all-targets -D warnings over pf-inject / punktfunk-core / punktfunk-probe / pf-client-core / pf-driver-proto / punktfunk-host, and the test suites including the 5 new motion-cadence tests — all green. Not measured on glass. G6's stated gate is a sensor-rate reading (SDL testcontroller or Steam's calibration screen) that matches the client's send rate; that is still owed, and a driver change only a compile has seen deserves it before anyone trusts the number.	2026-08-07 13:44:54 +02:00
enricobuehler	31bb3ca7f7	Merge pull request 'The console answers a mouse and a finger, and host cards get a menu' (#90) from worktree-console-tabs-pointer into main ... Reviewed-on: #90	2026-08-07 11:38:41 +00:00
enricobuehler	d49f955171	fix(console/host menu): the actions get their explainer line and room to breathe ... The rows sat hard against the pinned title — the menu is the one form screen with no subtitle, so the list started at the very top of the content band. It now wears Add Host's explainer, which both says what the menu is for and is the air that keeps the first row off the title. A pinned card explains what unpinning does and does not touch, the same wording the Android dialog uses. Caught by the screenshot pass, not by a test.	2026-08-07 13:29:59 +02:00
enricobuehler	507ea58da8	fix(host/audio): the silent-sink check recognizes the minted Speakers ... Observed in the first real session on the substrate: the loopback ran on the minted 'Punktfunk Speakers' (silent on the host by construction), but have_silent name-matches only the Streaming Microphone — so the capture open logged 'desktop audio will also play on the host' (false) and re-attempted the Steam-pair install it doesn't need. The minted sink is recognized by id; its name honestly says Speakers, which the name rule must keep refusing for FOREIGN instances.	2026-08-07 12:59:15 +02:00
enricobuehler	4834c2ee51	fix(host/pads): DualShock 4 gyro ran 40× fast, and no pad ever stopped turning ... Phase 1 of the gyro program (design/gyro-program.md, G1-G5) — the five correctness fixes under it. Gyro aim integrates angular velocity over time, so each of these is not a cosmetic wrongness: a wrong scale is every rotation being the wrong size, a wrong clock is every rotation being integrated against a fictional dt, and a stale sample is rotation that never happened. G1 — the DualShock 4 calibration blob. A Sony pad does not assume a motion scale, it reads one out of a fixed calibration feature report. Ours declared 0.5 LSB per °/s and 8192 LSB/g while the wire delivers 20 and 10000, so every DS4-type session decoded gyro 40× too fast and acceleration 1.22× hot — since the backend shipped. The blob now states the wire's own units (the DualSense blob's numbers, deliberately: both pads consume the identical wire sample). Its interleaved per-axis order is NOT a bug and stays: the virtual pad declares BUS_USB, where interleaved is the correct layout; grouped is Bluetooth's. The same blob lives a second time in the UMDF driver, which is a separate WDK workspace that cannot depend on pf-inject — one wrong table in two files, where fixing one reads as fixing it. Both are fixed, and the DS4 feature reports now live in dualshock4_proto beside the DualSense's rather than in the Linux backend, so there is one canonical copy to point at. Field hosts keep the old blob until they update the host package. G2 — the gate that would have caught it. Nothing pinned any backend's declaration against the wire, so tests/motion_contract.rs now applies the CONSUMER's arithmetic (the kernel's, and SDL's, which differ) to each backend and asserts the result lands back on the wire constants — for the DualSense and DS4 blobs, and for the Deck and Switch Pro rescales. It also parses the driver's Rust source and re-derives the units from THAT, so the two copies cannot drift. Verified non-vacuous both ways: re-introducing the old blob fails with "declares a fractional 32/64 LSB per °/s", and reverting only the driver's copy fails with "the UMDF driver's DS4_FEATURE_CALIBRATION has drifted from pf-inject's". The wire units themselves move to punktfunk_core::input::gamepad, referenced by the client's capture scale, the Deck/Switch rescales, and the probe — whose at-rest vector said 16384 (a driver's number, not the wire's) and now says 1 g. G3 — real sensor clocks. The DualSense advanced its sensor timestamp by +1 raw unit per report (0.33 µs — a frozen clock) and the DS4 by a flat +188 (~1 ms) regardless of the real 4-8 ms cadence. Anything integrating rate × dt off that field got nonsense. All four backends now stamp elapsed monotonic time in their own units via a shared SensorClock, anchored to the pad's first report so an irregular publish loop cannot make it drift, and truncated to the field width — which reproduces the wrap real hardware does. G4 — motion is level-triggered and had no watchdog. merge_frame preserves the last sample and the heartbeat re-emits it, so a feed that stops leaves the pad rotating forever — and with G3's honest clock, at a dt that keeps growing. Rumble and the pen plane each have an idle timeout; motion now has one too, at 100 ms. Angular velocity only: acceleration is kept, because gravity is legitimately persistent and blanking it reads as free-fall. The SDL client parks its gyro at zero when a slot closes, which is the case we can flush rather than wait out. (The Apple half of this rides in PR #88.) G5 — a pad returning inside the 300 ms replug grace keeps the same device and skips the create path, so a different controller inherits the previous one's touch contact and rotation — and a pad with no gyro never sends a sample to correct it. sweep() now reports re-claims separately from drops, and the manager clears the rich plane on one. Rich fields only: rumble and hidout dedup deliberately survive a removal. Gates (Linux, CI image): fmt, build, clippy --all-targets -D warnings over pf-inject/punktfunk-core/punktfunk-probe/pf-client-core, and the test suites — 110 pf-inject unit + 6 contract + 29 pf-client-core gamepad, all green. Not yet verified on glass; the on-glass sign/scale session is G16.	2026-08-07 12:47:26 +02:00
enricobuehler	413a3e3e76	feat(client): say which GPU can do Vulkan Video, and why not when it can't ... Field report from an Intel Arc + NVIDIA laptop: pinning the Vulkan rung on the Arc iGPU silently produced D3D11VA, and there was no way to tell whether the build had tried at all. That ambiguity was ours, in three places. The "unavailable" log printed three of the FIVE conjuncts that gate Vulkan Video. A device with 1.3, the features and a decode queue family — but no codec extension — logged dev_is_13=true features_ok=true decode_family=true next to the word "unavailable" and named nothing actionable. It now prints all five, plus which base extensions are missing, which codec extensions are present, the decode family's own advertised codec operations, and the device name and vendor. It also no longer says "VAAPI/software" on Windows, where the rung below is D3D11VA. The native-vulkan PIN refusal logged `video_decode` alone. On a device that decodes something but not THIS codec, that reads as a contradiction: refused, yet video_decode=true. It now carries the caps mask and the codec bit that was wanted, so "your GPU can't" is distinguishable from "we asked for the wrong thing" — only the second is our bug. And `--probe-decode` is new: per-adapter Vulkan Video capability with no session, no surface and no logical device. For each GPU it answers usable yes/no, the driver's own decode ops, the extensions, and — when the answer is no — which conjunct failed, in words. Separate from --list-adapters, which the desktop shells parse line-by-line for their GPU picker and which therefore keeps printing bare names. The listing is ordered like pick_device (discrete first) and marks entry 0 as the default presenter, because that ordering is very likely the reporter's actual answer: pick_device ranks DISCRETE_GPU above INTEGRATED_GPU, Vulkan Video decodes on the PRESENTER's device by design (that is what makes it zero-copy), and PUNKTFUNK_DECODER does not move the presenter. So on a hybrid laptop, pinning the decoder while the dGPU presents probes the wrong GPU entirely — PUNKTFUNK_VK_DEVICE=<index> is the knob that moves it, and the index printed is that value. To keep the probe honest, VIDEO_BASE and VIDEO_CODECS moved to module scope and the five-way AND became video_decode_gate(), called by both the probe and device creation. A probe holding its own copy of the rule is one that eventually reports a capability the session then refuses — which reads to everyone as a decoder bug rather than a probe bug. Gates: fmt clean; clippy -D warnings over punktfunk-client-session and pf-presenter. The Linux container was unavailable (the host's disk filled and took the docker daemon with it), so this ran on the macOS host target only — the container leg is owed, and CI covers it on the PR.	2026-08-07 12:42:33 +02:00
enricobuehler	f06b3d9d04	feat(console): the console answers a mouse and a finger, and host cards get a menu ... Two gaps, both found on the shared Linux/Windows console UI. **The settings tabs only moved for a gamepad.** They were bound to the shoulder buttons and to PgUp/PgDn, and the legend spells PgUp/PgDn out only when NO pad is attached — so with a controller plugged in a keyboard user had nothing to find, and a mouse or a touchscreen could not change section at all. The root cause was wider than the strip: `SkiaOverlay::handle_event` matched only `KeyDown` and `TextInput`, so every mouse button, wheel and touch contact fell past the console into the run loop, which routes pointer input exclusively at `stream.capture` — `None` while you are browsing. Nothing in the console had ever been clickable. Making just the pills answer would not have helped either: the settings screen is opened with X from home, so a mouse could not reach it. So the console gets a real pointer path: - `Overlay::handle_pointer` carries mouse/touch in SWAPCHAIN PIXELS. The run loop converts (it owns the window, hence the display scale, and mouse coordinates are logical while fingers are normalised); the console then hit-tests the very rects it drew last frame. Only DIRECT touch devices are offered — an indirect trackpad already drives the mouse. - Widgets act on the PRESS, not the release. The list and both carousels scroll the focused item toward the centre, so what you pressed has slid out from under your finger by the time it lifts; press-to-act has no such race and there is no drag gesture to compete with. - The hint bar became the pointer's button bar. It is already the console's only on-screen statement of what the face buttons do, and a pointer has none — so its Confirm/Back/Secondary/Tertiary pills are clickable on every screen, which is what puts Settings and Library within reach of a mouse at all. - Tab / Shift+Tab change section; PgUp/PgDn still do, and the keyboard legend now reads "Tab". - Right-click is Back everywhere, EXCEPT at the root: B there quits the launcher and a right-click is far easier to fire by accident. Quitting stays explicit. **Host cards had no menu.** Every other client hangs Wake / Copy link / Edit / Forget off a host card; the console could add a host and connect to one, and that was all — so a renamed machine or a fat-fingered address stayed wrong forever unless you opened a desktop shell. UP on a saved tile now opens that host's menu, the same gesture the Android console uses, on the one direction a horizontal carousel leaves free. - `ConsoleCmd::UpdateHost` edits the stored host IN PLACE. Removing and re-adding would silently drop the fingerprint, the learned MAC, the pinned cards and the profile binding — that is a rename, not a re-pair. - `ConsoleCmd::ForgetHost` drops it; if it is still advertising it returns as a discovered, unpaired row, which is the honest state. - Forget arms on the first press and fires on the second. The other clients forget outright; a console is driven by a thumbstick from across a room. - A pinned profile card offers only Unpin. It is a shortcut, not a second host, and offering to forget the host from it would blur exactly the distinction a pin draws. - "Edit…" REPLACES the menu on the stack rather than stacking over it, so Back from the editor doesn't land on a menu describing the host as it was before the edit. Verified in the pf-lxcheck2 container (this crate compiles to nothing on macOS — a bare `cargo check` there is vacuous): plain build and `clippy --all-targets` clean under `-D warnings`, 72 tests pass. Seven are new, and cover the reported bug directly — a press on a pill selects that tab, and each tab still keeps its own cursor when a pointer is what switched it.	2026-08-07 12:36:22 +02:00
enricobuehler	99a59fb5c7	fix(host/audio): the mic pump's first resolve waits for the minted endpoints ... Measured on the target box: the pump wired 2 s before the provisioning worker latched, took the cable as its write target, and the next wiring pass would then have paired the default recording with the minted microphone — which nothing writes into: dead mic-air until a pump reopen. resolve_target now provisions synchronously (instant once latched; the opt-out env is honoured), so the pump's held device and the plan's verdict can never disagree.	2026-08-07 12:02:48 +02:00
enricobuehler	3870cdd1da	feat(host/mgmt): the audio wiring verdict joins /status ... RuntimeStatus gains an 'audio' object (Windows hosts): readiness (full/audio_only/mic_only/none), the friendly names carrying each role, and the three degradation flags (mic_withheld, last_resort, narrowing) — the verdicts that previously lived only in tracing logs. Snapshot of the last wiring pass (the mic pump wires at host start and on every reopen); a status poll never triggers COM work or IPolicyConfig writes.	2026-08-07 11:53:15 +02:00
enricobuehler	79c72fa64d	fix(host/audio): capture endpoints carry the {0.0.1.…} id prefix ... The capture-direction lookup built its endpoint id with the RENDER prefix {0.0.0.00000000}., but WASAPI's enumeration returns capture ids as {0.0.1.00000000}.{guid} — so the minted microphone's capture side never string-matched the enumeration and the wiring plan paired no recording device (audio-probe plan on the target box: mic_capture = '-'). Measured; IMMDeviceEnumerator::GetDevice tolerated the wrong prefix, which is why the S3 spike's direct open still passed.	2026-08-07 11:37:39 +02:00
enricobuehler	64655c5275	fix(host/devtest): audio-probe plan provisions synchronously ... A fresh CLI process has no startup worker to have finished, so the plan devtest raced its own background provisioning thread and printed the name ladder instead of tier-0. ensure_blocking() re-resolves existing marker devnodes in milliseconds before the wiring pass runs.	2026-08-07 11:32:05 +02:00
enricobuehler	4a621de6b1	chore(packaging): retire VB-Cable — audio's substrate is Steam's drivers ... The other half of the audio-substrate decision (spikes S2+S3 green, minted endpoints landed in the previous commit): stop bundling a third-party kernel driver the host no longer needs. installer the VB-CABLE task, payload, silent-install run and the donationware notice are gone; a suppressible notice tells a Steam-less box that audio needs Steam INSTALLED (never running) and that installing it later just works. A cable from an older install is still deliberately not removed. packer + CI -VbCableDir/VBCABLE_DIR, the staged-payload check and the runner provisioning download are gone; SBOM drops the redistributed-driver component. winget the VB-Audio bundling-grant agreement becomes the honest Steam requirement (surfaced on the unattended path where no wizard is on screen). docs windows-host/uninstall/security/echo say what actually ships: no kernel-mode driver of our own, endpoints minted from Valve's vendor-signed drivers, VB-CABLE mentioned only as the historical fallback that keeps working. host wording the mic-open guidance and module headers lead with Steam; the NAME ladder itself is untouched — demoting 'cable input' was considered and rejected (on a box where minting transiently fails, the SSM would outrank an installed cable, steal the silent sink, and make audio host-audible).	2026-08-07 11:27:29 +02:00
enricobuehler	5aa1ca392e	Merge pull request 'fix(host/encode): the Windows host build stops failing on unused split-encode helpers' (#86) from worktree-fix-winhost-clippy-dead-code into main ... Reviewed-on: #86	2026-08-07 09:22:57 +00:00
enricobuehler	0b160a4e22	feat(host/audio): minted Punktfunk endpoints become the wiring plan's tier-0 ... The audio-substrate program's Phase 2 (spikes S2+S3 measured green on the target box): the host mints its OWN instances of Valve's streaming-audio drivers and wires by IDENTITY instead of borrowing Steam's primaries — minted.rs the provider: one devnode per role ('Punktfunk Speakers' from SteamStreamingSpeakers.inf, 'Punktfunk Microphone' from SteamStreamingMicrophone.inf), marker-matched across restarts (PunktfunkAudioRole in Device Parameters — names are NOT identity, a minted instance is name-identical to the primaries), provisioned on a startup worker like pad audio, retried with a 60 s cool-down from wiring passes, defaults restored when a fresh endpoint grabs them. wiring_plan MintedIds tier-0: the mic takes its minted device outright (capture side paired by the provider's id — a name search cannot tell it from the primary), the loopback prefers the minted sink at the head of the silent tier, an operator override still beats everything, a narrowing minted sink demotes below real hardware, and stale ids fall back to the ladder unchanged. Plus AudioReadiness — the full/audio-only/mic-only/nothing classification, logged with every plan change (§C4's seed). audio-probe 'mint' runs the provider synchronously; 'plan' prints one real wiring pass + readiness — the field-triage command. Without Steam's drivers nothing changes: provisioning degrades to absent ids and the plan keeps the name-based ladder (primaries → cable → real hardware) exactly as before.	2026-08-07 11:22:06 +02:00
enricobuehler	f49f22a292	fix(host/encode): the Windows host build stops failing on unused split-encode helpers ... The Windows host job died in its clippy step: eight items in pf-encode's split-encode policy (`SPLIT_AUTO`..`SPLIT_DISABLE`, `resolve_split_mode`, `max_forced_split_mode`, `clamp_to_engines`) were reported as never used, and `-D warnings` turns that into a build failure. Nothing about the encoder was wrong — the items simply have no reader in one particular build of the crate, and nothing was telling the compiler that. `codec.rs` compiles on every platform, but the split policy only ever has a caller on Linux (the libav NVENC path reads it unconditionally) or on Windows with the `nvenc` feature (the direct-SDK backend). A featureless Windows build of pf-encode has neither, so every item in the cluster is genuinely dead there. Gate them on the union of their callers' cfgs, the way `forced_split_width` next door already is. The step lints pf-encode itself WITH `--features nvenc,amf-qsv,qsv`, where the items are live, which is why this was invisible there; the failure came from the next command in the same step, `clippy -p pf-vdisplay`, which pulls pf-encode in as a plain default-features dependency. Same item-level `dead_code` trap this crate has now hit five times. Verified: default-features pf-encode reproduces all eight errors before the change and none after (macOS default-features exercises the identical "cluster has no caller" arm as featureless Windows — the two remaining errors there, `vbv_frames_env` and a redundant closure call, are pre-existing and macOS-only; both items have real Windows callers). Linux default-features and Linux + nvenc `--all-targets` both stay clean, so the callers still see the policy. `cargo fmt` clean.	2026-08-07 11:11:15 +02:00
enricobuehler	bbbcf321e5	Merge origin/main into worktree-native-decode-m0 ... main moved 93 commits while this branch ran. Two conflicts, both where main's new work sat next to M10's excision: packaging/flatpak/io.unom.Punktfunk.yml — main added the vendored gamescope WSI layer (the only route to HDR on a Deck) and, before it, a vulkan-headers module. Took both: this branch predates them and deletes neither. But the headers module's stated consumer was pf-ffvk's bindgen over FFmpeg's hwcontext_vulkan.h, and M10 deleted pf-ffvk — so it now reads as dead weight to the next person. It is not: the WSI layer IS a Vulkan layer, compiles against those headers, and builds after it, so module order is the dependency. Rewrote the rationale to say so, including why dropping it would be expensive to discover — flatpak.yml has no pull_request: trigger, so a manifest break reaches main invisibly and a tag then ships no Linux flatpak. Also recorded that the native decoder needs nothing from there: pf-vkdecode reaches Vulkan through ash, which is pure Rust bindings, no bindgen, no C headers. crates/pf-console-ui/src/screens/settings.rs — main restructured the gamepad settings into TABS, which removed the per-row section headers; this branch had left Some("Video") untouched from the merge base and added the pre-M10 decoder migration next to it. Git could not tell those apart. Took main's structure (no header, its deliberate change) with this branch's migration layered on: a stored `vulkan`, `vaapi` or `d3d11va` names no preset in the tabbed list and would render as "—", then silently rewrite the user's preference on the next save. Gates on the merged tree, Linux container: fmt clean; cargo check --workspace --all-targets clean; clippy --workspace --all-targets -D warnings clean; tests green across pf-vkdecode (187), pf-client-core (163), pf-console-ui (58) and punktfunk-host (447 of 448 — the one failure is the pre-existing gamestream::stream::tests::sender_delivers_batches, a UDP-loopback EINTR under qemu that fails identically on a pristine HEAD).	2026-08-07 10:50:32 +02:00