811 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	3daead7d71	fix(apple): the sub-screens' legends sit where the launcher's does ... Carries the display-corner inset (previous commit) through the three screens that pin the same legend pill — settings, add-host, pair — so they don't drift from the launcher the moment the user opens one. Each of those trays is `maxWidth: .infinity, alignment: .leading`, so the pill is left-aligned there too and the iPad's short centre indicator is never in its way; the keyboard tray sits ABOVE the legend in the stack, so pulling the tray down doesn't put keycaps over the strip. And the settings tab strip now takes its padding from the row metrics instead of two fixed numbers. It was the other half of the iPad sizing complaint: the tier work grew the fields under it while the tab pills stayed at phone scale, which read as a tab bar that belonged to a different screen. macOS + tvOS typecheck. Re-landed on the probe spelling: the corner inset is read from `\.displayBottomInset` (DisplayBottomInsetProbe via ContentView), never asked of UIKit during body — the original spelling froze the update graph of any view that called it on device (see the legend-pinning commit).	2026-08-10 09:59:25 +02:00
enricobuehler	18d0009c35	feat(apple): the trust prompt takes controller input ... Trust-on-first-use had no pad wiring at all, and it appears at the worst possible moment for that: mid-connect, with capture already disabled so ContentView can blur the stream and stop forwarding. A pad-only user pressed A to connect, got this card, and found the controller in their hands doing nothing — the only way past was to reach for the screen. A trusts, B cancels, X runs the PIN ceremony instead. The legend only appears with a pad attached; naming controller buttons to a trackpad user would be describing hardware they don't have. `GamepadManager` is observed rather than read once so the bar arrives if a pad wakes up while the card is already open. Safe to poll unconditionally while the card is up: capture is off for its whole lifetime and the home screens are unmounted behind the session view, so nothing else is reading the pad. The A press that STARTED the connect is typically still held when this mounts — `GamepadMenuInput` adopts the held state without firing on start, so it doesn't auto-trust. tvOS is untouched: the focus engine already drives these buttons. macOS + tvOS typecheck.	2026-08-10 09:58:26 +02:00
enricobuehler	8ef5350431	fix(apple): pin the launcher legend to the display's corner ... On an iPad the controls pill sat two to three times further from the bottom of the screen than from the left, so it read as floating rather than tucked into the corner. `safeAreaInset` places its content INSIDE the safe area, so the pill's bottom margin was stacking on top of the device's own ~24 pt home-indicator inset while the leading margin had nothing to stack on. Subtracting that inset is the fix; GETTING the inset is where this commit's history is. Three spellings failed before this one, each silently: - a `GeometryReader` carrying `.ignoresSafeArea()` — a proxy reports no inset for an edge it has been told to ignore, so it can only answer 0; - `.ignoresSafeArea(.container, edges: .bottom)` on the inset CONTENT, which does not move content the inset mechanism itself placed; - asking UIKit for the key window (`UIApplication.shared.connectedScenes…`) DURING body — which answers the right number and then KILLS the asking view. On a physical iPad (never the simulator) that walk re-enters UIKit layout mid-render and SwiftUI silently severs the view's update graph: from then on every `@State` write lands in storage without `body` ever running again. That is exactly how Settings and Add Host stopped opening while their triggers kept firing and `showSettings` kept reading true — no AttributeGraph warning, nothing in the log. Found by bisecting device builds; a build that opens the screen programmatically renders green with input-driven navigation completely dead, so only a real press counts. So the inset is measured where it is knowable: DisplayBottomInsetProbe, a UIView that reads its WINDOW's inset from UIKit's own callbacks (didMoveToWindow / safeAreaInsetsDidChange / layoutSubviews), hops out of the current update, and publishes through `\.displayBottomInset` from ContentView. The legend reads the environment — proven safe on glass — and `gamepadLegendBottomPadding` is pure arithmetic. Tablets only. The padding goes negative to pull the pill back down through the indicator strip, which is safe there because the pill is left-aligned and an iPad's indicator is a short bar in the middle. A phone's indicator is taller and its legend runs most of the width, so the same move would cross it — phones keep the plain margin, and the tier comes from the size classes, so an iPad in a narrow Stage Manager window is treated as the in-hand case it is. macOS + tvOS typecheck; margins and Settings/Add Host opening from a real controller press verified on the iPad itself.	2026-08-10 09:58:20 +02:00
enricobuehler	522ac7bd49	feat(apple): the connect path's modals are pad-navigable ... `.alert` and `.confirmationDialog` are UIKit/AppKit surfaces: a game controller cannot move through their buttons or press one. On iOS/macOS that made every prompt in the connect path a dead end for a pad-only user, and they are not incidental prompts — "Pairing required" is the FIRST thing an unpaired host shows (so pairing was unreachable before it even got to a PIN), "Connection failed" strands the console UI behind a modal only a finger can dismiss, and "Waiting for approval" owns the only Cancel for a connect that may never complete. GamepadPromptView renders those states as a console card with a focus list of actions; the system alerts stand down while it is up. tvOS keeps them — the focus engine drives them natively there, which is exactly why this gap was invisible from that platform. Two things are deliberate rather than incidental: The gate is "not STREAMING", not `model.connection == nil`. A connection object exists well before a stream does — through the pair-required and approval handshakes, precisely when these fire — so gating on the connection would hand those cases back to the system dialog. Streaming is the one state that must keep the alert: there the pad belongs to GamepadCapture. And the overlay hangs off `driven`, not `home`, for the same reason: `home` renders only while the connection is nil, so a prompt mounted there would be skipped in the very case it was written for. The launcher stands down from the controller poll while a prompt is up (`promptActive`) — without it the host carousel keeps scrolling underneath the modal and one A press reaches both. macOS + tvOS typecheck; console UI verified opening Settings in the iPad simulator with the prompts wired in.	2026-08-10 09:56:25 +02:00
enricobuehler	8ab4918923	fix(apple): the host strip stopped flashing as it settles ... Reported from the iPad: the cards arrive, come to rest, and then flash. They did — and it was not the motion. Every card sat at the WRONG fill for as long as the entrance animation ran, then snapped to its real one in a single frame once SwiftUI tore the animation down, roughly a third of a second AFTER the last card had stopped moving. `rotation3DEffect` was the cause. A real 3D transform renders its subtree through an offscreen layer, and these cards carry translucent glass, which resolves differently in there — so the strip showed the aurora through itself for the duration and went opaque the instant the layer was dropped. Measured on an iPad Pro 13", sampling the centred tile: it held #4a3d87 across twelve frames in which nothing moved, then stepped to #423970 — 23/255 of blue in one frame, on every card at once, while the backdrop beside them stayed exactly #713fa0 throughout. Stretching the timeline from 1.02 s to 2.82 s moved the step from 0.70 s to 2.50 s after launch: the same 0.32 s before the end in both runs, which is what proves it is the animation ENDING and not any state the tiles were waiting on. Deleting the rotation deleted the step outright. `compositingGroup()` above and below the transforms each changed nothing, so this is the 3D layer specifically, not compositing in general. The turn is now projected instead of rendered: cos(angle) as a horizontal squeeze IS the orthographic projection of a Y-axis rotation, hinged on the edge the card fans from — which also puts the code behind the doc comment that already described the fan that way (the sign of a rotation carried it before; cos is even, so the anchor has to). Affine, so there is no offscreen pass and no layer to drop. What's lost is the perspective trapezoid, which at card size was never what sold the motion; the fan-out, the stagger and the overshoot are untouched. Also drops the temporary PUNKTFUNK_DIAG_OPEN hook that gated each step of this branch in the simulator. 284 tests pass; macOS + tvOS typecheck; entrance re-recorded on the iPad Pro simulator — the tile now settles monotonically (#4153cf → #383c77 → #39396e → #393a6e) and holds, with the fan-out still reading as a turn.	2026-08-10 09:36:02 +02:00
enricobuehler	09bac99090	feat(apple): pairing you can actually do with a controller ... PairSheet is a `Form` with two `TextField`s. On tvOS the focus engine drives those natively, but on iOS/macOS a controller cannot reach a text field, type into it, or press the button underneath — so for anyone in the console UI, pairing (the ONE thing between a fresh install and a first stream) ended at "now touch the screen". GamepadPairView is the same ceremony in the gamepad UI's own vocabulary: the vertical focus list the settings and add-host screens use, A on a field to open GamepadKeyboard in a bottom tray, B to peel one layer. It mirrors GamepadAddHostView field for field, because it is the same interaction and someone who has added a host should recognise it immediately. The ceremony itself moved to a shared `PairCeremony` used by both presentations, so they can never disagree about what a wrong PIN means, what a host rejection says, or when a late result must be discarded. On iOS it is a shell layer like settings and add-host, and it LEADS the shell's screen order: it blocks a connect the user already asked for and can be raised from on top of the library (launching a title on an unpaired host), so it has to win; backing out reveals whatever it interrupted. macOS has no shell, so its sheet switches content by mode instead. tvOS is untouched. macOS + tvOS typecheck; console UI verified opening Settings in the iPad simulator with the pair screen wired into the shell.	2026-08-10 08:12:50 +02:00
enricobuehler	5db3b3c4fd	feat(apple): the controls legend is clickable ... Every hint cell that names an action is a real button on iOS/iPadOS/macOS. The legend already lists every action a screen has, in one fixed place, so a user without a pad in their hands — an iPad on a stand, a Mac driven by trackpad, anyone running `gamepadUIMode == "always"` — was reading a complete menu they could not press. tvOS keeps them inert deliberately. There is no pointer there, so a tappable cell would have to be FOCUSABLE, and that puts six new stops in the path of a focus engine whose flow on these screens is load-bearing and hard-won — while every action in the legend already has a native route (select, Menu, Play/Pause, the focusable tab pills). Cells that name an INPUT rather than an action stay labels: "↔ Adjust" is the stick itself, and "A Type" over the on-screen keyboard has no tap equivalent because a touch user types by tapping the keycap. Two details that are load-bearing rather than tidy: the decorative hairline gets `allowsHitTesting(false)` (it sits on top of the cells), and the press style's `contentShape` sits below its `scaleEffect` so shrinking the artwork cannot move the target out from under a resting finger and lose the touch-up. macOS + tvOS typecheck; 272 tests pass; console UI verified opening Settings in the iPad simulator.	2026-08-10 08:05:14 +02:00
enricobuehler	ffb1ecfebe	feat(apple): size the console UI for the iPad ... GamepadFormMetrics had exactly two tiers, tvOS and everything-else, so a 13" iPad Pro drew its settings rows, section tabs and legend at iPhone scale in the middle of a very large display — the field verdict was that the sizing "does not adapt to larger screens". There is a third tier now, between the in-hand and 10-foot sets. Chosen from the SIZE CLASSES, not the device idiom: an iPad in a narrow Stage Manager or Split View window keeps the in-hand numbers, because what is being read is the window, not the panel behind it. Phone sizing is untouched. Published from ContentView — the app root — rather than only from `gamepadPaletteInk`. A screen that applies that modifier itself sits ABOVE its own copy of the environment, so its `@Environment` resolves against its parent and would read the bare phone default no matter what the modifier published. The screenshot harness publishes it too, for the same reason: it mounts these screens with no ContentView above them, so an iPad capture used to render the whole gamepad UI at iPhone scale. macOS + tvOS typecheck; the console UI verified in the iPad simulator opening Settings at the tablet tier.	2026-08-10 07:44:36 +02:00
enricobuehler	08e462fee9	fix(apple): Graphite's selected settings tab was white on light grey ... The tab strip's selected pill is FILLED with the palette accent, and `ink.onAccent` — chosen by that accent's own luminance, and documented for "a filled pill's label" — has existed for exactly this since the palettes landed. The strip was using the plain foreground instead, which is white on every dark palette and therefore looked fine on all but one: Graphite's accent is a light grey (luma ≈ 0.80), so its selected tab read white on white.	2026-08-10 07:41:43 +02:00
enricobuehler	2590238b8f	fix(apple): the console sub-screens' backdrop, glass and option band ... Four things the field reported on glass, all in the console's visual layer. The tray scrim is GONE, not re-tuned. It laid `.ultraThinMaterial` across the top and bottom of every form screen, and a material by definition lifts and tints whatever it blurs — so it read grey, and washing it with the palette's ground only made it read coloured. There is no public way to blur a backdrop without that tint, so the layer had to go. The darkening it also provided was never its to provide: the backdrop's own legibility scrim (0.38/0.06/0.08/0.40 — the same gradient pf-console-ui bakes into its shader) has always been one layer down, which is why the console has no tray band. Pale palettes rendered every row, pill and card as a flat white slab, and lowering the tint did nothing, because the opacity came from the glass BODY: `.regular` is a bright, high-body material and a pale palette's `ink.glass` is literal white. Pale palettes take `Glass.clear` now, with a light wash to keep dark ink legible. A focused settings row changed colour in a hard jump, a beat late, while its scale animated smoothly beside it — the focus tint rode `Glass.tint`, and a Glass value is opaque to SwiftUI's animation system. It is a plain fill between the glass and the label now, so the existing animation covers it. The host cards appeared to be swapped for different ones as their entrance landed: `CardEntrance` swings each tile in on a rotation3DEffect, and Liquid Glass samples the backdrop through its own layer, which it cannot do under a 3D transform. Those tiles take the material path (`forceMaterial`). And the option band never turned like a cylinder because the band MASKED itself: a mask rasterises what it covers, flattening `rotation3DEffect`'s perspective, so the projection was computed and discarded every frame. The soft edge is folded into each option's own opacity instead. Its ±1 neighbours stay hidden at rest — showing them reproduced the documented overlap defect ("2752 × 2064" with "280 ×" through it), which is why they were dropped. Also fixes pale palettes washing out: the calm mix added a plusLighter wash of a near-white ground on top of a field already mixed toward it, saturating the form screens to white. macOS + tvOS typecheck; console UI verified opening Settings in the simulator, with no tray band.	2026-08-10 07:33:11 +02:00
enricobuehler	beb639f067	fix(ui): the OLED palette is called Eclipse now ... Every other background reads as a place or a material — Violet, Nebula, Abyss, Ember, Moss, Graphite, Holo, Sunset, Bloom, Dawn, Mint, Opal — and "OLED" was a spec sheet sitting among them, naming the panel it suits rather than what it looks like. It looks like black with a thin violet corona at one corner, which is an eclipse, and that puts it beside Nebula and Abyss. The ID stays "oled" in all three clients: it is the stored ui_palette value AND the cross-client key, so renaming it would orphan every saved choice and silently desync Apple, Android and the console UI. Only the label moved. No test or doc pinned the old string. Palette tests pass; macOS builds.	2026-08-10 07:30:30 +02:00
enricobuehler	90450ff1f6	feat(apple): the legends remember which pad you own ... `buttonGlyph` asked the LIVE controller for its `sfSymbolsName` and fell back to generic letter glyphs, so the moment a DualSense slept, disconnected or ran flat, every ✕/◯ hint turned into A/B under its owner's hands. Under `gamepadUIMode == "always"` — the console UI up with no pad by design — they were never right at all. GamepadManager now remembers the family of the last controller that was actually attached (`DefaultsKey.lastGamepadKind`, written on selection and deliberately never cleared on disconnect), and the legends resolve live → remembered → generic. Not a user-facing setting: a glyph-style picker is one more row asking a question the app can answer itself, and the remembered pad is right essentially always. GamepadGlyphs maps by POSITION, not by name, because that is what `GCExtendedGamepad`'s buttonA/B/X/Y are. So ✕ is role `.a` (the bottom button), and a Switch pad gets Nintendo's transposed labels rather than Xbox letters printed on the wrong physical buttons. The test asserts every symbol name RESOLVES on the running OS. That is the load-bearing one: `Image(systemName:)` draws an unknown name as nothing at all — no crash, no log, no red build — so a typo would silently blank a legend on device and no amount of building would catch it. macOS + tvOS typecheck; the 5 glyph tests pass; the console UI verified opening its Settings screen in the iPad simulator.	2026-08-10 07:29:33 +02:00
enricobuehler	bf913c5706	fix(apple): switching audio device mid-stream killed the sound for the rest of the session ... Field report, macOS client, host-independent: start a stream with AirPods in, take them out — nothing on the speakers; put them back in — nothing in the AirPods either. Only restarting the whole stream brought audio back. An AVAudioEngine does not follow the audio hardware. When the output device changes under a running engine, its IO unit sees the new hardware, THE ENGINE STOPS ITSELF, and it posts AVAudioEngineConfigurationChange. It stays stopped until somebody starts it again, and nothing here ever did — no error, no log line, just a session rendering silence from that moment on. Putting the AirPods back in is a second stop, not a recovery, which is exactly why that half of the report looked so strange. Measured on the client's own playback topology (source node -> main mixer, 48 kHz stereo) by moving the default output device programmatically: render callbacks go from ~94/s to zero the instant the device changes, and both restarting the same engine and building a fresh one resume them. The fix watches the hardware and rebuilds the topology the session was started with, on whatever device is there now. Three triggers, because no single one covers the ground: - the engine's own configuration-change notification, every platform — the direct signal, but it can only be posted BY an engine, so it cannot report a rebuild that failed to start; - a CoreAudio HAL default-output-device listener on macOS — independent of any engine and of the engine's topology. This is what makes the recovery work for the voice-processing engine, which is the DEFAULT macOS configuration (mic and echo cancellation both default on) and whose notification behaviour could not be verified: no Mac in the fleet can initialize VPIO at all; - route-change and media-services-reset on iOS/tvOS, where the session rather than the device is what moves. The route observer is now installed for mic-off (.playback) sessions and on tvOS too — it used to be iOS-and-mic-only, for the earpiece steer, but every platform has engines a route change can stop. They collapse into one debounced rebuild (one switch produces a burst), with a floor between rebuilds so a device that renegotiates in a loop cannot spin the session, and a short retry ladder for a device caught mid-transition — a rebuild that fails leaves no engine to post the next notification, so that path must not simply give up. The ring is deliberately carried across: the drain thread keeps decoding through the switch, and the ring's overflow policy has already dropped whatever went stale while the engine was down. A rebuild is only ever done when it concerns us. A healthy engine that followed the change on its own is left alone, and somebody changing the system default while this session is pinned to a named speaker is none of our business — rebuilding for that would cost an audible gap for nothing. The trigger wiring is split into AudioDeviceWatcher for one reason: an end-to-end test of the recovery needs a live session, which needs a host, and punktfunk-host does not build on macOS — so the part where a silent failure costs the session ALL of its audio would otherwise ship unverified. On its own the watcher is pointed at the real hardware from a unit test: a real default-output-device move must reach the owner, our engine's notification must get through, a foreign engine's must not. Neutralizing the wiring fails both positive tests and neither negative one. AudioDeviceSwitchTests drives the real SessionAudio through the out-and-back switch against the loopback host; it skips wherever that fixture cannot run (which is every Mac, today) and the open host's frame budget is raised so it outlives the switch.	2026-08-09 11:03:10 +02:00
enricobuehler	fd98406868	Merge pull request 'The Decky plugin's "update the client" has never once detected an update' (#128) from worktree-decky-client-update into main ... Reviewed-on: #128	2026-08-08 22:21:08 +00:00
enricobuehler	9e598f8595	fix(client): the 4:4:4 switch could cost a Deck its whole codec, and --probe-decode denied the queue it was decoding on ... Two Steam Deck findings from a field report of "the decoder was not found, it fell back to H.264 — but sometimes HEVC worked". **The 4:4:4 advertisement was a promise nothing checked.** `VIDEO_CAP_444` rode the "Full chroma" setting alone. That was safe while a software HEVC decoder existed underneath it; M8 removed one (there is no permissively licensed HEVC CPU decoder, so `software_decodable_codecs()` is H.264|AV1). The host grants 4:4:4 on HEVC ONLY, and answers the resolved chroma in the Welcome before the client builds a decoder — so on a device with no 4:4:4 decode the toggle did not cost crispness, it cost the entire codec: the Vulkan rung refuses the shape at construction, VAAPI refuses it too, there is no CPU rung, and the session reconnects on H.264. AMD has no HEVC 4:4:4 decode on any silicon, so every Deck with that switch on lost HEVC. It is per-profile and default-off, which is exactly why it looked intermittent — a "Work" profile lost HEVC where "Game" kept it, same box, same host. Gated on `hevc_444_hardware_decodable`, which asks the driver through the SAME code the rung uses at construction (`VkH265Decoder::probe_stream_support`), so the advertisement and the rung that must honour it cannot disagree. Both depths are required, not either: with HDR on the host may resolve 4:4:4 10-bit, and a device offering YUV444_8 but not YUV444_10 would land in the same hole. Answering from the Vulkan rung alone is exact rather than approximate — it is the only rung in this build that implements 4:4:4 at all (`pf_vaadec::profile_for` errors on chroma_format_idc 3, pf-dxvadec refuses anything but 4:2:0, the CPU rung is 8-bit 4:2:0). Deliberately NOT extended to VIDEO_CAP_10BIT/HDR: all three rungs implement 10-bit 4:2:0, so a Vulkan-only probe there would withdraw HDR from boxes whose VAAPI/DXVA rung decodes it perfectly — a real regression against a case never observed. The bit arithmetic moves into `video::video_caps_for` so the part that was wrong is testable without a GPU, a host or a Hello; the test is verified non-vacuous against the planted original defect. **`--probe-decode` described a different device from the one that streams.** The RADV video-decode opt-in sat AFTER the --list-adapters/--probe-decode/--list-audio /--pair early exits, so the triage tool never had it. Measured on a Deck (canary e22af40f), same binary back to back: bare `--probe-decode` printed "vulkan video decode: no", "driver decode ops: none (0x0)", "no queue family advertises VIDEO_DECODE"; with RADV_PERFTEST=video_decode in the environment, "YES" and "H.264, H.265, AV1, VP9". Any Deck triage that consulted it reached the opposite of the truth. Hoisted to the top of `run`, ahead of every early exit — nothing touches Vulkan before it (`main` calls `run` directly). Gates, in the Linux container: fmt, plain `cargo build` (not only --all-targets), `clippy --all-targets -D warnings`, and 185 tests.	2026-08-09 00:10:46 +02:00
enricobuehler	bd86598d97	fix(decky): the client update the plugin offers was never once detected ... The QAM has offered to update the client since 0.24, and on every Deck it has answered "up to date" — including right now, with a client a day out of date. The check asks flatpak for the remote's commit and compares it to the installed one, and it named the app id with no branch: `flatpak remote-info punktfunk-origin io.unom.Punktfunk`. The punktfunk remote publishes `stable` AND `canary`, so that ref is ambiguous and flatpak refuses it — "Multiple branches available" — rather than picking one. One branch INSTALLED does not help; the ambiguity is on the remote. The call failed on every box, every time, and the failure returned `available=False`, which the panel renders as good news. Hence: the plugin appeared to update only itself. Every query now names the ref in full, resolved once by `_flatpak_ref()` off the exported tree (no subprocess — `_client_argv` is on the path of every headless call). That resolution also carries the SCOPE, so a system-wide install is no longer invisible to a check that hardcoded `--user`, and the launcher pins the same `--branch=`, so the client we start is the client we check and update. A check that cannot run now says so instead of reporting up-to-date: the flatpak leg reports `client_error` exactly as the native leg already did. Dressing that failure up as good news is the whole reason this went a week unnoticed. Also: the button no longer promises "+ client" when the client is manual-only and the tap can only print a command. Verified on the Deck (192.168.1.253, canary, user scope) by running both code paths against the real install, minutes apart: pre-fix available=False remote='' post-fix available=True remote=ca010668 (installed e22af40f) and `flatpak {info,remote-info,update}` all accept the `id//branch` form there. 37 backend checks pass, 6 of them new and about exactly this.	2026-08-09 00:08:24 +02:00
enricobuehler	e22082ac2a	Merge pull request 'No audio over Bluetooth on iOS: .defaultToSpeaker is an override that outranks A2DP' (#126) from worktree-ios-bluetooth-audio-route into main ... Reviewed-on: #126	2026-08-08 21:54:23 +00:00
enricobuehler	07f6d6f324	fix(apple): .defaultToSpeaker outranks Bluetooth, so every headset lost the stream ... Field report on 0.25, iOS: "no audio over Bluetooth ... plays through speakers if Mic input is enabled". Both halves are one bug. `micEnabled` and `echoCancel` both default to true (EffectiveSettings.swift), so the DEFAULT iOS session is `.playAndRecord` — and that branch set `.defaultToSpeaker`. That option is not the polite preference it reads as: it is an output OVERRIDE, and it outranks an A2DP route. Wired headphones beat it, Bluetooth does not, so a cable is the one way to test it and get the right answer — which is what the comment sitting on it asserted ("headphones/BT still win"). Every Bluetooth listener on the default settings got the phone's own speaker instead. Turning the mic off was the accidental workaround the reporter found: that path takes `.playback`, which routes to A2DP happily and always did. The earpiece problem `.defaultToSpeaker` was reaching for is real — `.playAndRecord` really does park the built-in output on the receiver. So solve it against the route we were ACTUALLY given rather than pre-emptively: after activation, if the current output is `.builtInReceiver`, override to the speaker; anything external (Bluetooth, wired, CarPlay, AirPlay) is left strictly alone. That override is a property of the current route — iOS drops it whenever the route changes, which is exactly what lets a newly-connected headset win — so it has to be re-applied per route. Hence the route-change observer: without it, dropping Bluetooth mid-stream would hand the game to the earpiece. Registered only for a `.playAndRecord` session (a `.playback` one needs no steering), removed in stop() before the session deactivate, with deinit as a backstop. Deliberately NOT adding `.allowBluetooth`: it would make a headset's mic usable, but buys that by dragging the whole route onto HFP/SCO and collapsing game audio to narrowband. High-quality A2DP output plus the built-in mic is the better trade for a game-streaming client. Verified: builds clean on arm64-apple-ios17.0 (the triple that actually compiles these `#if os(iOS)` blocks — a plain `swift build` is macOS and skips them), arm64-apple-tvos17.0, and macOS; 257 Swift tests pass, 0 failures. On-glass iPhone + Bluetooth listen still owed.	2026-08-08 23:49:38 +02:00
enricobuehler	bed58b75b6	feat(apple): the statistics overlay is reachable on tvOS ... An Apple TV session had no way to the stats overlay at all. Every other client cycles it in-stream — Ctrl+Alt+Shift+S on the desktops, a three-finger tap on touch — and tvOS has neither a keyboard nor a screen to tap, so the only route was Settings before connecting (or a profile). The docs' own "cycle with" table simply had no row for it. Two surfaces, because an Apple TV may have a controller in the room or only the remote: - Select + X on a controller, cycling one tier per completion. Built like Android's mic chord (Select + Y) and deliberately disjoint from the escape chord — X is none of its four buttons, so reaching for one can never trip the other. Read off the wire mask like the escape chord, so a Select the hold-Select gesture has turned into a guide can't cycle the overlay on its way past. Available on every Apple platform: a controller in both hands is exactly the case the keyboard combo and the three-finger tap can't serve. - Hold Play/Pause on the Siri Remote. Its right-click is therefore deferred until the press resolves — a tap still right-clicks, delivered on release with the release trailing by TAP_PRESS — because a right button held for half a second is a context menu on every desktop this streams. A non-forwarding slot now claims the stats chord's elements too, alongside the escape chord's: on tvOS an unclaimed button's press stays the system's and the chord would silently never complete. Tests pin both chords' masks against their GameController alias lists, that the two overlap only on Select, and that the claim list covers both without duplicates — the failure mode is nothing happening, with nothing logged.	2026-08-08 23:24:09 +02:00
enricobuehler	4b514cc07c	Merge pull request 'An OLED palette, and split WHETHER the gamepad UI is offered from WHEN it appears' (#116) from worktree-oled-theme-gamepad-ui-split into main ... Reviewed-on: #116	2026-08-08 11:22:34 +00:00
enricobuehler	30bd10e301	feat(clients): an OLED palette, and split WHETHER the gamepad UI is offered from WHEN it appears ... Four changes to the client interface, kept together because two of them touch the same rows and the last is a bug the first would have made far more visible. A thirteenth `ui_palette` entry, `oled`. The palette table is hand-mirrored in three languages (`pf-console-ui`'s `library.rs`, `GamepadPalette.swift`, `GamepadPalette.kt`), so it goes into all three at index 1, directly after the brand default — which keeps `PALETTES[0]` the unknown-id fallback and keeps the dark-to-pale cycling order intact. What earns the name is arithmetic, not a darker shade of violet: the ramp's first two stops are literally (0,0,0) and the ground is pure black, so the shaded half of the field is pixels switched off rather than "very dark grey", and the calm mix the form screens sit under lifts toward nothing at all. Mean cell luminance is 0.019 against Violet's 0.254. The bright corner keeps a faint indigo-to-violet ember so the backdrop is still a field with somewhere to go, and that ember carries enough chroma at that luminance (60 degrees of hue travel across 13 of the 16 cells) to satisfy the existing multi-tone assertion without adding `oled` to the near-neutral exemption Graphite and Opal take. Each port gains an `oled_is_actually_black` test that measures the claim — pure-black corner cells, a mean under half the darkest other field's — rather than restating the table. A new device key, `gamepad_ui_mode`. The gamepad-UI switch had been deciding two things at once: whether to offer the controller-optimized interface at all, and that it appears only while a pad is attached. A user asked for the second half to stop applying. `"connected"` (the default, and exactly what the lone Bool meant) and `"always"` separate them, surfaced as a "Show it" row directly under the switch on all five settings surfaces and built only while that switch is on — a picker whose every option decides nothing is worse than no picker. `GamepadUIEnvironment.isActive` takes the mode with NO default argument on purpose: a call site that forgot it would silently strand everyone who chose Always back on "only with a controller", which is the one bug this parameter exists to make impossible. An unrecognized value waits for a controller, so a mode a newer client wrote can never trap an older one in a layout it has no way back out of. It stays a device preference on both platforms, never part of a profile: which interface this device wears has nothing to do with how a host streams to it. The smoothness buffer is hidden under Lowest latency, not dimmed. Everywhere else already hid it — the GTK and WinUI shells, the Apple touch and tvOS screens, the Android touch screen — because under that intent it names a quantity that does not exist. Two surfaces disagreed: Apple's gamepad settings screen left the row live and steppable, and the desktop console dimmed it, having no way to drop a row from a fixed list. That list is now rebuilt each frame through a `row_applies` filter. The concern about a vanishing row moving everything under the cursor does not apply here and the new test says why: the row it drops sits directly BELOW the row that drops it, so the only cursor that can be present when the list shrinks is the one on the intent row, which does not move. Two latent hazards went with it — `apply_row` had been indexing the row list on the assumption the cursor is always in range, and nothing re-clamped that cursor when another writer changed the intent behind the screen's back. Pale palettes were unreadable on tvOS, reported from the field. `GamepadInk` was never the problem: it flips correctly for a pale field, it is not platform-gated, and every tvOS gamepad entry point already published it. The cause is that this app sets `preferredColorScheme` nowhere and declares no `UIUserInterfaceStyle`, so every SYSTEM-derived colour landing on those screens — a `.secondary` placeholder, a `.bordered` button's chrome, a NavigationStack title, a material's frost — resolved against the DEVICE appearance, which the palette cannot reach. On iPhone, iPad and Mac a great many users sit in Light mode, so under a pale palette those colours came out dark and the theme looked correct by accident; an Apple TV is Dark essentially always, so every one of them rendered white on a light field. The mirror image was broken too and had simply never been reported: a dark palette on a Light-mode iPhone was already drawing dark on dark. The scheme is now published beside the ink, once, in `GamepadInkModifier`, because the two are halves of one decision and publishing only the ink silently loses every colour the frameworks draw on the app's behalf. Two structural amplifiers went with it: `ConsoleGlass` had been scoping the scheme to the fill inside its `.background {}` on the tvOS and pre-26 branches while the 26 branch put it on the content, so no console row's own content ever saw it on tvOS; and `LibraryView`'s navigation chrome and its loading, error and empty states sit above `LibraryCoverflowView` and so were never inked at all on tvOS and macOS, where that view is presented directly rather than through the iOS-only `GamepadLibraryScreen` wrapper. That last one exposed a second tvOS gap worth closing in the same breath: `ui_palette` had no row in tvOS's ordinary Settings, and the gamepad settings screen that owns it everywhere else needs an extended-profile controller to open on tvOS. An Apple TV driven by the Siri Remote alone could not reach the palettes at all, which would now include the OLED one. `SettingsView.tvBody` carries a Background row. Verified: pf-console-ui builds, passes `clippy --all-targets -D warnings` and runs 74 tests clean under linux/amd64 (a Mac `cargo check` of that crate is vacuous — every module is cfg'd to linux/windows); `cargo fmt --check` clean for it and pf-client-core. Android `:app` runs 80 tests with 0 failures, including four new `gamepadUiActive` cases and the palette parity table. The Apple package builds for macOS AND tvOS and its 9 palette/gamepad-UI tests pass — the tvOS typecheck is possible because the checked-in xcframework already carries a `tvos-arm64` slice. The tvOS RENDERING fix is compile-verified only; an on-glass Apple TV check under a pale palette is still owed, and is the one thing here that a build cannot answer.	2026-08-08 12:57:12 +02:00
enricobuehler	3bb87d260e	fix(audio): detect jitter before it is audible, and stop re-probing a depth the link just refused ... The 0.25.0 MacBook field report — audio jitter 'at certain points' — is the jitter policy learning exclusively from audible failures, on both of its sides. Growth needed THREE audible underruns before deepening the ring; the A/V sync loop re-tested a shallower ring every five quiet seconds and paid an audible starvation event every time it was wrong, forever; and a grown target was never re-banked — growth raises a threshold, only a re-prime deepens the ring — so a bunching link rode the knife edge, clicking once per bunching period with the 'grown' target sitting inert. A ten-minute simulation of the Wi-Fi power-save pattern (25 ms gaps / 300 ms, −50 ppm skew) measured ~2000 audible events under the shipped policy. Three mechanisms, in JitterPolicy (Linux/Windows/Android) and mirrored in the Swift AudioRing: - NEAR-MISS: a read served with less than one protocol frame left over is the same evidence as an underrun, heard by no one. It grows the target one step per window, BEFORE the click — waiting for the third audible underrun means the user heard two. - SHRINK PROBES: every shrink is armed for five seconds; answered by an underrun or near-miss it is undone on the spot, and a failed sync-driven shrink is not retried for a doubling backoff (60 s → 8 min). A probe that survives resets the backoff. Continuity outranks sync, now with a memory. - HOLLOW RE-PRIME: an underrun while the depth AVERAGE runs more than a step below the target re-primes immediately, spending the click it already cost on the whole refill instead of limping. The average, not the instant, is what separates a hollow ring from one late packet, and it is seeded on prime so a fresh ring is never spuriously hollow. Same simulation after: 9 audible events, tail clean but for the clock-skew re-anchor (a genuinely slow host must re-bank every few minutes; only rate adaptation would remove that, and no client has it). Neutralising the three constants reproduces the ~2000 — the convergence tests fail against the old behaviour. Verified: 203 punktfunk-core tests, 254 Swift tests (5 skipped), clippy -D warnings on punktfunk-core --all-features, cargo fmt --all --check.	2026-08-08 11:05:53 +02:00
enricobuehler	deeb8b6700	feat(pf-encode): build against FFmpeg 9 ... ffmpeg-next 8.1.0 could not accept FFmpeg 9 at all: ffmpeg-sys-next's version probe covered avcodec majors 56..62 (the range is exclusive of its end), so libavcodec 63 fell outside what it knew how to bind. 9.0.0 widens that to 56..63, which is what actually unblocks Arch. Bump both pins — the unconditional Linux dep and the optional Windows amf-qsv one — and the lock with them. No API drift to fix. The crate major is a CEILING, not a target: one source tree still spans FFmpeg 7.x/libavcodec 61, 8.x/62 and 9.x/63 via per-version cfgs, and every wrapper symbol the NVENC-libav, VAAPI and amf-qsv backends name survives 8.1.0 -> 9.0.0 unchanged. The three hand-written #[repr(C)] hwcontext mirrors are the parts no compiler checks, so they were re-read against the real headers rather than trusted: AVCUDADeviceContext and AVD3D11VAFramesContext are byte-identical across 7.1/8/9, and AVD3D11VADeviceContext gained two trailing UINTs in 8 that 7.1 lacks — which is why that mirror deliberately stops at the common prefix, and why its assertions now say what they do and do not buy you. They pin our layout, not libav's; a green build is not evidence. The CI image is the step that makes this reach users. arch.yml deliberately runs no -Syu ("the image's snapshot IS the build environment"), so the builder stayed frozen on ffmpeg 8 no matter what Arch shipped, and a canary built from that snapshot could not satisfy the soname dep the PKGBUILD now derives. Re-keying ci/ rebuilds it against ffmpeg 9. Ubuntu and Windows deliberately stay put: the noble .deb bundles its own FFmpeg 8 behind an rpath and strips the libav sonames from its Depends, and Windows bundles BtbN DLLs into the signed installer — neither is exposed to the break, BtbN publishes no FFmpeg 9 build, and moving either would re-qualify an encode stack to buy nothing. Verified end to end on 192.168.1.21 (CachyOS, system ffmpeg 2:9.0-5, RTX 5070 Ti): host builds clean and links libavcodec.so.63/libavutil.so.61/libavfilter.so.12/libswscale.so.10 with no unresolved sonames; the ffmpeg-8 compat shim is gone and the service runs with NRestarts=0 and answers 401 on :47990; pf-encode's 67 tests pass; and a live synthetic encode drives real NVENC hardware through FFmpeg 9's libavcodec to a decodable 1080p HEVC stream (180/180 frames, FEC loopback 0 mismatches) with libavcodec.so.63 and libnvidia-encode both mapped into the encoding process.	2026-08-08 02:35:20 +02:00
enricobuehler	fca9f42c44	Merge pull request 'Worktree apple mgmt ats bypass' (#103) from worktree-apple-mgmt-ats-bypass into main ... Reviewed-on: #103	2026-08-07 23:20:19 +00:00
enricobuehler	3d20f2c0e5	Merge pull request 'Three decode rungs were decoding into a surface they were predicting from' (#102) from integration/decode-aliasing-program into main ... Reviewed-on: #102	2026-08-07 23:11:28 +00:00
enricobuehler	7798401f06	perf(apple): cache posters on disk and pool the mgmt connections ... Moving the management API onto Network.framework left one request per connection, so a library grid paid a TLS handshake per poster where the pooled URLSession had shared one. And the Apple client -- unlike Windows -- never cached art at all, so it re-fetched every poster on every visit. ArtCache: a size- and age-bounded blob cache in the CACHES directory (every byte is re-derivable from the host, so the system is welcome to evict it). Keyed by the SHA-256 of the absolute URL, so host-proxy paths and store CDN URLs share one cache without colliding. Reads touch the entry, so eviction is by last USE, not last write. Empty bodies and data: URLs are refused -- neither is worth a file. Defaults: 128 MB, 30 days. Connection pooling: MgmtConnectionPool keeps up to four keep-alive connections per host and makes further callers wait rather than opening more, which is the part that matters -- a grid can ask for dozens of posters at once. A connection the host dropped since we last used it is indistinguishable from a live one until we write, so a REUSED connection that fails is retried once on a fresh one; a fresh failure is a real failure. Keep-alive means a response can no longer be delimited by the peer hanging up, so HTTPResponseParser.messageLength finds the end from the framing itself -- Content-Length or the chunked terminal chunk plus trailers. Getting that wrong would truncate a response or bleed one into the next, silently, so it carries the bulk of the new tests. A connection with bytes left over after a response is dropped rather than reused: we never pipeline, so anything trailing means we are out of sync. LibraryView closes the loader's pooled connections on disappear instead of leaving sockets open on a screen the user has left. 16 new tests: message framing (both encodings, partial reads, back-to-back responses, close detection) and the cache (binary round trip, key separation, refusals, expiry, LRU eviction).	2026-08-08 01:09:25 +02:00
enricobuehler	244cafe005	refactor(apple): move the mgmt API off URLSession so ATS can stay on ... The previous commit bought the library back on VPN/remote hosts by declaring NSAllowsArbitraryLoads, which works but is blunt: it drops ATS for ALL of the app's URLSession traffic, and the only other traffic is third-party cover-art CDN fetches -- the one surface we never wanted to open. It cost the TLS-version floor, forward secrecy, and the cleartext-HTTP block on URLs the host supplies at runtime (custom entries and scanner plugins carry arbitrary ones). So take the host out of the URL loading system instead. MgmtTransport speaks HTTPS over Network.framework, which ATS does not govern, and states the trust rule we actually mean in a verify block: the leaf must hash to the fingerprint pinned during PIN pairing. That is the same rule punktfunk-core has always applied on the QUIC stream plane -- which is exactly why streaming kept working over Tailscale while the library did not. With that, the ATS dict is gone and ATS is fully enforced again. Cover-art CDN fetches keep ordinary URLSession with full system trust evaluation and no client certificate. LibraryTLSDelegate is deleted; nothing pins through URLSession now. Also here: - HTTPResponse: just enough HTTP/1.1 to read one GET -- status, headers, Content-Length and chunked framing (hyper streams the art proxy chunked). A body shorter than Content-Length throws instead of returning partial JSON, which would otherwise read as "this host has no games". - LibraryError.pinMismatch, so a re-keyed host says "pair again" rather than sending someone to debug their network. - 403 joins 401 as "unauthorized": both are the host declining the certificate. - baseURL brackets IPv6 literals; the old string interpolation did not. - 11 tests covering the framings hyper emits and the failure modes that would otherwise be silent. Known trade-off: no connection reuse yet, so each poster costs its own handshake where the pooled URLSession shared one. Fine on a LAN, worth revisiting for large libraries over a high-latency link.	2026-08-08 01:09:04 +02:00
enricobuehler	bae8742e48	fix(apple): the library's unreachable message pointed at the wrong layer ... It led with `--mgmt-bind 127.0.0.1`, a rare cause, and never mentioned the one fact that actually explains the symptom: the library rides the management API on a different port (47990) than the QUIC stream plane (9777), so it can fail while streaming to the same host works. Field triage of exactly that case spent hours on the stream path before anyone questioned the port. Leads with that now, and names browser-testing the port as the fast split between "unreachable" and anything client-side.	2026-08-08 01:07:26 +02:00
enricobuehler	78a02bc994	fix(apple): ATS blocked the library on every non-RFC1918 host ... The game library rides the management REST API over HTTPS (TCP 47990) through URLSession, authenticated by mTLS and pinned by SHA-256 fingerprint. The app declared no App Transport Security policy at all, so it ran under default ATS -- which exempts only "local" destinations (.local, unqualified names, RFC1918 and link-local literals) and applies the full policy everywhere else. The host certificate is self-signed (and carries no SubjectAltName), so it cannot satisfy that policy: the library loaded at 192.168.x and failed at the TLS layer on any other address. Field-reported against a Tailscale host. 100.64.0.0/10 is CGNAT, not RFC1918, so the library failed there while streaming to the very same address worked -- the QUIC stream plane is raw UDP and never enters the URL loading system. A WireGuard peer or a public-IP host breaks identically. Declares NSAllowsArbitraryLoads, which must stay the dict's only key: iOS 10+ and macOS 10.12+ ignore it whenever a more granular ATS key sits alongside it. Trust is unchanged -- LibraryTLSDelegate still pins the host by fingerprint and hands every other origin (cover-art CDNs) to full system trust evaluation.	2026-08-08 01:07:26 +02:00
enricobuehler	bfed711921	Merge remote-tracking branch 'origin/main' into audio/latency-overhaul	2026-08-08 00:16:02 +02:00
enricobuehler	c43769282a	fix(apple): place audio with the picture instead of wherever the ring settles ... The Apple half of the A/V sync overhaul; the Rust half is 12a53183 and this mirrors its policy rather than re-deriving one. The host stamps `pts_ns` on every audio datagram and the client decoded it into `AudioPCM` — and then never read it. Video's `pts_ns` is used end to end (the end-to-end meter computes a true glass-to-glass `displayed + clockOffset − pts` per presented frame), 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. Video is the master: 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. Swift refuses one thing Rust does not have to: the arithmetic itself. The Rust controller works in i128, while Swift has no Int128 at this tools version, so the terms are combined with overflow-REPORTING arithmetic instead of the `&-` the latency meters use. That is not defensive padding — `ptsNs = 1 << 63` reads as `Int64.min`, the difference lands on exactly `Int64.min`, and `abs()` of that has no representable result, so checking the overflow flags AFTER the sanity limit does not mis-measure the stream, it aborts the process from the audio drain thread. The guard's short-circuit ordering is what makes the sanity check safe to run at all. Continuity outranks sync, always. `AudioRing.setSyncTarget` 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. `nil` is the default and reproduces the previous behaviour exactly. The clamp raises its ceiling to the floor rather than using it as-is: a device whose callback quantum alone exceeds the hard cap makes floor > cap, and a plain `min(max(s, floor), cap)` would then hand back the CAP — quietly below the continuity floor, inverting the exact ordering this exists to guarantee, on the awkward hardware it exists to survive. (Rust's `Ord::clamp` announces that condition by panicking; Swift would just get it wrong, which is worse.) The reference is the other half, and without it the loop is inert — which is why this was split out rather than shipped alongside the Rust side. `LatencyMeter` now publishes its most recent sample as a LEVEL, so the end-to-end meter the presenter already writes per presented frame becomes the video figure the audio plane reads. Both present paths (arrival and deadline) feed it without either knowing audio exists, and the stage-1 fallback presenter — which stamps no present at all — offers nothing, so the loop correctly declines to correct. The level EXPIRES, unlike the Rust atomic: this client has a backgrounded keep-alive that keeps audio playing and drops video decode entirely, and a reference with no expiry would go on steering the ring against a figure minutes old and frozen. And the reason none of this was visible: `bufferedMS`/`targetMS` existed only in a periodic log line, absent from anything a surface could render. The HUD's detailed tier now carries `audio buffer N ms · a/v ±N ms` and the 1 Hz stats log gains the same pair, appended last so existing parsers are unaffected — both numbers, because a deep ring on a jittery link is correct and only the offset separates that from audio held late. `PUNKTFUNK_NO_AV_SYNC=1` disarms the loop without a rebuild, as on the Rust clients. Verified: swift build + 225 tests (5 skipped) green. Every new gate was proven non-vacuous by planting its own defect and confirming the gate caught it — the continuity invariant, the clamp inversion, the deadband, both refusal paths, the evidence threshold, the sync-pressure relax, the reference's staleness and its survival of a drain, and `setSyncTarget` being live at all rather than dead code, which is how the previous pass in this area shipped a correction that was structurally unreachable with a green test. Two gates came back VACUOUS on the first sweep and are the reason their inputs look so specific: the overflow test was being caught by the sanity limit instead of the overflow guard, and the refused-reference test was being caught by `latestSample`'s own `> 0` check rather than by where the publish sits.	2026-08-08 00:10:48 +02:00
enricobuehler	74270109dd	ci(android): lint the Android target, which nothing had ever done ... `ci.yml` runs `cargo clippy --workspace` on the HOST, where `clients/android/native` and every `#[cfg(target_os = "android")]` module elsewhere compile out, and `android.yml` only ever built. So the Android target was never linted at all — not once. Five lints were sitting in clients/android/native when this was noticed, in code no gate had ever read. The gate is a Gradle task rather than a YAML step because cargo-ndk needs a specific discovery environment (NDK sysroot, SDK cmake 3.22.1 for libopus, `LIBOPUS_STATIC`, Ninja) and duplicating it into the workflow would let the lint drift from the build — a lint that ran against a different toolchain is a lint about a different program. `registerCargoNdkClippy` reuses the build task's environment verbatim via the extracted `cargoNdkEnvironment`, so local and CI runs are the same invocation. It lints BOTH pointer widths, and that is load-bearing rather than thorough: arm64-v8a is 64-bit and armeabi-v7a is 32-bit, so a cast that is redundant on one can be required on the other. Linting only the primary ABI would license "fixes" that break the 32-bit build — the shipping ABI for the many 32-bit Google TV / Android TV boxes this client targets. x86_64 is skipped: it is emulator-only and shares its width with arm64, so it costs lint time for no signal the other two do not already carry. The five resident lints: * `audio.rs` / `mic.rs` `type_complexity` — the open-attempt closures now return named `OpenedPlayback` / `OpenedCapture` aliases. The two tuples are mirror images of each other (playback sends, capture receives), which the aliases now say out loud. * `vsync.rs` ×2 `unnecessary_cast` — **not** taken. `timespec`'s fields are 32-bit on armv7 and 64-bit on arm64, so the casts are REQUIRED on one shipping ABI and redundant on the other; following the suggestion would break the 32-bit build. `i64::from`/`.into()` do not escape it either, they trade `unnecessary_cast` for `useless_conversion` on the 64-bit side. Answered with a documented `#[allow]` at the expression instead of in whichever build breaks first. * `pad_audio.rs` `needless_range_loop` — iterator form, preserving the `channels < 2` no-op the range had. Verified: `:kit:cargoNdkClippy` green on both ABIs, host-lane clippy for the crate still clean, `cargo fmt --all --check` clean. The gate was proven non-vacuous by planting `1i32 as i32` in an android-only module and confirming it fails the task, then reverting.	2026-08-08 00:01:39 +02:00
enricobuehler	70e6b80200	fix(client/android): place audio with the picture on Android too ... The core, Linux, Windows and host halves of the audio latency overhaul landed with Android deliberately left inert: `JitterPolicy`'s sync target defaults to `None`, so this ring kept behaving exactly as it always had. What was missing was not the loop but its REFERENCE — nothing here published where a frame actually reached glass, and a controller with no reference is the mechanism you can prove is present but that cannot act. This wires both halves. The decode thread now reads the host capture `pts_ns` that every `AudioPacket` has always carried and that this client, like every other, dropped on the floor. Against the ring depth (published by the AAudio callback through the shared `AudioSyncCell`) and the video plane's end-to-end figure it computes audio_e2e = (now + buffered_ahead + clock_offset) − pts_ns av_offset = audio_e2e − video_e2e (> 0 ⇒ audio behind the picture) and asks the ring for a depth that closes it. Only ASKS: `set_sync_target` is clamped between the underrun-driven adaptive floor and the hard cap, so a link whose jitter genuinely needs more buffer than the picture is away keeps its buffer and the residual is reported instead of being taken out of the listener's stream. Continuity outranks sync, on this ring as on the others. The reference comes from `DisplayTracker`'s `OnFrameRendered` callback — the one place in the client that knows a frame truly latched — and it is computed ABOVE the HUD gate now. A sync loop that only ran while the overlay was up would be off on exactly the devices that report latency; the stats LOCK stays gated, which is what that early-return was really protecting. Both decode loops feed it, so sync works with "Low-latency mode" off as well. Two deliberate refusals: * The figure is published RAW. The HUD shaves the OS present floor off its shown display/end-to-end numbers — metrics report what Punktfunk controls — but sound has to reach the ear when the light reaches the eye, and a floor-shaved reference would place audio a whole latch period early on every device. * Below API 33 there is no render callback, so there is no confirmed present and the loop stays inert (target `None` ⇒ today's behaviour exactly). The release instant is NOT substituted for it: a release targets a FUTURE vsync and runs a whole latch period (8-21 ms measured) ahead of glass, well outside the loop's deadband — it would place audio early on every frame while looking like it was working. The plane is also no longer invisible. Ring depth and the smoothed offset ride the stats array at 33/34 and the Detailed HUD carries `audio buffer N ms · a/v ±N ms`, the same wording the desktop HUD uses — both numbers, because a deep ring on a jittery link is correct behaviour and only the offset separates that from audio simply held late. The 1 Hz logcat line gains `av_ms` beside its depth, and the depth itself now has ONE publisher: the counter copy is gone in favour of the sync cell both readers already share. The escape hatch is two levers. `PUNKTFUNK_NO_AV_SYNC=1` keeps the contract the desktop clients document, but an app launched from the launcher inherits no environment, so the one a field tester can actually reach is `adb shell setprop debug.punktfunk.no_av_sync 1` — no rebuild, exactly like `debug.punktfunk.presenter`. A loop that steers playback has to be bisectable on the device that reports the regression. Verified: `cargo ndk -t arm64-v8a check` clean; `cargo clippy -p punktfunk-client-android --all-targets -- -D warnings` clean on the host lane CI lints, and the Android target introduces no new findings (5 pre-existing lints in audio/mic/pad_audio/vsync are unchanged — the android-gated modules are never linted by the host workspace); `cargo fmt --all --check` clean; `./gradlew :app:testDebugUnitTest` green. The new HUD test was proven non-vacuous by planting the defect first — dropping the render call fails its three positive assertions and leaves the three absence assertions passing, which is the shape a test that "passes for the wrong reason" would not have. design/audio-latency-overhaul.md W4. Apple (W6) still keeps today's behaviour.	2026-08-07 23:51:15 +02:00
enricobuehler	3a4c94ad79	fix(dxvadec): the review round — a vacuous predicate, an overstated claim, and the H.264 twin of this defect ... Five findings from the adversarial pass, all real. **The deferral predicate was vacuous.** `plan.dpb.removed` is ALWAYS a subset of `plan.dpb_refs`: `Av1Planner::plan_frame` snapshots `dpb_refs` before any mutation and `refresh_slots` can only report a picture that was in `self.slots` at that moment. So `filter(|id| dpb_refs.contains(id))` was a condition that is never false, the eager-release loop beside it could never release anything, and the test assertion "only a picture the submission points at earns the reprieve" could never fire. Now: defer every removal, say why in terms of the planner, and assert the PLANNER's property (`removed ⊆ dpb_refs`) — which is falsifiable, and whose failure would mean the conversion is releasing a surface `ref_frame_map` points at. **The failure-path claim was overstated.** Holding the decode's `Result` closes this frame's leak, not the unit's: `decode_av1` returns on the first failing frame and abandons the rest of the temporal unit's plans, so their removals are never released. 24 of 250 units carry a second frame. Named rather than fixed — what to do with the frames after a failure is the pump's question. **⚠⚠ The H.264 leg plausibly has the same defect, and the comment this change added said it could not.** `pic.rs` builds `RefFrameList` from `plan.dpb_refs`, and `H264Planner` snapshots that in `begin_picture` — BEFORE 8.2.5 marking and the DPB bump. The vendored bump drops a picture the sliding window just unmarked once it has been output, so a picture can land in both `RefFrameList` and `dpb.removed`: the AV1 aliasing shape exactly. Measured zero on the vendored vector — but that vector REORDERS, which is precisely what keeps an unmarked picture alive past the AU that unmarked it. A punktfunk host emits LOW-DELAY H.264, where output happens as each picture is decoded, which is the condition that makes eviction and unmarking land in the same access unit. Traced end to end in source, not reproduced (no low-delay vector). NOT fixed: changing a hardware-proven codec on an unreproduced suspicion is the worse risk two commits before a release. Instead `no_au_removes_a_picture_its_own_reference_list_names` makes the assumption falsifiable, and its message says what to do when it fires. HEVC is structurally safe and now says why: `H265Planner` snapshots `dpb_refs` AFTER `decode_rps`. **Four more stale promotion sites**, past the four already fixed: `Backend:: NativeD3d11va`'s variant doc, `Decoder::new`'s Windows rung comment, `lib.rs`'s module note and `clients/session/README.md`. Two sites that used the AV1 leg as the live EXAMPLE of an unproven rung are marked as expired rather than deleted — the reasoning is what the next bad-evidence leg will need. **The AV1 dump was missing.** `PF_DXVA_DUMP` wrote h264 and hevc only, for the one codec whose libavcodec capture has never been taken and where the dump is therefore the only tool.	2026-08-07 21:34:59 +02:00
enricobuehler	ee61e8c9ba	fix(clients/pads): the phone mirror never needed the controller path's frame change ... Reverts half of 1eab4b66 and closes G10's open frame question, both settled by the same measurement. 1eab4b66 made two corrections to the Apple phone-gyro mirror. The negation was right and stays: Apple reports the gravity VECTOR, pointing down, while an accelerometer measures proper acceleration, pointing up at rest, and the wire carries the latter. The frame change was wrong, and this removes it. The mistake was a name collision. Two different frames are both called "the controller frame". GCMotion reports a CONTROLLER in (Right, Forward, Up) — measured on a real DualSense — which is not the wire's frame, which is why `GamepadCapture.forwardMotion` converts. The mirror's orientation remap resolves THIS DEVICE into the frame its header describes, x right, y up, z out of the screen. For the pose that mirror exists to serve — a phone clipped upright with the screen facing the player — "out of the screen" points at the player, so that frame is (Right, Up, Backward), which IS the wire's. It was already correct. Applying the controller path's conversion on top rotated it out of true: a phone sitting still would have reported gravity as −1 g on the roll axis rather than +1 g up, i.e. claimed to be lying on its edge. Reasoning by analogy is what produced it — "the mirror says controller frame, the capture path says controller frame, so the same fix applies". Both files say it; they mean different things. What caught it was measuring the Android twin, which does the same thing straight through. On glass: a DualSense on Bluetooth to a phone, streaming to a Linux host, reads +1 g on the up axis end to end. Had the Apple mirror needed a conversion, the Android one would have needed the same one and would have been visibly wrong. It is not. The same run settles G10's frame, which shipped straight-through and explicitly unverified because nobody had put a Bluetooth pad in front of the platform sensor framework. Now somebody has. `PadSensors`' own first-sample log read `accel 0, 10000, 0` — exactly 1 g on slot 1 — and at the far end hid-playstation published gravity as +0.991 g on ABS_Y, with every rotation driving its correctly-named axis and the signs agreeing with gravity's independent witness on 95 of 100 rotating samples. Android hands a controller's sensors over in the pad's own frame, as documented. No remap, and the comment now says measured instead of assumed. Worth recording why the earlier suspicion was wrong, since it is the same trap in the other direction: Android's DEVICE sensor frame really does put +z out of the screen, so a flat phone puts gravity on z — but a CONTROLLER's sensors are reported in the controller's frame, not the phone's. One platform, two conventions, chosen by what the sensor is attached to. Gate: Apple macOS `swift build` + full suite (215 tests, 5 skipped, 0 failures) and the iOS-triple typecheck, which is what actually compiles `DeviceGyro.swift`; Android `:kit:compileDebugKotlin`, `:kit:testDebugUnitTest`, `:app:compileDebugKotlin`. Green. Still owed: `DeviceGyroRemap`'s four orientation matrices remain derived — this run used a controller's own sensors, not the mirror, so it says nothing about them. They need a gyro-less pad on wire index 0 and a phone turned through all four orientations.	2026-08-07 21:28:13 +02:00
enricobuehler	7a4cdac5b7	fix(client/android): a Bluetooth pad's gyro obeys the same reachability gate as the rest ... Follow-up to the G10 merge. The new sensor path was written against main, which does not carry this branch's G8 work, so it forwarded motion unconditionally — the one thing G8 exists to stop. `deviceMotion` checked `forwarding` and nothing else. A Bluetooth DualSense in a session that resolved to an X-Box backend would stream ~200 Hz of samples the host parses and discards, for the whole session, exactly as the USB capture path did before G8. Not a regression against shipped behaviour — the path is new — but it would have shipped the defect back into a client that had just been taught not to have it. `Slot` now carries `motionReaches`, asked once at open off the kind that pad DECLARED, in the same shape `ExternalPad` already used. Per pad, not per session: under Automatic the handshake carries the active pad's kind, so a couch with an X-Box pad on slot 0 and a DualSense on slot 1 must not have slot 1's working gyro suppressed by slot 0's answer. The notice moved to where the truth is known. `openSlot` knows only what kind a pad declared, not whether it physically has a gyro — that is discovered later, when `PadSensors` finds a gyroscope and calls `setDeviceHasSensorMotion`. Raising it there is the only placement that both tells a player whose gyro is being dropped and stays silent for the pads that never had one. Also unified the last duplicate scale in the module. G10 hoisted the wire units into `Gamepad` and pointed `DeviceGyro` at them, but `DsDevice` kept its own `20L` / `10000L` — and `Gamepad`'s new comment claims every sender goes through one place, which was not yet true. Two copies of a unit constant in one module is precisely the defect this program opened with (a DualShock 4 blob 40× hot because a second copy had drifted), so the claim and the code now agree. `val` rather than `const val` only because widening to Long is not a constant expression; Long is deliberate, since the calibration arithmetic overflows an Int before it divides. Proven non-vacuous rather than assumed: changing `Gamepad.MOTION_GYRO_LSB_PER_DEG_S` from 20 to 16 now fails four named cases across three classes — `DsDeviceTest.calibrationRescalesRawCountsOntoTheWireUnits`, `.theHostsOwnBlobIsAPassthrough`, `.parseStateAppliesTheCalibration` and `DeviceGyroTest.wireUnitConstants`. Before this change `DsDevice` would not have noticed. The gate itself has no test, for the reason the surrounding code already documents: `GamepadRouter` needs Android plus a live JNI handle, there is no Robolectric in this module, and a mock would test the mock. It is argued at the call sites instead. Gate: `:kit:compileDebugKotlin`, `:kit:testDebugUnitTest`, `:app:compileDebugKotlin`, `:app:testDebugUnitTest` — kit 75 / app 67, 0 failures, counts read out of the JUnit XML. The merge reconciles: 62 on this branch, plus 6 from main's DeviceGyroTest, plus G10's 7.	2026-08-07 20:18:39 +02:00
enricobuehler	e81ab1ff2b	Merge branch 'worktree-agent-a6f74e8ea7824fb56' into worktree-gyro-p0-correctness	2026-08-07 20:14:41 +02:00
enricobuehler	8f1081719f	feat(client/android): a Bluetooth controller's gyro stops going nowhere ... Android had two motion sources and both of them are USB claims. DsCapture takes a Sony pad's HID interface away from the kernel; Sc2Capture does the same for a Steam Controller 2. Everything else — a DualSense, a DualShock 4, a Switch Pro, an 8BitDo, paired over Bluetooth — arrives as an ordinary InputDevice. Its buttons worked, its sticks worked, and its gyro was dead, silently, with no log line and nothing in the UI to suggest the pad had a sensor at all. That is not one controller, it is the whole class of controllers people actually pair to a phone. The platform has had the answer since Android 12: InputDevice.getSensorManager hands back a SensorManager scoped to that one controller, carrying its TYPE_GYROSCOPE and TYPE_ACCELEROMETER. PadSensors registers a listener per forwarded pad that has a gyroscope and sends the samples on that pad's wire index. Below API 31 it registers nothing and the pads behave exactly as they did. It is built on DeviceGyro's shape, because the phone mirror had already paid for these lessons. One dedicated HandlerThread, never the main one. Batching off (maxReportLatencyUs = 0) — batching would trade away precisely the latency gyro aim exists to avoid. 200 Hz requested, which is also the ceiling the framework grants an app without HIGH_SAMPLING_RATE_SENSORS, so asking for more would only be capped. And a feed that lets go of a pad still alive parks its rotation at zero first: the host holds motion as state and re-emits it in every virtual-pad report, so an angular velocity left behind is a pad that rotates forever. Two writers on one pad's motion is the failure this program has spent the day unpicking, so the coordination is explicit in three places. A USB capture wins: DsCapture.startUsb already calls releaseDevice at claim time, that closes the slot, and the close now also takes the sensor listeners off — the claim makes the InputDevice vanish anyway, but going through the explicit teardown is what makes the ordering deterministic instead of a race against the platform's own removal callback. The phone-gyro mirror stands down: registering flips a bit the router reports through padHasOwnMotion, which DeviceGyro re-reads on every sample and answers with its own zero park. And a pad with an accelerometer but no gyroscope is deliberately NOT taken — it could only send gravity while pinning rotation at zero, on a pad the mirror is otherwise entitled to speak for, which is the same fight in a quieter costume. The wire units are measured fact (punktfunk_core::input::gamepad: 20 LSB/deg·s, 10000 LSB/g), and they now live in exactly one place on this client: Gamepad.motionGyroWire / motionAccelWire, which DeviceGyro was hand-inlining a second copy of. The gyro program's first finding was a client sending 40x hot because a second copy of a number had drifted, and the merge that followed found a sender nobody remembered to correct. One function, both callers. THE AXIS FRAME ON THIS PATH IS NOT VERIFIED, and the mapping is deliberately straight through rather than guessed at. What is known: the wire is a unit passthrough into a virtual DualSense report, and that report's frame was measured over raw HID on 2026-08-07 as (Right, Up, Backward-toward-the-player) carrying (pitch, yaw, roll), right-handed — which is why the USB path forwards the pad's own order un-remapped and is correct to. Android documents its sensor frame for a handheld device as +x right, +y up, +z out of the face, the same frame once "the face" is read as the one the player looks at. So straight through is what the documentation implies. What nobody has done is put a Bluetooth DualSense in front of the platform sensor framework and compare — those numbers come through a HID driver and InputFlinger's sensor mapper, either of which could permute or negate without saying so. A plausible-looking wrong remap is exactly the bug this program keeps finding, so the code says unverified and names the measurement that settles it, and each feed logs its first converted sample so the cheapest half of that measurement — which slot gravity lands on with the pad flat and still — costs a logcat line. PadSensorsTest pins the scale, the clamp, the rounding and the straight-through order, mutation-checked four ways: 20 to 16 fails gyroScaleFromRadiansPerSecond and straightThroughFrame, reversing the axis order fails straightThroughFrame, truncating instead of rounding fails roundsToNearestNotTowardZero, and negating the accel fails restingPadIsTheHostNeutral. Its frame expectations are written to change together with any remap that lands, not to be edited around one. GamepadRouter needs Android and a live JNI handle and there is no Robolectric here, so its half is argued in comments beside the code, as DsCapture's claim ordering already is. Gates: kit 65 tests (58 before, plus 7), app 67 unchanged, 0 failures, read out of the JUnit XML rather than off a green build.	2026-08-07 20:12:39 +02:00
enricobuehler	979ed8f426	docs(clients/pads): say that an X-Box virtual pad has nowhere to put motion ... G17's motion half. The docs described what the CLIENT sends and stopped there, which made a promise the host does not always keep. The support matrix said a desktop client forwards motion from any pad SDL exposes a gyro on "and the host injects it into the matching virtual pad". The first clause is true; the second is only true when the virtual pad has a motion plane. The X-Box 360 and One backends do not — no gyro in their HID contract — so the host parses every sample and discards it. That is where *Automatic* lands anything it does not recognise as Sony or Valve, an 8BitDo with a perfectly good gyro included, and where a Switch Pro lands on a Windows host with no `hid-nintendo` backend to fold it into. A reader following the old text would conclude their gyro was broken. The failure has no other symptom: motion just does nothing. So both pages now say what to do about it — pick a DualSense-class type — and the client-settings page says it where the choice is actually made, next to the degrade paragraph that explains why a session ends up on an X-Box pad in the first place. The Deck's Steam-Input requirement moves out of Decky's settings blurb, which is the one place a Deck user streaming FROM the Deck would never look. With Steam Input on, Steam hands the app its own virtual X-Box pad, so no controller-type choice can help: there is no gyro on the pad the client can see. The picker help text now mentions motion on GTK and Android, which is where it was missing — Windows already said it and Apple says it in its own words. One sentence, the same sentence, so the four clients answer the question the same way. This is the doc side of the on-screen notice that shipped earlier in this branch. The two exist for the same reason and now agree: the client says it when it detects the case, the docs say it when someone goes looking. Not covered: the preset COUNTS in note 1 ("Android and the console home offer six … Windows and Apple offer five") are still unverified against the four pickers, and the Apple picker's missing Steam Deck entry is a code gap rather than a doc one. Both are noted in the plan and left for their own change rather than guessed at here. Gate: Linux CI image fmt + `clippy --locked --all-targets -D warnings` on punktfunk-client-linux (the GTK string is compiled) plus the core crates and their tests; Android `:app:compileDebugKotlin` + `:app:testDebugUnitTest`. Green.	2026-08-07 20:11:28 +02:00
enricobuehler	1eab4b6626	fix(client/apple): the phone-gyro mirror was left on the old motion convention ... Surfaced by the merge. `DeviceGyro`'s header states the contract plainly — "units and axis semantics match `GamepadCapture.forwardMotion` exactly … the same convention, so a future sign/scale correction lands in one place for both sources" — and this branch made two such corrections in only one of the two places. That is a promise the code stopped keeping the moment the controller path was fixed. Both were true parity when #88 was written; both broke here. **The negation.** `GamepadCapture` sends `-(gravity + userAcceleration)` because Apple reports the gravity VECTOR, pointing down, while an accelerometer measures proper acceleration, pointing up at rest — and the wire carries the latter. The mirror sent it un-negated, so a phone lying still told the host it was accelerating downward at 1 g. The comment above that line even claimed the convention matched. **The frame.** The mirror's remap targets the controller frame its own header describes — x right, y up, z out of the screen — which is exactly GameController's frame, and that is not the DualSense report frame the wire is defined in. So the same change of basis the controller path now takes applies here, after the orientation remap rather than instead of it: the remap resolves which way the phone is being held, and the basis change translates the result into the pad's language. Two different jobs that happen to compose. Order matters for the closing sample too. `stop` replays `lastAccel` beside a zero gyro so "rotation stopped" does not also read as free fall; `lastAccel` is recorded after both conversions, so what gets parked is what was actually sent. Left alone deliberately: `DeviceGyroRemap` itself and `DeviceGyroRemapTests`. The orientation matrices answer a different question — which way is the phone being held — and nothing measured this evening bears on them. They remain derived-not-verified, as their own doc says, and the on-glass pass that owes the controller path a check owes them one too, in all four orientations. Gate: macOS `swift build` + full suite (215 tests, 5 skipped, 0 failures) and the iOS-triple typecheck green — the latter is what actually compiles this file, since the whole thing is `#if os(iOS)`.	2026-08-07 19:34:51 +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	0170da2a5f	fix(client/apple): stop dropping rotation, and stop inventing it ... G13 — the three capture-fidelity findings from the gyro sweep, two fixed and one argued. **The 4 ms floor was a DROP, and it was shedding real rotation.** A sample arriving 3.9 ms after the last one was discarded outright. That is the wrong shape for this signal: buttons and sticks are absolute state, so a dropped frame costs nothing — the next one says everything it would have. Angular velocity is a RATE, and a consumer integrates it into an angle, so a dropped sample is rotation that happened and can never be recovered. GameController's delivery jitters around the pad's own ~250 Hz, so a floor set AT that rate does not shed a rare extra sample; it sheds a steady fraction of every turn. And the error is one-signed, so it accumulates — aim drifting short, which reads as bad sensitivity rather than as a bug. Nothing needed the ceiling. GC delivers at the sensor's rate rather than faster, the SDL client has always forwarded every sample, and the host's idle watchdog is a 100 ms timeout this cannot outpace. The throttle's two fields went with it: `lastMotionNs` was left set-but-never-read once the guard was gone, and `motionIntervalNs` had no other consumer. (Notes elsewhere say `flush` parks motion and reads it — that is PR #88's branch, not this one. Checked rather than assumed.) **An X-Box pad was streaming gyro it does not have.** Capture attached to any `GCMotion`, and an X-Box controller exposes one that reports gravity and NOTHING else. So the client sent a permanently-zero `rotationRate` to the host as authoritative gyro, under a declaration saying this pad has one. That is worse than having no motion plane at all: a game sees a controller being held perfectly still forever, and there is nothing to fall back to and nothing to notice. Now gated on `hasRotationRate`, which is GameController's own answer to the question we actually mean. The settings badge had the same bug from the same cause — `hasMotion` was `motion != nil`, so an X-Box pad got a gyroscope icon. It now reads `hasRotationRate` too. One wrong predicate was driving both the UI promise and the wire behaviour, which is why they were wrong together. That also simplifies G8's "your gyro can't reach this session" notice, which had to test `hasRotationRate` itself to avoid nagging about a gyro the pad never had. With the attach gated on it, the notice is just the else-branch. **Motion stays on the main queue, and this is the argument for why.** GameController's `handlerQueue` is a property of the CONTROLLER, not of an element, so moving motion off main moves buttons, sticks, the touchpad and the escape chord with it. This class is `@MainActor` throughout — eight `assumeIsolated` sites, the slot table, the gesture timers — so that is a rewrite of the isolation model rather than a queue assignment, and it would put the tvOS escape chord (the only controller way out of a stream there) on a background queue. That is a real risk for a speculative gain. The comment says so at the call site, and names the measurement to make first if it ever does bite: the host's per-pad motion inter-arrival histogram already reports exactly this and would say whether the delay is client-side or on the wire. Gate: macOS `swift build` + the full suite (215 tests, 5 skipped, 0 failures) and the iOS-triple typecheck green. No test pins the throttle removal or the capability gate: both are properties of live `GCMotion` delivery, which this module cannot fake — there is no injectable seam, and inventing one to assert "we called sendMotion twice" would test the mock. They are argued at the call sites instead, in the same spirit as the parts of `DsCapture` that are not unit-testable in their module either. On-glass verification is owed with the two already outstanding on that rig.	2026-08-07 19:12:02 +02:00
enricobuehler	efb7f99129	fix(client/apple): motion arrived in the wrong frame — measured against a real pad ... G16 step 1, and the second half of what 9e9bb9f4 started. That commit fixed the SIGN of acceleration (Apple reports the gravity vector, pointing down; a pad reports proper acceleration, pointing up). This fixes the FRAME, which is a separate defect and was never going to show up as an inverted axis — it shows up as roll where the game reads yaw. The wire is a unit passthrough. `dualsense_proto::write_report` puts gyro[0..3] and accel[0..3] straight into the virtual pad's report bytes 16.. and 22.., in order, with no permutation — the same slots a real DualSense fills. So the frame the wire is DEFINED in is the pad's own report frame, and forwarding GameController's x/y/z unconverted was speaking a different language with the same vocabulary. Both frames measured 2026-08-07 from ONE physical DualSense on one desk, read twice — over raw HID and through GameController — so this is two readings of the same controller in the same orientations rather than two documents: DualSense report frame: (Right, Up, Backward) axis 0 pitch, 1 yaw, 2 roll GameController frame: (Right, Forward, Up) Right is already slot 0; Up is GC's z and moves to slot 1; slot 2 wants Backward, which is GC's y negated. Hence (x, z, -y), applied to gyro AND acceleration because it is a change of basis and both live in that basis. Notable: the wire's documented naming was right all along — gyro[0]=pitch, [1]=yaw, [2]=roll is exactly what the hardware does. And Android needs no remap at all: it forwards the pad's own axis order un-remapped, which is correct. Its old reading was purely the scale bug f6de620f fixed. Only Apple was converting nothing. How the hardware frame was established, since a wrong frame here is invisible. Gravity at rest put +0.997 g on axis 1. Yaw clockwise-from-above drove axis 1 negative (98% of the rotation), pitch nose-down drove axis 0 negative (100%), roll right-side-down drove axis 2 negative (95%) — plain right-hand rule, and (a0 x a1 = a2) confirms the triad is right-handed. The accelerometer then corroborated the gyro's assignment independently: under pitch-down axis 2 rose 0.160 -> +0.339 (nose down raises the back, so world-up gains a Backward component) and under roll-right-down axis 0 went +0.021 -> -0.197, while yaw left acceleration untouched. Two different physical quantities agreeing on one triad. Apple's frame took four attempts, and the failures are worth recording because each was a different way to be confidently wrong: - peak |w| over a window containing BOTH the tip-down and the return stroke can record the return, with the opposite sign. Yaw (a continuous one-way spin) was unaffected; pitch and roll were exactly the two that disagreed with everything else. - reading `gravity + userAcceleration` when `hasGravityAndUserAcceleration` is FALSE yields a constant (0,0,1) in every orientation. It looks like data. The tell is that it never moves. The client's own else-branch on `m.acceleration` is the correct read and is what the instrument now mirrors. - `da/dt = -w x a` holds only for gravity, so testing it during vigorous waving — when `m.acceleration` carries inseparable linear acceleration — fits nothing. The frame that survived all of that: static poses, three of them, three repetitions each. Nose-down moved axis 1 by -0.635 (so axis 1 is Forward), right-side-down moved axis 0 by -0.686 (so axis 0 is Right), flat put +0.99 on axis 2 (Up). That conclusion holds whether or not the acceleration negation is right, because negating flips the measured vector and the physical direction it represents together. Confidence, stated honestly. The accelerometer half is solid: nine pose measurements, and mapping the flat pose through gives (+0.005, +0.992, +0.192) against the hardware's own (+0.021, +0.997, +0.160) — all three components, including the small tilt term that is what distinguishes this mapping from the five other permutations that also put gravity on slot 1. That the gyro shares the frame unmodified rests on a weaker measurement: a gravity-dominated consistency test that preferred (+x,+y,+z) by 1.22x, which is a margin, not a landslide. It is corroborated by the yaw reading (the one rotation measured without the return-stroke ambiguity) agreeing with right-hand rule in that frame, and by the peak-vs-return mechanism explaining the two that did not. A device-side confirmation is still owed and is listed below. The tests carry the measurements, not just the conclusion. Resting gravity is asserted against BOTH readings of that pose; each rotation is asserted to reach the slot the wire reads it from; and two properties guard the shape rather than the numbers — that the conversion is an isometry (a basis change may not stretch anything) and that it preserves handedness. That last one matters most: a permutation with the wrong number of sign flips is a REFLECTION, which looks plausible axis by axis and inverts every rotation. Mutation-checked: dropping only the negation fails 6 assertions across 4 of the 5 cases, the handedness test among them. Owed, and not claimed done: on-glass re-verification through a real iOS device, together with the two already owed on that rig (the 9e9bb9f4 sign fix and the Android calibration read) — one pass covers all three. G14's DualSense neutral acceleration is now unblocked by this measurement (1 g on slot 1, not the z-up the notes assumed) but is deliberately left to its own change; and that constant must NOT be propagated to switch_proto, which is a different device whose frame nobody has measured. Gate: macOS `swift build` + the full suite (215 tests, 5 skipped, 0 failures) with the five new cases observed in the run's own output, and the iOS-triple typecheck green.	2026-08-07 18:41:54 +02:00
enricobuehler	7cab7ae6bc	feat(client/android): say when a captured pad's gyro can't reach the session ... G8's Android half, and the last of the three clients. Same failure as the other two: a controller with a gyro, in a session whose virtual pad has no motion plane, does nothing when tilted — silently, with no way from the couch to tell that apart from a broken sensor. The fix is the Controller type setting, so the notice names it. Android read neither the requested nor the resolved backend, so this needed a plumb. What it did NOT need was a third copy of the rule. `nativePadMotionReaches` takes the kind a pad declared and answers off `pad_motion_reaches` in punktfunk-core, where the argument and the tests already live. The rule is subtler than it looks — the host builds each pad from its OWN declaration and folds what it cannot build, so neither the declaration nor the session echo answers it alone — and every way of getting it wrong is silent. A Kotlin transcription would have been a third thing to keep in step with the host, which is exactly how the SDL half got it wrong the first time. Asked once per pad, at claim, in `openExternal` — where the pad's kind is already being declared to the host — and the answer held for the pad's lifetime on the `ExternalPad`. Not per sample: this runs at a DualSense's full report rate. `hasGyro` gates only the NOTICE, and defaults to false. `DsCapture` passes true — every pad it captures is a Sony one whose IMU is a headline feature, forwarded on the rich plane. `Sc2Capture` keeps the default, because the Steam Controller 2's motion rides inside the opaque passthrough report that `hidReport` carries, which nothing here may second-guess: warning about motion for a pad that never calls `motion()` would be a notice about a feature the player never lost. The suppression itself is on `motion()` regardless, where it costs a dead pad nothing and stops a live one paying to send samples the host will decode and discard. The notice sits at the BOTTOM of the stream overlay, unlike the mic-chord confirmation at the top. The two can coincide — a pad is claimed at roughly the moment someone might be muting — and one landing on the other would cost the user both. It holds 6 s rather than the mic chord's 1.6: that one confirms something the user just did, this one explains something they did not, in a sentence they have to read. Nulled at teardown beside `onExitArmed`/`onMicChord`, for the same reason those are — a slot closing during release must not poke Compose state on the way out. Not covered by tests, and this is a limit of the module rather than a choice: `GamepadRouter` needs Android plus a live JNI handle, there is no Robolectric here, and the predicate it defers to is pure Rust that already has its table. So the parts that carry the reasoning are argued in comments, as `DsCapture`'s claim/teardown ordering already is. What IS mechanically verified is the piece that a compiler cannot catch and a device would fail on: the JNI symbol `Java_io_unom_punktfunk_kit_NativeBridge_nativePadMotionReaches` is present and global in the built arm64-v8a `.so`, so the `external fun` resolves rather than throwing `UnsatisfiedLinkError` at the first pad. Gate: `:kit:compileDebugKotlin`, `:kit:testDebugUnitTest` (62 cases, 0 failed, read out of the JUnit XML rather than inferred from a green build — unchanged from this branch's previous count), `:app:compileDebugKotlin` and `:app:testDebugUnitTest` (67 cases, 0 failed), with `:kit:cargoNdkRelease` rebuilding the JNI crate clean across all three ABIs, plus `cargo fmt --check` on it. On-glass verification is owed on the rig the earlier legs used, and is worth doing as one pass with the two already owed there.	2026-08-07 17:02:04 +02:00
enricobuehler	aaa58ad817	feat(client/apple): say when a pad's gyro can't reach the session, and stop powering it ... G8's Apple half — the UI hint 77797a9e left owed, plus the suppression, which on this client is worth more than it was on the SDL one. The failure being fixed is entirely silent. A controller with a gyro, in a session whose virtual pad has no motion plane, simply does nothing when tilted: nothing in the app says so, and from the couch a session that resolved an X-Box backend is indistinguishable from a broken sensor. The fix is the Controller type setting, so the hint has to name it — a badge that only said "motion unavailable" would leave the player exactly as stuck. Asked per pad, off what the slot declared, via the predicate punktfunk-core now carries. `GamepadCapture` is the one client where this is naturally per pad already: `openSlot` computes `manager.declaredKind(for:)` and puts it in `slot.pref`, so the question is answered where the pad is opened rather than on every sample. `GamepadType.motionReaches(declared:asked:resolved:)` is static and pure so it can be tested without a live session; the connection's instance method fills in the two halves it owns, and `requestedGamepad` is stored beside `resolvedGamepad` for the same reason it exists in the Rust client — the echo is only this pad's answer when the pad declared what we asked for. Where Apple differs from the SDL client, and better: it never powers the IMU. The existing code already declined to activate sensors when forwarding was off, reasoning that with nothing to forward there is no reason to make the pad stream gyro over Bluetooth and burn its battery — `closeSlot` is careful to power them back down for exactly that reason. A host that built this pad a backend without a motion plane is the same situation, so it takes the same branch. No per-sample check, no handler attached, and a DualSense in an X-Box-class session stops paying for a sensor nobody reads. The hint fires only for a pad that really has a gyro (`motion.hasRotationRate`). A gravity-only GCMotion — what an X-Box controller exposes — would otherwise produce a notice about a feature the player never had. That is a narrower condition than the capture path itself uses, deliberately: making the capture gate agree is G13's job and its own change. The badge sits in the bottom-centre stack with the muted-mic badge and the start-of-stream banner, at every stats tier and with the overlay off, because this is not a statistic. Unlike the mic badge it is not a control: the setting is not reachable mid-stream on every platform and applies from the next session anyway. So it states the fact, names the setting, and leaves after the banner's same 6 s. Every platform including tvOS — a DualSense on an Apple TV is an ordinary way to play, and is exactly the pad this happens to. The model owns the expiry rather than the view, so a second pad's hint replaces the first cleanly instead of stacking, and ending the session cancels a pending clear rather than carrying a stale hint into the next stream. Non-vacuity proven by mutation, not assumed: collapsing the predicate to `resolved.hasMotion` fails 4 assertions, including the mixed-pad row that is the whole reason it is not a session-level check. The table mirrors the Rust one row for row — a client that disagrees with the host here either kills a working gyro or streams ~250 Hz into a void, and both are silent. Gate: macOS `swift build` + the FULL suite (210 tests, 5 skipped, 0 failures) with the two new cases observed in the run's own output, and the iOS-triple typecheck green (`arm64-apple-ios17.0`, iOS slices + hand-assembled xcframework per the memory recipe) — the badge and the overlay it joins are on every platform, so the macOS build alone would not have covered them. tvOS remains unverifiable from this Mac; the badge deliberately reuses the neighbouring banner's shape rather than introducing anything tvOS-specific.	2026-08-07 16:55:03 +02:00
enricobuehler	7f822d9c41	Merge pull request 'Apple mic uplink: the microphone was never in the audio graph, so nothing ever pulled it' (#94) from fix/apple-mic-uplink into main ... Reviewed-on: #94	2026-08-07 14:33:44 +00:00
enricobuehler	9db2c06140	Merge pull request 'Gamepad UI (iOS): the field pass — a linear drum, no close chrome, a heading that leads, and strips that assemble themselves' (#93) from worktree-gamepad-ios-polish-2 into main ... Reviewed-on: #93	2026-08-07 14:33:18 +00:00
enricobuehler	d2d5058d0b	fix(client/apple): the mic was never in the graph, so nothing ever pulled it ... ROOT CAUSE, from the reporter's device log: 16:25:49.093 mic capture: 48000 Hz, 1 ch <- tap installed, format fine 16:25:49.235 audio engines joined - voice processing active ... 13 s of session, no errors, and the 10 s silence verdict NEVER fires The engine started clean and the tap was installed against a valid format - so neither the format timing nor the encoder was the fault. The tripwire fires after ten seconds of CAPTURED frames and never fired across a 13-second session: the tap received nothing at all. Because the capture side must be pulled, and only the render graph pulls anything. On the combined engine the input node carried a tap and no connection, so it was not in the graph and nobody drove it: the IO unit came up (the recording indicator lit for a beat, then went out as the input went idle) and not one buffer ever reached the tap. No error, no failed start - a session that quietly sent no microphone. The input now runs through a silent sink into the main mixer, which is what Apple's own voice-processing sample does. outputVolume = 0 because the mic must reach the graph and never the speaker. The split path never needed this - a capture-only engine has the input node AS its graph - so this broke exactly when the combined topology became the default. Verified: swift build (macOS), swift build --triple arm64-apple-ios17.0, swift test 208 passed. Awaiting the reporter's on-device confirmation.	2026-08-07 16:30:29 +02:00
enricobuehler	8e8d30202c	fix(client/android): a Sony pad's buttons no longer wait on its calibration ... Supersedes the parse gate in 26b0819f. The off-thread read, the claim token, the teardown ordering and its bounded wait all stand — only what happens in the gap changes. 26b0819f held every report back until the calibration read came home, so a pad that stalled on EP0 could feel dead for up to the link's 250 ms timeout: no buttons, no sticks, nothing. Reports are now forwarded immediately and their motion scaled by the nominal calibration until the real one lands. That gap is exactly the behaviour that shipped before f6de620f — acceleration ~18% short, gyro unscaled — for about a millisecond. Nobody can feel that. A controller that ignores a button press for a quarter of a second is not in the same category, and it is the only one of the two a user would ever report. It is also the safer of the two conservatisms available here. The rejected third option, forwarding motion as zeroes until the real numbers arrive, would have the host read a still pad as being in free fall — a lie about the physical world rather than an imprecision about it. The nominal constants are merely a slightly wrong scale. The token is more load-bearing under this, not less. With a gate, an unpublished calibration meant "parse nothing"; now it means "scale nominally", so begin() clearing the previous pad's value is the whole reason a re-claim falls back to the nominal constants instead of silently inheriting factory numbers belonging to a different unit — which are, in general, further off than nominal. The fallback therefore lives in the hand-off itself (MotionCalHandoff.effective) rather than as an elvis at the call site: restoring the gate now means changing the type's API, not deleting three characters in onReport. The tests moved with the contract. They assert the nominal calibration is what is in effect during the gap, rather than merely that the slot is empty — an empty slot is now compatible with either behaviour, so asserting on it would have let a regression pass. Added the case the change exists for: the same raw report, parsed either side of publication, forwards identical buttons and sticks while its gyro and acceleration convert differently. Mutation-checked three ways — dropping the nominal fallback fails all five cases, dropping begin's clear fails the inheritance case, dropping the token check fails three. Gate: `:kit:compileDebugKotlin`, `:kit:testDebugUnitTest` and `:app:compileDebugKotlin` green on a forced clean rerun, 62 cases across the module, 0 failed, with the five hand-off cases read back out of the JUnit XML. The on-glass re-verification f6de620f owes is still owed and unchanged.	2026-08-07 16:23:48 +02:00
enricobuehler	428377eaa1	Merge pull request 'Intel Arc never used Vulkan Video because our pNext order fed the decode caps to the wrong struct' (#92) from worktree-probe-codec-names into main ... Reviewed-on: #92	2026-08-07 14:13:14 +00:00