193 Commits

Include renames

Author	SHA1	Message	Date
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	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	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	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	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	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	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	7e34ca3d5e	fix(client/apple): a session that can't voice-process still sends its microphone ... Field report: mic uplink dead on iOS, iPadOS and macOS alike, while Android on the same host works - so the host and the wire are fine. Two defects in the combined (voice-processing) engine, which became the default on all three Apple platforms a week ago and has never run on a device - CI only runs swift test on macOS, and the loopback test counts datagrams without decoding them. - The tap read the input format before the engine was prepared. Enabling voice processing swaps the engine's IO unit for the VPIO one and renegotiates its formats; until prepare() the input node can still report the pre-swap state, 0 Hz / 0 channels included, which installMicTap correctly refuses as 'no usable input device'. Both topologies now prepare first, so the chain is built against what the voice processor actually emits. - A mic chain that failed on the voice-processed engine took the whole uplink down for the session: that arm fell back to playback ONLY. The sibling failure a few lines above - the voice processor refusing to engage at all - already falls back to the split path, which is a working mic without echo cancellation. Both arms do that now. The mic outranks the AEC. Not reproduced locally (no Punktfunk entries in this Mac's log store, and collecting the device's log needs root), so this is a strong inference plus one proven logic defect rather than a confirmed fix. If it persists, Console filtered to subsystem io.unom.punktfunk / category audio names the stage: 'mic capture: N Hz' then 'audio engines joined' then, 10 s in, either 'mic uplink OK - peak ...' or the SILENCE warning. Follow-up worth doing separately: nothing reports whether the uplink actually opened, so the HUD offers a Mute Microphone button over a session sending nothing. Android gates that on a real micRunning signal.	2026-08-07 16:09:33 +02:00
enricobuehler	9e9bb9f466	fix(client/apple): acceleration was upside down — measured on glass ... G16, first result. A DualSense paired to an iPhone, streaming to a Linux host, lying flat and face up: hid-playstation decoded z = −0.99 g where a DualSense owes +1.00. Vector magnitude was 1.006 g, so the scale was already correct — this is purely direction, and it was wrong for every accelerometer sample the Apple client has ever sent. The cause is a convention mismatch, not a sign typo. Apple reports acceleration as the gravity VECTOR, which points down: a device face-up on a table reads z = −1. An accelerometer physically measures proper acceleration, and at rest that is the +1 g normal force pushing UP — which is what a DualSense's report, and therefore our wire, carries. The two are exact negatives. Both branches were affected, because `m.acceleration` follows the same Apple convention as the gravity/userAcceleration split, so reading the "raw vector" was not an escape from it. `rotationRate` is a true angular rate and needs no flip. The same session confirmed that independently: rotating the pad clockwise seen from above produced a negative yaw, which is correct under the right-hand rule about an up-pointing Z. That asymmetry — accel wrong, gyro right — is itself evidence for this diagnosis rather than a blanket frame error, and it is why the fix is three negations at one site instead of a remap. The sweep predicted this ("Apple accel plausibly INVERTED — CoreMotion gravity -1 g vs DS +1 g up at rest") but could not confirm it without hardware. It is now measured, and the mechanism is confirmed in the code rather than inferred from the number. Method, for whoever repeats it: the readout is python-evdev on the host reading the virtual pad's own motion node, dividing by the axis `resolution` the kernel publishes, so it prints deg/s and g. That is downstream of the calibration blob — the same layer a game reads — which is what makes a sign error visible to a human at all. Two things this does NOT establish. The host was a KVM guest, so the DualSense could not be attached natively for a side-by-side reference reading; the test stands on the DualSense convention being a fixed property of the hardware, which is decisive for the at-rest sign but weaker for the gyro axis ORDER. And the fix itself is unverified on glass: confirming it needs a rebuilt client on the device, so someone should re-run the same at-rest reading and see +1.00. Gate: `swiftc -parse` clean. A full typecheck needs the gitignored PunktfunkCore.xcframework assembled first and has not been run.	2026-08-07 14:56:27 +02:00
enricobuehler	f7ef41b45b	Merge pull request 'feat(clients): the phone's gyro can speak for a gyro-less pad' (#88) from worktree-gyro-phone-mirror into main ... Reviewed-on: #88	2026-08-07 09:47:04 +00:00
enricobuehler	1f54b75c5c	feat(client/apple): the phone's gyro can speak for a gyro-less pad ... Opt-in "Gyro from this device" (DefaultsKey.gyroFromDevice, off by default, iOS only): while player 1's forwarded controller reports no rotation rate of its own — no GCMotion, or the gravity-only motion an Xbox pad exposes — this device's IMU sources pad 0's wire motion instead. The rumble-on-device mirror's sibling, data flowing the other way: same session-scoped UserDefaults read, same hardware-gated settings rows, same pad-0 rule. DeviceGyro wraps CMDeviceMotion at the ~100 Hz CoreMotion ceiling on a dedicated serial queue (not main — the controller path's main-queue delivery is a known jitter source), converts with the shared GamepadWire constants, and rotates each sample from the device's portrait frame into the controller frame by interface orientation, so a phone clipped landscape yaws when the player yaws instead of rolling. The remap matrix is derived and pinned by DeviceGyroRemapTests. GamepadCapture owns engage/stand-down (reconcile, suspend/resume, stop), and suppresses pad 0's controller-motion forwarding while the mirror runs — two writers on one pad's motion state would fight, and the accel-only stream would stomp the mirror's gyro with zeros. Also fixes the stale-motion latch from the gyro sweep on the controller path: flush now parks motion at zero (keeping the last accel, so gravity doesn't become free-fall), and the mirror's stop sends the same closing zero. The host holds motion as state and re-emits it — a nonzero angular velocity left behind read as endless rotation for as long as an overlay (Control Center pull-down) kept the app inactive.	2026-08-07 11:38:13 +02:00
enricobuehler	bbbcf321e5	Merge origin/main into worktree-native-decode-m0 ... main moved 93 commits while this branch ran. Two conflicts, both where main's new work sat next to M10's excision: packaging/flatpak/io.unom.Punktfunk.yml — main added the vendored gamescope WSI layer (the only route to HDR on a Deck) and, before it, a vulkan-headers module. Took both: this branch predates them and deletes neither. But the headers module's stated consumer was pf-ffvk's bindgen over FFmpeg's hwcontext_vulkan.h, and M10 deleted pf-ffvk — so it now reads as dead weight to the next person. It is not: the WSI layer IS a Vulkan layer, compiles against those headers, and builds after it, so module order is the dependency. Rewrote the rationale to say so, including why dropping it would be expensive to discover — flatpak.yml has no pull_request: trigger, so a manifest break reaches main invisibly and a tag then ships no Linux flatpak. Also recorded that the native decoder needs nothing from there: pf-vkdecode reaches Vulkan through ash, which is pure Rust bindings, no bindgen, no C headers. crates/pf-console-ui/src/screens/settings.rs — main restructured the gamepad settings into TABS, which removed the per-row section headers; this branch had left Some("Video") untouched from the merge base and added the pre-M10 decoder migration next to it. Git could not tell those apart. Took main's structure (no header, its deliberate change) with this branch's migration layered on: a stored `vulkan`, `vaapi` or `d3d11va` names no preset in the tabbed list and would render as "—", then silently rewrite the user's preference on the next save. Gates on the merged tree, Linux container: fmt clean; cargo check --workspace --all-targets clean; clippy --workspace --all-targets -D warnings clean; tests green across pf-vkdecode (187), pf-client-core (163), pf-console-ui (58) and punktfunk-host (447 of 448 — the one failure is the pre-existing gamestream::stream::tests::sender_delivers_batches, a UDP-loopback EINTR under qemu that fails identically on a pristine HEAD).	2026-08-07 10:50:32 +02:00
enricobuehler	b5205fef52	Merge pull request 'fix(client/apple): audio stops crackling on lossy, bunching Wi-Fi' (#82) from worktree-audio-wifi-distortion into main ... Reviewed-on: #82	2026-08-07 07:37:19 +00:00
enricobuehler	64c92da356	fix(client/apple): the jitter ring deepens on the sessions that actually starve ... The shared JitterPolicy grew an adaptive target floor — clustered genuine underruns raise the live target a step at a time up to max_target_ms, a long quiet spell relaxes it back — and the three Rust rings all run it via note_read. The Apple ring is the one hand-written mirror, and it mirrored the shed half but not the growth half: its target was pinned at the 20 ms base forever. On Wi-Fi that bunches arrivals (power-save is the classic; the field MacBook report is the symptom), 20 ms is regularly shorter than one delivery stall, so the ring re-primed through every stall for the whole session — crackle that never got better, on exactly the client where a Moonlight with a deeper buffer sounds fine on the same host and network. The ring now carries the full mirror of note_read: 3 underruns inside a 5 s window grow the target 10 ms (capped at COREAUDIO's 70), 30 s of quiet gives a step back, and the write-side hard trim follows the grown target (including the Rust policy's target+quantum guard, which the mirror also lacked). New tests pin the mirror to the Rust suite's expectations — growth, relax, the cap — plus the field scenario end to end: bunched 60 ms deliveries with every fourth burst 30 ms late converge to a silence-free tail instead of crackling forever.	2026-08-07 09:23:29 +02:00
enricobuehler	5c05246098	feat: M10 — FFmpeg is gone from the client ... cargo tree -p punktfunk-client-session finds no ffmpeg. The host still does, which is the whole point: pf-encode keeps libavcodec unconditionally and no host workflow, packaging script or licence file was touched. Deleted: crates/pf-ffvk, video_vulkan.rs, video_vaapi.rs, video_libav.rs, the libavcodec half of video_d3d11.rs, the av_log machinery, ffmpeg::codec::Id as the decoder's vocabulary (the quic CODEC_* wire constants now serve, which is why the evidence table was keyed on them), DecodedImage::VkFrame and ::Dmabuf, the presenter's AVVkFrame lane, and the ffmpeg-fallback feature with everything behind it. DrmFrameGuard collapses from an enum to a newtype, which removes an unsafe impl Send. Roughly 25,000 lines. Then the CI, packaging, licensing and docs work the plan's §6 lists: the Windows workflows lose FFMPEG_DIR, PF_FFVK_VULKAN_INCLUDE and their PATH prepend; the MSIX loses its DLL wildcard; the client .deb stops emitting libav sonames on its own because depends come from dpkg-shlibdeps; arch, flatpak and nix drop the dependency; and the README's "FFmpeg 7 or 8" contract narrows to the host. Three defects reached users' machines in the first cut, and none was in the deletion itself. All three desktop Settings UIs offer vulkan, vaapi and d3d11va as stored decoder values, so those strings sit in shipped settings files today. Refusing them by name — which is the correct rule for a stale pin — would have bricked every upgraded client whose owner ever touched that dropdown. They now migrate onto the native rung for the same hardware family, at decoder construction AND at each dialog's lookup, because a legacy value that matches no preset displays as "Automatic" and silently rewrites the user's preference on the next save. M9's evidence filter was deleted on the argument that with no libavcodec twin below, barring an unproven rung removes hardware decode rather than moving down one rung. That is true on Windows and false on Linux for Intel and every unknown vendor id, where prefer_vulkan_first is false and the order is native-vaapi → native-vk: a rung that has decoded nothing anywhere sitting above one that is 250/250 on three drivers. Every Intel Linux desktop would have moved from libavcodec VAAPI, shipping for years, onto pf-vaadec by default — and a rung that constructs and then produces wrong pixels leaves only by the error-streak demotion, which this codebase already documents as not tripping on the B580's strobing. The filter is restored as a narrow, pure, testable rule: an unproven rung yields to a proven one, and to nothing else. Windows deliberately passes no rung below, because that vendor family is the one with a measured wrong-pixel report against Vulkan decode, and trading no evidence for evidence of corruption is the wrong direction. And the notices still said FFmpeg was bundled. The root file is what both desktop clients include_str! and what the MSIX ships, three lines under the new card saying no FFmpeg is bundled; Apple's Acknowledgements said it too, on iOS, tvOS and macOS. The generator now emits four per-client files scoped by transitive closure — 0 FFmpeg mentions in each, verified — while the root file keeps it for the host. That also ends the standing false attribution of ffmpeg-next, GTK4, windows-rs and the NVENC SDK to an iPhone. Windows has no reachable box, so it was compiled instead: a cross clippy at -D warnings on x86_64 and aarch64-pc-windows-msvc with the C toolchain stubbed so build scripts run without linking. That gate immediately caught an include_str! path one directory too deep, which nothing else could have. Gates: container clippy -D warnings, 160 tests, workspace check, both Windows targets clean, client ffmpeg count 0 and host 2. The four decode crates are untouched, so the hardware rungs' 250/250 stands. ⚠ Owed and unrun: no GPU has executed any of this milestone. M8's on-glass software check, M7's D3D11 and VAAPI AV1 hardware legs, and M9's field bake all still want hardware, and the bake window and criteria remain the user's.	2026-08-07 08:58:47 +02:00
enricobuehler	d5e23146c0	feat(client): M8 — the software rung is openh264 and rav1d, and swscale is gone ... The ladder's last rung no longer runs FFmpeg. H.264 decodes through openh264, AV1 through rav1d, and HEVC is refused outright: no permissively licensed software HEVC decoder exists, so an HEVC session that exhausts its hardware rungs now tears down and re-dials advertising HEVC-less caps, and the host picks H.264. The plan calls that a first-class path; it is one. swscale is deleted, and with it the BT.601 default that its correction code existed to undo. Colour on the H.264 lane now comes from the same pf-bitstream planner every hardware rung submits from — openh264 reports no VUI at all — and AV1's comes per-picture from the sequence header. One colour source, one CSC: the old default is unrepresentable rather than merely fixed. Frames reach the presenter as three tightly-packed planes through the planar CSC pass, which had to be un-gated from the pyrowave feature and its device probe, since the last rung must exist on devices that failed that probe. rav1d rather than the dav1d crate, deliberately and against the plan's literal wording: dav1d-sys is system-deps-only, so it would add a system library and a .pc file to every client package — in the milestone family whose excision checklist exists to delete exactly that. rav1d is the same decoder, same licence, statically linked. The cost is honest: no-asm builds on both decoders, and software throughput is still unmeasured. The colour test is the milestone's exit criterion, so it is built to fail. Three fixtures, and a mutation check: hardcoding the swscale default turns the red bar to [255,24,0], and swapping Cb/Cr turns red to blue — a silent error no metadata assertion could catch. Review then disproved the range half of it numerically: with eight saturated bars, decoding the full-range fixture with the wrong range gives max error ZERO, because a mismatch only pushes values outside [0,1] where the shader clamps. A mid-tone was added; the wrong range now costs 11, well past the tolerance. The exit criterion I set was satisfiable by a test that proved nothing. Two blocking defects, both emergent rather than local. Software AV1 on a 10-bit stream never reached its typed refusal: rav1d is built 8-bit-only and returns ENOPROTOOPT, which the send loop turned into a generic error, so the pump's typed downcast missed and every AU failed identically — a permanent freeze on precisely the shipping case, since AV1 is advertised only where hardware AV1 exists and hardware AV1 plus HDR is Main 10. The shape is now read from the sequence header before any byte reaches the decoder, exactly as the H.264 leg reads the active SPS. And the new Reconnecting phase was the first state that is not streaming, not connecting, and still holding a live stream — which opened all three guards that had made a second launch impossible. Pressing A assigned over `stream` where every other site shuts down first, and StreamState has no Drop, so the old pump was detached: a second live session still submitting to a Vulkan device that gets destroyed underneath it. Nothing about the reconnect was wrong in isolation; the defect lived between a new state and three guards nobody re-examined. Start is now defensive and the retry raises the connecting modal, so the UI matches the state and B can cancel. Also closed: retry_caps was computed, tested and never applied, so a shape refusal could end a session reporting no codec available while a working retry existed; the retry inherited force_software sticky-true, landing an HEVC→H.264 fallback on software H.264 with working hardware H.264; it re-dialled with a stale mode; the CPU present arm had no survivable-failure handling where the pyrowave arm — same pass — has it; HEVC is no longer advertised when the decoder is pinned to software; and the software rung now feeds the recovery-point SEI it already had in hand to the re-anchor gate. ⚠ Two host-side gaps found while tracing, neither in scope here: Hello::launch is NOT idempotent (gog:/custom: targets spawn a second copy on a retry; the field is kept verbatim because dropping it orphans the gamescope display whose reuse key includes the command), and a reconnected session can never adopt a game predating its own launch stamp, so it has no game-exit detection. ⚠ OWED: the on-glass software run. ~200 lines of new Vulkan on a path that only runs because the GPU already failed, and no driver has seen it. The review's minimum check is sync validation enabled, a non-multiple-of-16 mode, a mid-session resize and demotion, and both colour matrices. Gates: container clippy -D warnings over four crates, 236 tests, workspace check. pf-vkdecode and pf-bitstream are byte-for-byte untouched, so the hardware rungs' 250/250 stands.	2026-08-07 06:18:23 +02:00
enricobuehler	e6bcac8770	chore(license): name the copyright holder "unom - Enrico Bühler" ... "unom" alone is not the legal entity name. Updated the copyright line in all nine first-party license files -- the root MIT/Apache pair and the hand-maintained copies under clients/apple, clients/decky, packaging/windows/drivers and packaging/windows/pf-vkhdr-layer (there is no script that syncs these, so each is edited directly). The Linux and Windows clients' About screens pick this up automatically: both `include_str!` the root LICENSE-MIT / LICENSE-APACHE at compile time. Deliberately untouched: - Third-party license texts (Geist OFL, FFmpeg, VB-CABLE, the vendored pyrowave/Granite tree, KDE protocol XMLs, the os-icon licenses) -- those are other parties' copyrights. - Publisher/author/maintainer metadata, which is identity rather than license text and is reported separately for a decision.	2026-08-06 23:16:16 +02:00
enricobuehler	b0ec759fad	fix(brand): capitalize "Punktfunk" in user-facing text ... The docs site's page title read "punktfunk docs". Fixed that and swept the rest of the tree for the same defect, capitalizing the brand wherever it is shown to a human and leaving it lowercase where it is a technical identifier (CLI/package names, `punktfunk://` scheme, PnP enumerator, TLS SNI, logcat tag, config paths, CMS tenant id). User-visible fixes: - docs-site: page title -> "Punktfunk Docs"; API reference title, meta description and the branded bar's aria-label; the BrandMark/Wordmark SVG accessible names (the web console already had these capitalized -- the docs site had drifted from it). - Android: six strings of live UI copy -- the local-network permission dialog (x2), the connect-screen error banner, and the no-controller explainer. - Apple: the "No Hosts" empty-state text and the fallback display name for a host that advertises no instance name. - Windows client: the `--discover` progress line. - KWin fake-input: the application name passed to `authenticate()` (the grant is cached per-exe, so the string is display-only). - THIRD-PARTY-NOTICES: fixed in both generators (about.hbs and gen-third-party-notices.py) and applied to the three checked-in outputs so they match what a regeneration now produces. Every changed line differs from the original only by letter case, so line lengths are unchanged and no formatter width rule is affected. `cargo fmt --all --check` passes.	2026-08-06 23:10:25 +02:00
enricobuehler	c48e60fbb7	Merge pull request 'Two July fixes that were never merged: rpm FFmpeg modules + the released-pointer double cursor' (#71) from worktree-july-rpm-and-cursor into main ... Reviewed-on: #71	2026-08-06 13:13:33 +00:00
enricobuehler	2a67c02f7e	fix(clients/cursor): the host must not composite a pointer under a released client's own cursor ... Streaming a KDE desktop showed two cursors: the one the user was moving, and a second one sitting underneath it that never moved. It was not KDE's — KWin 6.7.3 in cursor-as-metadata mode calls `setRenderCursor(false)` on every recorded buffer and hands the cursor item to an exclusive `ItemTreeView`, so `shouldRenderItem()` skips it and no pointer is ever painted into that stream. It was ours. Both clients declared the render model as `captured && desktop`, so ANY released pointer handed compositing back to the host. But releasing does not remove the local cursor — it restores the ordinary window arrow over the video. The host then blends its own pointer in underneath, and since a released client forwards no motion, nothing drives it: it stays frozen wherever the host pointer was last left. Caught live on the host with the render-model diag: cursor diag: client_draws=false blended=true live=Some((-1, 622, true)) x = -1 — parked on the streamed output's left edge, unchanged sample after sample, while the user moved their own cursor around freely. Engaging capture flipped it to `client_draws=true blended=false` and the duplicate vanished, which is why it only looked "stuck when not dragging": dragging means engaged, and engaged was the one state that behaved. The host may composite ONLY while the client holds a grabbed, hidden pointer — the capture model, engaged — which is the single state with no local cursor on screen. Released now counts as "the client draws it": the host stops compositing and keeps forwarding shape/state over the channel (the forwarder ticks on this side of the flip), so re-engaging is seamless and the client's cached shape stays warm.	2026-08-06 15:03:11 +02:00
enricobuehler	6ae2ea6708	Merge remote-tracking branch 'origin/main' into worktree-library-clients	2026-08-06 14:45:36 +02:00
enricobuehler	00d4026054	Merge pull request 'Worktree field kleisty triage' (#69) from worktree-field-kleisty-triage into main ... Reviewed-on: #69	2026-08-06 12:41:28 +00:00
enricobuehler	883c317872	feat(clients/library): a launcher tile looks like one, on every client ... The host has been able to describe a launcher entry since M2 — `role: "launcher"`, the `steam_ui` and `launcher_ui` kinds — and the web console has grouped them into their own rail since M4. No other client ever looked. `pf-client-core` decoded `role` into an `is_launcher()` helper with zero call sites, and the shared console model dropped the field entirely on its way to the renderer. So a launcher tile arrived everywhere else as an ordinary game with no cover art: indistinguishable from a title whose poster failed to load, sorted into the middle of the alphabet, and captioned "Play". One contract, implemented in each client's own idiom: * launchers never interleave with titles — they lead, and each group keeps the host's title order * grid surfaces get a labelled section; a coverflow keeps its single carousel and names the group the cursor is in, changing as it crosses the boundary. A second focus rail would mean a new up/down nav model in three renderers for two or three tiles * an art-less launcher gets an accent face naming its launcher, not a title monogram on the neutral one — "opens Steam", not "a cover that didn't load" * anything that is not `"launcher"` is a game, and a host that omits the field renders exactly as before (design D4's intended degradation) * launching is unchanged: the client sends an id, the host resolves the recipe The grouping is enforced once per client stack rather than per screen. In the console UI it is an invariant of `LibraryShared::set_games`, so the cursor arithmetic, the art pump and every future consumer inherit it; on Apple and Android it is applied where the library is fetched/parsed. Fixed in passing: the Apple and Android store badges were hard-coded `isCustom ? "Custom" : "Steam"`, so every Lutris, GOG, Heroic, Epic and Xbox title was labelled "Steam". Both now carry the same store table the Rust clients use. The CLI's `--library` gains a fourth column (`game`/`launcher`), appended rather than folded into an existing one so anything reading the first three is untouched. Gates: punktfunk-host 436 passed / 0 failed and pf-console-ui 49 passed / 0 failed on .21 (three new tests), workspace clippy -D warnings and cargo fmt --check clean there; `swift build` of the full PunktfunkClient and `:app:compileDebugKotlin` clean on macOS; `cargo check` + `clippy -D warnings` for the Windows client on .173. Still unproven on hardware: no launcher tile has been clicked on a real host — that needs the plugins published, which needs this branch's base merged first.	2026-08-06 14:35:24 +02:00
enricobuehler	81b4f76c4d	fix(client): a session ending on purpose stops reading as a failure ... The desktop clients turned every host-side close into "Host ended the session", and a reason string means "abnormal" to everything downstream: the GTK and Windows shells raised a banner, the console overlay drew a status strip. Quitting a game you launched yourself produced all of that. Now only a host error or a lost connection carries a message; the deliberate endings return the silence those shells already give a clean exit, which is also what puts the console back in its library with nothing in the way. The Apple client gains the same distinction. It had one line for every ending — "Session ended by <host>." — which is fine for an operator stopping the session and wrong for a link that died, so each now says what happened. A game exiting stays silent and returns to the library it was launched from. Both read the reason while the connection is still up, because tearing it down is what makes it unreadable, and both fall back to their previous wording when there is no verdict — an older core, or a close that raced the read — rather than inventing a new one for a case they cannot see.	2026-08-06 14:30:46 +02:00
enricobuehler	d4dd5f7a3d	feat(client): a game exiting takes you back to its library ... Quit a game you launched from a host's library and the stream ended with "Session ended by <host>." on the host-selection screen — an error report for something you had just done on purpose, and several taps away from starting the next title. The host has always said what happened: it closes the connection with APP_EXITED when the game it launched for a session exits, and that code's own documentation describes this feature. Nothing ever read it — a search across every client found zero consumers. (It also could not reach anyone until the previous commit, since the close only happens once the lease declares the game gone.) The core now records the reason as it observes the close, latched before the shutdown flag because different threads watch the two, and exposes it as punktfunk_connection_game_exited. Purely additive: a client that never asks behaves exactly as before, the host sends identical bytes, and the wire version is untouched — ABI 17. The Apple client asks while the connection is still up, then treats a game exit as the normal finish it is: no error banner, and if the session began as a library launch it reopens that library so the next title is one tap away. Any other ending — a stop, the host going away, network loss — is unchanged. The other clients keep their existing end-of-session behaviour; the call is there when they want it.	2026-08-06 13:58:57 +02:00
enricobuehler	ea762b849d	fix(client/ios): Escape stays in the game instead of freeing the pointer ... Pressing Escape mid-stream on an iPad handed the mouse back to iPadOS: the captured cursor was swapped for the system one and the game stopped receiving relative motion, so aiming died until you clicked back in. Two previous attempts treated that release as unavoidable and built recovery around it — a re-lock burst, then a click that re-asks. Both came back from the field unchanged, because both fought the release after it had already happened, inside the cooldown the platform applies straight after its own "let me out" gesture. The release was never unavoidable. This app had no UIKit key handling at all: every key arrives on the GameController path, which is a parallel HID feed that does not consume the UIKit event, and the only thing that ever became first responder was the video view, and only to summon the soft keyboard. So every hardware Escape reached UIKit unclaimed — and an unclaimed key press is precisely what lets the system apply its own default for that key. Apps that read a hardware keyboard the ordinary way consume the event as a side effect and never see this. So claim it. The stream controller becomes first responder while capture is engaged and takes Escape in pressesBegan/pressesEnded, passing every other press to super untouched. Escape still reaches the host on the GameController path, so in-game menus open exactly as before; only the system's own interpretation is suppressed. Scoped to captured input, so Escape keeps dismissing sheets and leaving full screen whenever the stream doesn't own the keyboard, and the deliberate ways out are untouched — Cmd-Escape and Ctrl-Opt-Shift-Q are read off the same GameController path and clear capture themselves. The recovery path stays as a backstop and is retimed to match what was measured: the old burst spent its entire budget within ~0.6 s of the drop, i.e. wholly inside the cooldown, where the answer can only be no. Retries now continue at 1.2 s and 2.4 s, and quietly — they don't hide the cursor or mute pointer motion the way the burst does, so a longer recovery costs nothing when it fails.	2026-08-06 13:58:41 +02:00
enricobuehler	b25e6eda91	fix(clients): host discovery heals itself, and every client can rescan ... A field report from an iPad: the host is not found on first run, and restarting the client finds it. Pull-to-refresh appeared to do nothing. Both were real. The Apple client's discovery had three ways to go permanently deaf, each needing an app relaunch to clear: - A failed resolve was never retried. `browseResultsChangedHandler` only fires when the result SET changes, and a host whose resolve failed is still in the set — so nothing ever re-offered it. - A stuck resolve never ended. `NWConnection` has no timeout, so the throwaway UDP flow used to resolve an address could sit in `.preparing`/`.waiting` forever, and a service with a connection in flight was skipped. - `NWBrowser` parking in `.waiting` was ignored (only `.failed` re-armed). On iOS that is where the local-network privacy prompt lands on first launch after install: the browse starts, the system asks, and the browser waits. Granting does not revive that browser — only a new one sees the grant. That is the reported first-run bug. HostDiscovery now runs a 1 Hz sweep that times out stuck resolves, retries failed ones on a 1→30 s backoff, and re-arms a browser that stopped working; the advert's TXT is re-read on every browse report, so a host that re-keys or flips its pairing policy is followed. Returning to the foreground re-arms the browse (iOS/tvOS: `onAppear` does not fire across background/foreground, and a suspended browse stays dead). Pull-to-refresh did nothing because there was no `.refreshable` in the client at all. Added, plus the explicit control the report asked for: a toolbar Refresh on iOS/macOS, an action-row button on tvOS, a Rescan tile in the gamepad launcher, Scan Again on the empty state, a header-bar button in the GTK client, a hosts-page button on Windows, and Scan again on Android. Decky already had one. The desktop/Android browses needed a rescan trigger to make those buttons mean anything: mdns-sd re-queries on a doubling backoff capped at ONE HOUR, so a long-lived browse is effectively passive and a host that appears later can stay invisible. `discovery::Rescan` forces a fresh query; the wake-and-wait loops use it too, so a host that just booted is noticed in seconds rather than at the next backoff tick. Also fixed, found on the way: clients/windows/src/discovery.rs is a second copy of the browse that d0fa8bd3 ("pin mDNS discovery to IPv4 on every client") missed. It took an arbitrary first address, so when a host's OS responder answered AAAA the Windows GUI rendered a card that failed on every click. It also never noticed a dropped receiver, leaking a thread and a :5353 socket per wake-and-wait. Gates: Apple macOS + iOS (arm64-apple-ios17.0, proven non-vacuous) build clean, 195 tests pass incl. a new one asserting a rescan re-finds a still-advertising host. On .21: fmt, clippy --all-targets -D warnings and build clean for pf-client-core + client-linux + client-session, 117 tests pass. Android :kit: and :app: compileDebugKotlin clean. The Windows client is UNGATED — its CI runner was unreachable.	2026-08-06 13:30:10 +02:00
enricobuehler	92f617a989	Merge remote-tracking branch 'origin/main' into worktree-haptics-m12-dry ... # Conflicts: # clients/android/kit/src/main/kotlin/io/unom/punktfunk/kit/GamepadFeedback.kt # crates/pf-client-core/src/gamepad.rs	2026-08-04 23:11:22 +02:00
enricobuehler	2f071a9a93	Merge pull request 'fix(clients/settings): controller settings that can't do anything no longer look live' (#50) from worktree-haptics-m11-settings into main	2026-08-04 21:08:15 +00:00
enricobuehler	68353a5d57	Merge pull request 'fix(client/apple): two DualSenses stop fighting over one device, and a failed stop stops lying' (#32) from worktree-haptics-m4-apple into main	2026-08-04 21:01:51 +00:00
enricobuehler	42a0dd52be	refactor(haptics): one copy of each thing every rumble path was transcribing ... Twelve findings from the sweep's DRY/docs/dead-code tail. Most are small; three found real defects hiding behind the duplication. **The UHID event ABI existed five times.** Every UHID gamepad backend — DualSense, DualShock 4, Switch Pro, Steam Controller, Steam Controller 2 — carried its own verbatim copy of the kernel's constants plus its own `put_cstr`, and they had already drifted: `switch_pro` was missing the SET_REPORT pair entirely, and `steam_controller` read a FIXED 16-byte SET_REPORT window instead of the event's own `size`. That last one is a bug in both directions — a longer report was truncated, and a shorter one had the parser reading whatever the reused event buffer still held past the payload, i.e. acting on rumble values the game never wrote. Now one `uhid_abi` module owns the numbers plus the two accessors that are easy to get subtly wrong, with tests on exactly that. **A dead force-feedback id fallback.** ff-core's `input_ff_upload` picks a free effect slot and writes it into the effect BEFORE uinput forwards the request, so the `id == -1` branch could never run — and allocating from a local counter would have been the wrong answer anyway, since the kernel owns that id space. Removed, with a `debug_assert` where it stood. **Apple's HID path silently dropped weak rumble.** `hidByte` took the top byte with no non-zero floor, so every amplitude below 0x0100 rendered as exactly nothing. Android has always floored it at 1; this was the odd one out. That converter also existed twice byte-identically inside one Gradle module — now one `wireAmplitudeToByte`. Also: the DS5 output-report layout gets named offsets (`dualsense_proto::out_report`) documenting all three transport bases — USB 0, SDL payload −1, Bluetooth +2 — since the differing bases are transport-forced, not drift. `pf-client-core` cannot import them (it and `pf-inject` do not depend on each other, and a DualSense layout has no business in `punktfunk-core`, their only shared crate), so its copy now DERIVES its offsets by explicit subtraction and a test pins the relationship. `PUNKTFUNK_HID_EFFECT_MAX` sizes the struct it describes instead of a second literal 11 — the header now emits `uint8_t effect[PUNKTFUNK_HID_EFFECT_MAX]`. The rumble policy engine's `min_pulse_ms` and `keepalive_ms` docs stop naming cases nothing implements: no in-tree caller sets `min_pulse_ms`, and the macOS DualSense-over-BT keepalive the doc cited CANNOT be served by the quirk, because that renderer skips writes whose levels are unchanged and would swallow the engine's re-emit — it keeps its own keepalive instead. `TrackpadHaptic` is marked as staged scaffolding (the tag is on a shipped wire; removing the variant would not reclaim it). Three ×257-vs-`<<8` doc comments corrected — the scaling itself is fine, both round-trip to 255. `backstop_ms.max(160)` deleted as unreachable (the engine floors at 500). New tests for `Ds5Feedback` and for the Android rumble JNI packing on BOTH sides, with `MAX_PADS <= 16` now a compile-time assertion rather than a comment. Closes S1-S9, S11, T2, T3 (design/haptics-sweep-2026-08-03.md M12). S11's second half is NOT a defect and was left alone: `clients/session/src/main.rs` calls `set_forwarding` unconditionally on every params-build (its own comment explains why — browse mode reuses one service across launches), so `Ctl::Forwarding` routinely arrives unchanged and that early-out is what stops a redundant `sync_open` + Valve-HIDAPI cycle each launch. Verified: pf-inject clippy -D warnings 0 / 91 tests; pf-client-core + punktfunk-core clippy 0 / 437 tests (amd64 container); punktfunk-client-android 7 tests; Android :kit: 6 tests; Apple swift build + 189 tests / 0 failures; cargo fmt --all --check clean. Each new test probed by reverting its fix — the fixed SET_REPORT window fails 3, a broken pack shift fails 3, dropping the amplitude floor fails 1, and a wrong DS5 offset either fails the pin or refuses to compile.	2026-08-04 22:52:38 +02:00
enricobuehler	9fb41affba	fix(clients/settings): a controller setting you can't use no longer looks like one you can ... Turn "Forward controllers" off and four rows below it stop meaning anything — nothing is forwarded, so there is no pad type to pick and no guide button to route. GTK desensitised them, the touch settings on both mobile clients dimmed them and the console UI refused the step; the Windows client and BOTH controller-navigable screens left them fully live, so you could sit there changing settings that did nothing. Windows: `.enabled(s.gamepad_forwarding)` on the forwarded-controller picker, pad type, guide button and hold-Select rows — the same builder the echo-cancellation row already used to follow the mic switch. Apple's gamepad settings had no way to say it: `Row` carried `adjustable` (which only hides the chevrons) and nothing else. Added `Row.enabled`, dimmed the row CONTENTS only so the glass still reads as a focusable row, and enforced the inertness centrally in `adjust(id:)` / `activate(id:)` rather than in each builder's closure. The hint bar drops "Adjust"/"Change" on a dimmed row, because advertising them was the same lie the live row told. Android's gamepad settings already had `GpRow.enabled` — documented as "dimmed + inert" — but it only faded the label: every dimmed row still stepped and still wrote its setting. The "No profiles yet" placeholder looked inert only because its own closures were empty. Made it real in one named place (`liveRow`), covering all three input paths (left/right, A, and a tap on the already-focused row), then gated the pad rows on it. Also on that screen: the DualSense / DualShock passthrough toggle, which the touch settings have carried beside its SC2 twin all along. It was missing exactly where it matters most — a TV box has no touch interface to fall back to, so there was no way to reach it at all. Apple capture, separately: with forwarding off, opening a slot still claimed EVERY element's system gesture and powered the controller's IMU. Neither reaches the host, so the first only took the user's screenshot/Home gestures away for nothing and the second drained the pad's battery streaming gyro over Bluetooth. Narrowed rather than skipped — the escape chord is read off the same slot and on tvOS is the ONLY controller way out of a stream, so the chord's own four buttons keep their claim. A test pins the alias list against the chord mask; if they drift the symptom is a session nobody can leave, with nothing logged. Closes R17, R18, R19 (design/haptics-sweep-2026-08-03.md M11). R17 as filed named Windows and "Apple"; Apple's TOUCH settings were already correct and Android's controller-navigable screen was not — both corrected here. Verified: Windows clippy -D warnings exit 0 on a real Windows box; Apple swift build clean + full suite 192 tests / 0 failures (3 new); Android :app: + :kit: green (5 new); cargo fmt --all --check clean. Each fix probed by reverting it — every probe failed the tests it should.	2026-08-04 22:25:51 +02:00
enricobuehler	d7e22c3db2	Merge pull request 'fix(apple/shots): the store screenshots show the app as it actually is' (#48) from worktree-apple-store-screenshots into main ... Reviewed-on: #48	2026-08-04 20:02:37 +00:00
enricobuehler	1db7058a5d	feat(clients/input): system buttons route around local overlays ... Pressing guide/Steam/QAM collided with the client device's own shell: iOS 26 opens its Game Overlay for the Home press (no app opt-out until iOS 27 makes it a user setting), and a Gaming-Mode client opened BOTH Steam overlays for one press — the local one covering the stream. Two cross-client tier-P settings, zero wire changes: - system_buttons (auto|forward|local): raw guide+misc1 passthrough. Auto forwards everywhere EXCEPT under gamescope, where SteamOS reacts to the same physical press no matter what. - guide_gesture (auto|on|off): hold Select ALONE ~350ms sends the HOST's guide, down until release — held on, that's the host's long-press, which opens a Gaming-Mode host's QAM for regular pads. A Select tap is delivered on release with its up TAP_PRESS (50ms) behind, because per-transition sends fold into seq'd GamepadState snapshots and a back-to-back pair can coalesce into no press at all. A Select inside a combo (the escape chord) passes through untouched. Auto arms it only where the raw press can't reach the host cleanly: gamescope, iOS/iPadOS, tvOS. The same SelectGesture rules live in pf-client-core (pure state machine + unit tests), the Apple client (mask-diff adaptation in GamepadCapture), and Android's GamepadRouter. Settings rows on every surface (GTK, WinUI, console UI, Decky, Apple x2, Android x2) with profile plumbing throughout. punktfunk-session grows a control socket ($XDG_RUNTIME_DIR[/app/$FLATPAK_ID]/punktfunk-session-ctl.sock — the one runtime path a flatpak and the host see identically): 'guide'/'qam' verbs inject synthetic taps. The Decky panel gains a Host menus section (visible while the client runs) whose buttons press the host's Steam/QAM and close the local menu so the host's shows through. iOS 27's GCControllerHomeButtonSettingsManager deep-link is a TODO (the class needs the Xcode 27 SDK to compile). Docs: input, client-settings, steam-deck. Design: punktfunk-planning design/system-buttons-routing.md. Gates: docker clippy --all-targets --locked -D warnings + tests (pf-client-core 88 incl. 6 new gesture tests, pf-console-ui 47), cargo fmt --all --check, swift build (macOS), gradle kit+app compile, decky tsc --noEmit + py_compile. clients/windows not compiled (no box).	2026-08-04 21:46:27 +02:00
enricobuehler	8f35155c14	fix(apple/shots): the store screenshots show the app as it actually is ... Uploading the 0.24.0 set surfaced a pair screen that reads as broken, and a hero that was never the orientation it claimed. The capture harness: - Landscape scenes were captured in PORTRAIT. `IOSOrientationConfigurator` asked for the geometry update from `updateUIViewController`, where `view.window` is still nil — SwiftUI makes one update pass for a `.background` representable, before the hierarchy is in a window, so the guard fell through and nothing ever asked again. Both `.landscape` scenes (the stream hero, the trust card) shipped as portrait. Now a real UIViewController asks from `viewDidAppear` and pins `supportedInterfaceOrientations`. - The shot host applied `.ignoresSafeArea()` to the whole scene, so the hero's HUD — resolution, bitrate, the latency breakdown, the entire point of that screenshot — sat under the Dynamic Island. Only the black backing ignores it now; scenes that want full bleed already ignore it themselves. - `03-pair` was hand-composed into a ZStack rather than presented. PairSheet is a bottom sheet on iOS: its detents and the system's Liquid Glass only exist inside a real `.sheet`. Composed, the grouped Form stretched to full screen height and the capture was a strip of content over a black void, with a DISABLED "Pair & Connect" (empty PIN) and the capture simulator's own name — `pf-shot-iphone-6.9` — rendered in as the device name. - Sheets do not inherit `.environment(\.colorScheme, .dark)` across the presentation boundary; they follow the DEVICE. The pairing sheet came out light grey over the dark app. The simulator is now set to dark appearance. - Discovery browsed the live LAN mid-capture, so a bystanding machine's hostname went out on the listing and no two runs matched. `HostDiscovery` gains a `debugSet` seam (the counterpart to `HostWaker.debugSet`); the mock hosts advertise, so cards read ONLINE through the real `advertises` path and the reachability probe never touches the network. - Created simulators were named `pf-shot-<prefix>`, which the reuse regex never matches: every run created another simulator and none was reused. They are named after the device now — reusable, and not user-visible junk. Two bugs found on the way, neither screenshot-only: - HostStore/ProfileStore PERSISTED the harness's mock data. On a dev Mac that is the same App-Group suite the real app reads, so running the script could replace the tester's saved hosts with "Battlestation" & co. - GamepadHomeView drew the controller chip as a trailing `.overlay`, which reserves no width — on a portrait phone it sat on top of the centred "Select a Host". Laid out as a row with a hidden leading mirror. - The pairing sheet's field prompt said "How the host lists this Mac" on iPhone and iPad. Coverage: the listing set is six scenes in listing order, and is now the stream, the machines it found, the couch/controller mode, waking a sleeping host, the quality controls and pairing — the console and wake screens already existed in `ShotScenes.all` and were simply never captured. Mock hosts carry OS marks, Wake-on-LAN MACs and profile chips so the grid is full rather than three offline rows over an empty half-screen. `SCENES=` overrides the set for the dev scenes.	2026-08-04 21:30:18 +02:00
enricobuehler	7331be0a40	Merge pull request 'fix(audio): the quality root cause, the latency ratchet, and making the plane observable' (#33) from worktree-audio-quality-latency into main ... Reviewed-on: #33	2026-08-04 16:51:34 +00:00
enricobuehler	6f54fcdd2d	fix(client/ios): a click wins the pointer back after Escape drops it ... Pressing Escape mid-stream on an iPad leaves the capture in a state it could never leave: iPadOS releases the pointer lock by itself, a bare Escape deliberately never clears `captured` (it is a game key), and the re-lock burst added with the Escape-drop fix is the only thing that ever asks for the lock back. That burst fires in the 0.6 s immediately after the platform's own "let me out" gesture — precisely when it is least likely to be granted — and once its budget is spent nothing re-asks: `setCaptured` is the only other requester, and `captured` never went false. The capture then spends the rest of its life on the absolute pointer path, which is why the field report reads the way it does — clicks still land exactly where you aim, because absolute positions keep forwarding, but the game receives no relative deltas and camera look is dead for the rest of the session. Make the click the second stage of the recovery. A click into the video while captured-but-unlocked now re-anchors the lock chain and re-asks, which is the request the platform actually wants: a genuine user gesture rather than an app grabbing the pointer straight back. Asked on the button UP, so the click has fully forwarded on one transport first — asking on the DOWN can flip `gcMouseForwarding` mid-click and strand the release on the GCMouse path. Gated on `pointerLockWasEngaged`, exactly as the drop path is, so a scene that never qualifies (Stage Manager, Split View) is never bursted at, and on no burst already being in flight, since a pending burst mutes absolute motion and re-arming one per click would freeze the cursor between clicks of a menu the user is still aiming around. Worst case is now today's behaviour rather than a permanent one: a refused burst settles, and the next click tries again. Typechecked for arm64-apple-ios17.0 (PunktfunkKit builds clean). NOT yet verified on glass — the premise that a click-driven re-request is honoured is exactly what the previous fix got wrong.	2026-08-04 18:07:07 +02:00
enricobuehlerandClaude Opus 5	2cfc82e96c	fix(audio): budget the audio plane against the link, and close the review's gaps ... Findings from the post-implementation review of design/audio-quality-and-latency.md. **The bandwidth gap (highest).** Tier `High` (256 kbps) and the redundant `0xD2` plane were added separately, each costed as "~1 % of the video budget", and nobody added them together: 256 kbps sent twice is 512 kbps — ~2.5 % of a 20 Mbps session but ~10 % of a 5 Mbps one. Audio rides QUIC datagrams, OUTSIDE the ABR loop, so ABR could neither see that nor reclaim it; a constrained link quietly handed a tenth of its bandwidth to audio while ABR carefully managed the rest. `plan_audio_budget` now makes tier and redundancy ONE decision against the session's resolved video bitrate, ordered by preference rather than cost — transparent audio beats redundant audio, since the field report was about quality and redundancy only pays under loss, so `High` alone outranks `Standard`+redundancy even though they cost the same. It can lower what the operator asked for, never raise it, and never goes below `Low`: a stream with unintelligible audio is worse than one spending a few percent more. **The Linux host kept the exact defect fixed on Windows.** `let _ = tx.try_send(samples)` — silent, uncounted data loss, where the encoder concatenates across the hole, so every drop is a click AND a permanent shift of everything after it. WP0.2 turned out to be Windows-only and had not said so. Linux now shares `capture_policy::CaptureStats`: drops counted and warned, plus per-window peak/RMS/delivered%. A Linux audio report was until now exactly as un-triageable as the Windows one was on 2026-08-03. **Apple's WP0.3 was half-done** — `bufferedMS` was added and wired to nothing. The drain thread now logs buffer/target/underruns/sheds like the other three, from one locked snapshot so the numbers in a line describe the same instant. Also: the Linux "audio format negotiated" line now says WHICH mode produced it, because that changes what it is worth — in stream-sink mode the host owns the sink so the mix cannot have been narrowed upstream, but in legacy monitor mode a 16 kHz Bluetooth sink would still be reported as a clean 48 kHz through PipeWire's resampler, the same way WASAPI's autoconvert hid it on Windows. Reading the monitored node's own rate needs a registry lookup this stream does not do; recorded as an open gap rather than implied to be covered. Two stale docs: `audio_wasapi.rs` cited `clients/windows/src/audio.rs` (deleted) and still described the pre-shared-policy "prime to ~3 quanta" behaviour. And the Apple ring's `prefill:` parameter, dead since the depth moved into the ring, is gone. Verified: clippy --all-targets -D warnings on Linux (docker) AND Windows (runner .133, forced clean rebuild of punktfunk-host + pf-client-core); core 167 tests; host 57 audio tests on Windows; Android clippy count identical to pristine (6, all documented arm64 artifacts); Apple ring re-simulated. The host suite's `gamestream::stream::tests::sender_delivers_batches` fails under qemu — the recorded environmental flake, unrelated to audio, green on the earlier less-loaded run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 17:58:17 +02:00