2639 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehler	0ee690f8bc	fix(client/hevc): the DPB we demanded was the level's ceiling, not the stream's need ... A punktfunk client streaming HEVC from .21 (RTX 5070 Ti) refused every access unit with "stream needs 17 DPB slots, device caps at 16", flushed, waited for an IRAP, got a fresh IDR that needed 17 too, exhausted the decode ladder and reconnected with HEVC excluded. On a build with no software HEVC decoder — there is no permissively licensed one — that is not a slower path, it is losing the codec. The host was blameless. Reading the SPS it actually emitted: general_level_idc 153 (L5.1 High, which NVENC autoselects at hevcConfig.level = 0 because a 130 Mbps target does not fit L5.0's 100 Mbps ceiling) and sps_max_dec_pic_buffering_minus1 = 5 — six pictures, RFI_DPB references plus the current one. Six, at every resolution. That is already the minimum the encoder can honestly declare, and the only host-side lever, the level, cannot be lowered without signalling a bitrate the stream exceeds. There was nothing to fix there. dpb_limit was reading equation A-2 instead. A-2 is a CEILING on what an SPS may signal — 7.4.3.2.1 constrains sps_max_dec_pic_buffering_minus1 to 0..=MaxDpbSize-1 — not a statement of what a stream needs, and it branches on picture size against the LEVEL's MaxLumaPs. At 1080p the coded 1920x1088 = 2 088 960 luma samples fall under MaxLumaPs(L5.1) >> 2 = 2 228 224, taking the first branch for min(4 * MaxDpbPicBuf, 16) = 16. max(A-2, buffering) then reported 16 where the stream had asked for 6, the backends added one slot for the picture in flight, and 17 is one more than NVIDIA's maxDpbSlots. A resolution sweep on the box drew A-2's branch table exactly, and it is the two commonest streaming resolutions that lost the codec: 720p 1280x720 = 921 600 branch 1 -> 16 frames, 17 slots 82 refusals, HEVC dropped 1080p 1920x1088 = 2 088 960 branch 1 -> 16 frames, 17 slots 41 refusals, HEVC dropped 1440p 2560x1440 = 3 686 400 branch 2 -> 12 frames, 13 slots clean 4K 3840x2176 = 8 355 840 else -> 6 frames, 7 slots clean, decode 1.9 ms One host, one level, one six-picture requirement. Only which branch the picture size landed in decided whether HEVC worked. That is also why this hid for so long: 4K was the resolution it was exercised at, and 4K is the one size that falls through to the honest answer. H.264 escaped for an unrelated reason — its own level-derived ceiling happened to land at 13 for 1080p L5.0 and 5 for 4K L5.2 — but it is the same shape of derivation and would fail the same way if NVENC ever picked a higher level for a smaller picture. So dpb_limit now returns the stream's own sps_max_dec_pic_buffering_minus1 + 1, capped at 16. That is not a workaround, it is what the number means: it is exactly the bound C.5.2.2's fullness clause bumps against, and A.4.1 bounds the total RPS entries by the same value, so `buffering` pictures hold `buffering - 1` references plus the current one with nothing left over. The max() that produced the 16 was written to be generous to malformed streams — "storing their pictures beats erroring the AU" — but it never did that either. Dpb::needs_bumping (C.5.2.2) already keys on the signalled buffering, not on max_num_pics, so a stream referencing more pictures than it declared was ALREADY being bumped below its own declared depth before every store. The widened limit bought no tolerance at all; all it ever did was over-allocate hardware surfaces, by ten pictures per session at 1080p, and on NVIDIA take HEVC away entirely. The fix moves 720p and 1080p onto the pool shape 4K has been running in the field all along (7 slots, 6 references), so it is not a new operating point — it is the one already proven. max_active_references drops from 15 to 6, still above the 5 an RFI_DPB stream can name. The per-AU level gate in pf-vkdecode reads plan.picture.level_idc directly, so dropping A-2 out of NegotiationInfo costs no sensitivity to a mid-stream level change. Two regression tests pin the arithmetic from both ends, because either end drifting back reproduces this: - h265: the field SPS synthesized byte for byte on the fields that matter must plan 6 frames / 7 slots, all four resolutions must agree because the stream does, and every depth the envelope gate admits must leave room for the picture in flight. The one honest residue is pinned too and deliberately left refusing: A.4 does let a conforming stream declare a full 16-picture DPB, and 17 slots genuinely do not fit 16, so that stream is still refused rather than decoded with too few slots and silently corrupted references. - pf-encode: RFI_DPB + 2 <= 16, guarding the producer end. RFI is a real latency win and this does not cap it at today's value — there are nine slots of headroom — it just stops it being raised past the point where clients can no longer decode us at all.	2026-08-07 17:34:17 +02:00
enricobuehler	7f822d9c41	Merge pull request 'Apple mic uplink: the microphone was never in the audio graph, so nothing ever pulled it' (#94) from fix/apple-mic-uplink into main ... Reviewed-on: #94	2026-08-07 14:33:44 +00:00
enricobuehler	9db2c06140	Merge pull request 'Gamepad UI (iOS): the field pass — a linear drum, no close chrome, a heading that leads, and strips that assemble themselves' (#93) from worktree-gamepad-ios-polish-2 into main ... Reviewed-on: #93	2026-08-07 14:33:18 +00:00
enricobuehler	d2d5058d0b	fix(client/apple): the mic was never in the graph, so nothing ever pulled it ... ROOT CAUSE, from the reporter's device log: 16:25:49.093 mic capture: 48000 Hz, 1 ch <- tap installed, format fine 16:25:49.235 audio engines joined - voice processing active ... 13 s of session, no errors, and the 10 s silence verdict NEVER fires The engine started clean and the tap was installed against a valid format - so neither the format timing nor the encoder was the fault. The tripwire fires after ten seconds of CAPTURED frames and never fired across a 13-second session: the tap received nothing at all. Because the capture side must be pulled, and only the render graph pulls anything. On the combined engine the input node carried a tap and no connection, so it was not in the graph and nobody drove it: the IO unit came up (the recording indicator lit for a beat, then went out as the input went idle) and not one buffer ever reached the tap. No error, no failed start - a session that quietly sent no microphone. The input now runs through a silent sink into the main mixer, which is what Apple's own voice-processing sample does. outputVolume = 0 because the mic must reach the graph and never the speaker. The split path never needed this - a capture-only engine has the input node AS its graph - so this broke exactly when the combined topology became the default. Verified: swift build (macOS), swift build --triple arm64-apple-ios17.0, swift test 208 passed. Awaiting the reporter's on-device confirmation.	2026-08-07 16:30:29 +02:00
enricobuehler	428377eaa1	Merge pull request 'Intel Arc never used Vulkan Video because our pNext order fed the decode caps to the wrong struct' (#92) from worktree-probe-codec-names into main ... Reviewed-on: #92	2026-08-07 14:13:14 +00:00
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	adf92939ec	fix(client/apple): the stats card's corner stops eating its own text ... Making the HUD concentric with the physical display corner had no upper bound, so a modern phone (~62 pt of display radius) asked for a 48 pt corner on a card whose lines sit 10 pt from the edge. A corner of radius r pulls the edge inward by r - sqrt(r^2 - (r-y)^2) at distance y below the top: at the first line that is ~19 pt, so the top and bottom lines rendered INSIDE the arc. Concentricity is only a virtue while the radius is small next to the card. The radius is now capped at 28 (devices asking for less still get a truly concentric corner) and the iOS content padding scales with it at 0.45*r, which leaves ~4.6 pt of arc against 12.6 pt of padding at the cap. The card grows by under 3 pt a side; the compact pill is unchanged.	2026-08-07 15:49:37 +02:00
enricobuehler	b166c53cc2	fix(vkdecode): a refused device says what the refusal costs, and about which format ... Three things the Intel Arc measurement showed were wrong or unhelpful in the refusal path. The message named NV12 whatever the stream was. A Main 10 session refused over P010 was told about NV12, which sends the reader to look up the wrong format's support. Both variants now carry the format the driver's own entry reported. A missing SAMPLED now says what it costs. "does not advertise usage SAMPLED" is accurate and tells a field reporter nothing: the consequence is that no shader can read this device's decoded pictures, so the zero-copy path cannot exist on it at all — which is a different conversation from a device that is merely slower. The line points at --probe-decode for the driver's own words. And the probe's second opinion no longer claims to be one. Measured on both vendors, vkGetPhysicalDeviceImageFormatProperties2 answers "creatable" for combinations the video-format query rejects — on NVIDIA too, for SAMPLED alone, which is not a legal video image usage at all. So it does not honour the chained profile list and must not be read as permission; it is still printed, because otherwise everyone who reads a refusal asks the question again, but it is labelled as not authority. Also names the three video ENCODE usage bits, which NVIDIA advertises on decode pictures and the probe was printing as "unrecognised 0xC000".	2026-08-07 15:44:07 +02:00
enricobuehler	9582da07b4	fix(client/apple): the entrance goes underneath the scroll transition ... Structural, because tuning the transform values was treating a symptom. A scroll transition derives its phase from the geometry of the view it wraps, and the entrance was wrapping each card on the OUTSIDE - so it moved the very thing the transition measures. Every card read as far from centre for the whole travel, phase pinned at fully receded, and the centred card only collapsed into its focused look as the entrance ended. That collapse was the jump; shrinking the offset last round only made it smaller. The card builder now hands each caller its own CardEntrance and both the launcher and the coverflow apply it BENEATH their .scrollTransition. The transition measures a card that never moves and composes its scale and rotation on top of the entrance's, so the two can no longer fight - and the fuller travel is back (34 pt rise) now that the geometry constraint that forced it down to 16 is gone.	2026-08-07 15:38:38 +02:00
enricobuehler	48339326ae	fix(client/apple): the entrance keeps every card inside its own footprint ... The focused card jumping into its correct state at the end of the entrance was the entrance's own geometry. The caller's .scrollTransition reads the geometry of the view underneath the entrance's transforms, so a card shoved 58 pt down and hinged on its leading edge spent the whole travel reported as far from centre - phase pinned at fully receded - and only collapsed to identity as the card came home. That collapse IS the jump, and it explains why it looked timing-dependent rather than simply broken. Now the rotation is about the card's centre (it turns in place instead of swinging sideways out of position) and the rise is 16 pt, inside the strip's own vertical slack, so nothing the entrance does moves a card away from where the scroll view thinks it is. The entrance also waits a couple of frames for real layout - the GeometryReader's first pass can report no width, so there is nothing to centre on yet - and the transaction override from the previous round is gone: it was not the cause, and nil-ing inherited animation could have made navigation snappier than intended.	2026-08-07 15:34:56 +02:00
enricobuehler	c06ee55b61	diag(vkdecode): --probe-decode reports what the driver says about video images ... The Intel Arc refusal moved one step down the caps query and stopped again: the coincide NV12 entry does not advertise SAMPLED. That sentence is punktfunk's, not the driver's, and the last two times a conclusion was drawn from a sentence of ours the conclusion was wrong. So --probe-decode now prints the driver's own answers instead. For every profile the client can negotiate (H.264 High, H.265 Main and Main 10, AV1 Main 8- and 10-bit) it asks vkGetPhysicalDeviceVideoFormatPropertiesKHR in six usage combinations — the three the image pools really create with, plus DPB|DST without sampling, SAMPLED alone and DST alone, which are what localise a refusal to a half. Each answer is printed as the driver gave it: format, usage and create flags named AND in hex with unrecognised bits called out, image type, tiling. A failed query prints its VkResult rather than vanishing into an empty list. It goes through pf-vkdecode's own query rather than a copy of it, which meant splitting query_formats into a physical-device form — the call never needed the VkDevice the old signature demanded. VideoFormat gains imageType and imageTiling to carry the whole record; VUID-VkImageCreateInfo-pNext-06811 compares both for equality, so they were being assumed rather than read. And because a driver that under-reports usage would be indistinguishable from one that genuinely lacks it, the probe asks a second, independent question — vkGetPhysicalDeviceImageFormatProperties2 over the same profile list — and prints it only where the two disagree. A disagreement is the finding. No behaviour change to any decode path: derivation reads the same fields it did.	2026-08-07 15:34:12 +02:00
enricobuehler	eaa87ca0cc	fix(client/apple): the entrance stops dragging the scroll transition along with it ... The strip entrance is one animated progress value now, not a Bool behind per-card .animation modifiers. Those modifiers wrap the caller's card - INCLUDING its .scrollTransition - so a delayed spring flipping while the scroll view was still settling captured the transition's own per-frame phase updates and stranded the centred card half-receded until the next scroll re-drove it. That was the 'only navigating fixes it' report, and the race with load speed was the same thing. CardEntrance is now a ViewModifier + Animatable: it slices its own window out of one master clock the carousel animates 0 -> 1, so every transform is a pure function of an interpolated Double and no animation modifier wraps a card at all. Benign failure mode too - progress reaching 1 without animating leaves each card at exact identity rather than stranded. The entrance also moved inside .frame(width:) so a scroll target's geometry never depends on what its card is doing, and the non-tvOS branch states its .id explicitly. One leak remained after that: withAnimation sets its animation on the whole TRANSACTION, so the scroll view's initial centring still inherited the 1 s linear clock and the focused card only reached its correct look as that clock ran out - arriving as a jump. The card subtree now clears the inherited animation, so its phase lands per frame while the entrance's own transforms (driven by animatableData, not by the transaction) keep running.	2026-08-07 15:28:09 +02:00
enricobuehler	769a8c049d	fix(client/apple): the entrance waits for the art, and every card swings ... Three defects behind an entrance that read as a card sliding up: - The centred card never rotated. The stagger fans out from an anchor, and the anchor was given side 0 = no rotation - but the anchor IS the card the eye is on, so the single most visible card only rose. Side is never 0 now; every card turns. - The swing happened while the card was invisible. Opacity shared the transform's spring, so the card spent its whole rotation at near-zero alpha and only the last few degrees showed. The fade now runs on its own 0.22 s curve (a second .animation governs only the modifiers above it) while the transform springs over ~0.6 s. The travel is deeper too - 0.74 scale, 64 degrees, 58 pt - and the rotation sign now matches the coverflow's own recede, so a card unwinds INTO its resting angle instead of swinging against it. - It fired before the art existed. Cards swung in as grey placeholders and filled with artwork afterwards. PosterImage reports when a cover settles (art loaded, or candidates exhausted), the coverflow counts the first few, and GamepadCarousel holds its entrance on a contentReady gate - with a 700 ms backstop so a slow or artless library still animates.	2026-08-07 15:16:49 +02:00
enricobuehler	2fb80073e6	fix(client/apple): the library actually plays its entrance, and it swings in 3D ... The strip entrance never ran in the library, for two reasons: - The trigger was lost. Flipping the state inside onAppear puts the change in the SAME transaction as the view's insertion, where SwiftUI runs with animations disabled. The launcher got away with it; the library's strip mounts late - only once the fetch lands - and lost every time. The flip now defers one runloop turn, so it is an ordinary animated state change. - The art snapped in behind it. Covers hard-swapped from grey placeholder to image, so even a working entrance was followed by a run of cards popping to artwork after the strip had settled. PosterImage cross-fades now (the touch grid inherits it). And the entrance is 3D: a card starts turned away on the drum, small, low and invisible, then swings flat, grows and rises on an overshooting spring. Cards left of the anchor hinge on their trailing edge and cards right of it on their leading one, so the strip FANS OPEN from the cursor instead of sweeping past it - the same hinge-and-perspective language the coverflow's own recede speaks, so arriving and scrolling read as one object. Reduce Motion still drops every bit of travel.	2026-08-07 15:10:33 +02:00
enricobuehler	ca667cb79a	fix(vkdecode): the pNext order decided which struct got the decode caps ... Intel Arc never used Vulkan Video decode on Windows. The rung refused every session with "driver advertises neither DPB_AND_OUTPUT_COINCIDE nor DISTINCT" and fell back to D3D11VA — and that refusal was ours. vkGetPhysicalDeviceVideoCapabilitiesKHR was called with the codec capability struct chained BEFORE VkVideoDecodeCapabilitiesKHR (push_next prepends, so the chain was caps -> h265_caps -> decode_caps). On Arc/Windows 101.8724 the driver fills those two by POSITION, not by sType, and returned them SWAPPED. Measured, on glass, both ways: before: decode_flags_raw=12 max_level_idc=1 after: decode_flags_raw=1 max_level_idc=12 12 is STD_VIDEO_H265_LEVEL_IDC_6_2 and 1 is DPB_AND_OUTPUT_COINCIDE. We were reading an H.265 level as a decode-capability bitmask; 12 contains neither 0x1 nor 0x2, so the check concluded the device had no DPB mode. It had one all along. The base struct was fully populated throughout — 15 DPB slots, 8192x8192 max extent — which is what gave the lie away: a driver that answers in that much detail is not declining. NVIDIA and RADV dispatch by sType and do not care about the order, which is exactly why the fleet stayed green and this reached the field. Both orders are spec-legal for us to write; only one survives a driver that assumes the conventional one, and the conventional one — decode caps first, as every Vulkan sample writes it — is now what all three codecs use. ⚠ This does NOT yet give the Arc Vulkan Video. It moves the refusal one step down the same function: the device advertises only COINCIDE (no DISTINCT), and its NV12 coincide entry does not advertise SAMPLED usage, which the zero-copy presenter path needs. Whether that is a second bug of ours or a real Intel constraint is not yet established, and this commit does not claim it either way. Found because the user disbelieved my "Intel driver bug" conclusion. He was right: I had reasoned from our own error message, which is the same circularity the caps logging added in fb1a0a61/a183cac8 now exists to break. Gates: fmt clean; clippy -D warnings; 187 pf-vkdecode tests. The GPU parity legs that cover this code cannot run here (no GPU on the build host) — the evidence is the on-glass A/B above.	2026-08-07 15:07:48 +02:00
enricobuehler	cf68d33e2c	feat(client/apple): the strips assemble themselves, and the store chip stops flashing ... Two more from the on-glass pass: - The coverflow's store/source chip only showed its background on the centred cover. Same mechanism as the tray blur: a card rides a scrollTransition that composites it with opacity < 1 and a 3D rotation, and a material cannot sample a backdrop through an offscreen composite - so the frost stayed blank everywhere except the one card sitting at exactly full opacity. The coverflow's chip is a flat wash now (StoreBadge gains `solid`), which has no backdrop to sample and is therefore simply always there. The touch grid keeps its material - its cards carry no transform, so its frost samples fine. - Host cards and library covers now arrive with the strip instead of being there: each card rises out of a fade on a lightly overshooting spring, delayed by its distance from the cursor, so the strip assembles outward from where the eye already is. Implemented once in GamepadCarousel, so the launcher and the coverflow inherit it together. Transforms only - snapping, the callers' own scrollTransition and the tvOS focus engine are untouched - and Reduce Motion drops the travel for a plain unstaggered cross-fade.	2026-08-07 15:03:54 +02:00
enricobuehler	a183cac8aa	diag(vkdecode): log maxLevelIdc beside the decode flags ... The Arc returned decode_flags=0b1100 = 12 with a fully populated base struct (15 DPB slots, 8192x8192 max extent). Neither COINCIDE (0x1) nor DISTINCT (0x2) is set, and 0x4|0x8 are not defined for that field at all — but 12 IS STD_VIDEO_H265_LEVEL_IDC_6_2, and VkVideoDecodeCapabilitiesKHR and VkVideoDecodeH265CapabilitiesKHR have identical layouts (sType, pNext, one u32). So the suspicion is that we are reading H.265's maxLevelIdc where the decode flags belong. Logging both settles it: if max_level_idc comes back as 1 or 2 the two structs are crossed, and the refusal is ours rather than the driver's.	2026-08-07 14:55:27 +02:00
enricobuehler	fb1a0a61e9	diag(vkdecode): log the driver's video capabilities verbatim ... Nothing in the caps module logged anything, so when a device refused with "advertises neither DPB_AND_OUTPUT_COINCIDE nor DISTINCT" there was no way to separate two very different situations that present identically as a zero: the driver filling the chain and genuinely declaring no DPB mode, versus our own pNext chain never reaching VkVideoDecodeCapabilitiesKHR at all. Printing the BASE VkVideoCapabilitiesKHR beside the decode flags is the discriminator. A populated max_dpb_slots next to decode_flags: 0 means the driver traversed the chain and answered; zeros across both mean the query never landed and the refusal is ours, not the driver's. Raised by the Intel Arc result on .221, where I concluded "driver bug" on the strength of our own code's report — which is precisely the circular reasoning this line exists to break.	2026-08-07 14:50:08 +02:00
enricobuehler	70de58f446	fix(client/apple): the tray blur goes full-bleed by layout, and its frost sinks to black ... Round-3 field findings: the pop-in had retreated to the X axis alone - the one growth still left to safe-area resolution (the landscape side insets), which settles a beat after insertion, outside any geometry group and outside the view's own transaction. The scrim now reaches full-bleed purely by layout: a fixed 80 pt negative-padding overhang on the outer edge and both sides replaces ignoresSafeArea entirely, so every axis is deterministic from the first frame (and orientation no longer changes the gradient's proportions). The mask's strong region moves to 0.65 to account for the overhang leading the gradient. And the frost reads black now, not grey: an ink.shade(0.35) wash inside the mask sinks the material's luminance lift toward the palette's shade - black on a dark field, palette-honest on a pale one.	2026-08-07 14:50:01 +02:00
enricobuehler	f674a06a08	fix(client/apple): the tray blur keeps its shape, and the tab pill turns to glass ... Two follow-ups from the second on-glass pass: - The tray blur's pop-in survived the geometryGroup: the full-bleed growth (negative padding + safe-area expansion) rode the push's transaction, and safe-area resolution sits outside a geometry group. The scrim now pins its own geometry out of any animation - the layer fade/slide still carries it, only its SHAPE can never animate. The bottom overshoot grows 32 -> 72 pt (the tray sits over scrolling rows plus the detail line; the blur influence starts well above the legend now) and the mask holds strength longer before dissolving. - The selected tab pill is a Liquid Glass surface (accent-tinted through consoleGlass, material fallback pre-26/tvOS) - the strip wears the same material language as the rows below it. The matched-geometry travel between pills is unchanged.	2026-08-07 14:45:15 +02:00
enricobuehler	49fa344c92	fix(client/apple): the gamepad UI answers its first field test ... Six findings from the on-device pass over #91, all iOS-facing: - The tray blurs no longer grow into place on a push: the screen layer resolves its internal layout (safe-area trays, the scrims' full-bleed) in a geometryGroup BEFORE the insertion animates. - The option band is LINEAR now, not a ring. A ring showed the first option waiting to the right of the last one - unreachable, since left/right clamps - and on a 2-option ring the unselected item flipped sides with every step (the 60/120 Hz row). Positions are fixed, the ends are the ends, and A's wrap travels back across the list. Options other than the facing one exist only while the drum is moving, so a long label never sits under a resting neighbour as overlapping text. - Toggles (and the pin rows) ride the band too: Off left of On, matching the left-off/right-on step semantics. - The close X is gone from settings, add-host and the library - a gamepad UI exits with B. A chromeless cancel button keeps hardware Esc and the macOS sheet working, and the library's loading/error/empty states gain a zero-size B listener so a controller-only user is never trapped where the coverflow (and its B) doesn't exist yet. - The heading is a real heading: leading-aligned with the 24 pt content inset, 24/34 pt (was 20/30), top margin 18/28 (was 10/18) - launcher, settings, add-host and library alike. The launcher's hidden-mirror chip trick died with the centred title that needed it. Verified: swift build (macOS), swift build --triple arm64-apple-ios17.0, swift test 208 passed / 0 failed.	2026-08-07 14:35:47 +02:00
enricobuehler	c34e1412fb	fix(client): a decoder pin with a stray space was silently ignored ... Found on glass, and it cost a whole session to find. PUNKTFUNK_DECODER was read untrimmed, so "native-vulkan " — ONE trailing space — matched no arm of native_vulkan_gate, fell through to `auto`, and on an Intel box `auto` takes d3d11va first. The operator's pin never ran and NOTHING said so. Read against a log, that is indistinguishable from the rung being refused for a hardware reason, which is precisely the ambiguity the rest of this module's logging was just rewritten to remove. The space is not exotic. A Windows .cmd produces it for free: `echo x>> file` keeps the space before the redirect, so every line written that way carries one. PUNKTFUNK_VK_ADAPTER already trimmed; this did not, and the inconsistency is what made it invisible — the GPU override obeyed while the decoder override did not. The rule now lives in one pure function, resolve_decoder_pref, called by BOTH readers. decode_pinned_to_software had the identical untrimmed expression, and its own doc comment says a second reading of the same two inputs is a second place for them to drift — fixing one and not the other would have proved it right. Whitespace-only counts as ABSENT rather than as a pin to "", because an exported-but-empty variable means "no override" and "" is a value the gate happens to accept. Tested as a pure rule (no process environment), including the end-to-end leg that matters: the trimmed pin reaches native_vulkan_gate and is admitted. Like the create-array tests in dee97e89 its before-state is a compile error rather than a failing assertion, because the function is new — what it guards going forward is real, and an editor who drops the trim fails it. Gates: fmt clean; clippy -D warnings over pf-client-core, punktfunk-client-session and pf-presenter in the Linux container; 164 pf-client-core tests.	2026-08-07 14:34:59 +02:00
enricobuehler	6c4df043fe	Merge pull request 'Gamepad UI (iOS): palette-washed glass, room to breathe, in-place screens, and a real option drum' (#91) from worktree-gamepad-ios-polish into main ... Reviewed-on: #91	2026-08-07 12:07:54 +00:00
enricobuehler	c010139e6e	feat(client/apple): the gamepad UI moves and colours like the console it mirrors ... Four reworks from the first palette-era on-glass review, all iOS-facing: - Surfaces carry the palette now, not just the text on them: ConsoleGlass washes every tier (Liquid Glass tint, pre-26 material, tvOS material) with ink.glass — the same colour the desktop console fills its panels with — and the close buttons move to an ink-aware consoleGlassBackground. The pre-26 branch also gains the focus tint it had silently dropped. Stray literals follow: ConnectOverlay text rides ink in the console takeover, card shadows soften on pale fields, the focused keycap reads onAccent. The online pip stays status-green on purpose. - The header breathes: title top padding 4/10 -> 10/18 plus shared header-spacing and title-bottom helpers mapped from the console shell's rhythm, applied to the launcher, settings and add-host alike, with the add-host close X re-anchored to the title row. - Settings, Add Host and the Library present IN PLACE on iOS: one persistent aurora whose calm is chased (the console's bg_mix), screens as transparent layers with the console's 0.26 s ease-out-cubic push/pop, an input drop for the transition, and the controller handed off through isActive — no more opaque bottom-up covers, no backdrop teardown. macOS keeps its sheets, tvOS its focus-engine covers. - The settings select is a real band: choice rows mount GamepadOptionBand, a spring-driven drum (Animatable body, ring-distance wrap, neighbours gated by focus and flight) whose retargeting spring accumulates rapid steps into one continuous spin. Reduce Motion falls back to a plain crossfade; toggles keep the quiet 14 pt slip. Verified: swift build (macOS), swift build --triple arm64-apple-ios17.0, swift test 208 passed / 0 failed. On-glass QA still owed: palette sweep on a pale palette, transition compositing over materials, drum feel on device.	2026-08-07 13:59:40 +02:00
enricobuehler	c0f8f051c3	fix(client): the probe printed a device index the env var does not take ... --probe-decode printed its DISPLAY position and called it the PUNKTFUNK_VK_DEVICE value. It is not. pick_device resolves that variable against the RAW vkEnumeratePhysicalDevices order (setup.rs, `devices.get(i)`) BEFORE any ranking runs, while the probe sorts discrete-first for readability. Those two orders disagree precisely on the hardware this flag exists to diagnose. pick_device's own comment records why the ranking is there: "enumeration order puts the iGPU FIRST on some hybrids (observed: Ryzen iGPU ahead of an RTX dGPU)". So on a hybrid laptop the number the probe printed for the iGPU could well be the number for the dGPU — a diagnostic handing out an actionable value that selects the other GPU, which is worse than printing none. Measured on the Arc + RTX 3500 Ada laptop, which is also where the first output went out with the wrong claim in it: three adapters, and the same Arc iGPU enumerated TWICE. So AdapterDecode now carries the raw enumeration index, captured before the sort, and the printer uses it; the "default presenter" marker stays on the first LISTED entry, because sorted-first is what pick_device lands on when nothing overrides. The duplicate is why the trailing hint names PUNKTFUNK_VK_ADAPTER as the safer knob and admits its limit: two adapters sharing a marketing name cannot be told apart by it, and a name match resolves to whichever enumerates first. The hint also states the thing this whole output invites a reader to get wrong — that a capable GPU in the list does not mean the decoder will use it, because Vulkan Video decodes on the presenter's device and PUNKTFUNK_DECODER does not move the presenter. Gates: fmt clean; clippy -D warnings on punktfunk-client-session and pf-presenter.	2026-08-07 13:52:23 +02:00
enricobuehler	43e713ecca	fix(client): the probe now accounts for every bit it prints ... First hardware run of --probe-decode, on the RTX 5070 Ti: driver decode ops: H.264, H.265, AV1 (0xF) Three names, four bits. 0xF is H.264|H.265|AV1|VP9 — bit 3 is VK_VIDEO_CODEC_OPERATION_DECODE_VP9_BIT_KHR, a real decode operation this client has no rung for, so the name table stopped short of it and the line looked complete while silently dropping a codec the driver had advertised. That is the exact failure this flag exists to prevent. The whole point of --probe-decode is that a reader can trust the words to cover the number; a mask with an unexplained bit asks them to trust it instead. VP9 is now named (marked as having no punktfunk rung, because advertising it as decodable would be its own lie), and any bit beyond the four we know prints as "unrecognised bits 0x…" rather than vanishing — so the next codec Khronos adds shows up as an unknown rather than as nothing at all. Gates: fmt clean; clippy -D warnings on punktfunk-client-session.	2026-08-07 13:46:28 +02:00
enricobuehler	31bb3ca7f7	Merge pull request 'The console answers a mouse and a finger, and host cards get a menu' (#90) from worktree-console-tabs-pointer into main ... Reviewed-on: #90	2026-08-07 11:38:41 +00:00
enricobuehler	d49f955171	fix(console/host menu): the actions get their explainer line and room to breathe ... The rows sat hard against the pinned title — the menu is the one form screen with no subtitle, so the list started at the very top of the content band. It now wears Add Host's explainer, which both says what the menu is for and is the air that keeps the first row off the title. A pinned card explains what unpinning does and does not touch, the same wording the Android dialog uses. Caught by the screenshot pass, not by a test.	2026-08-07 13:29:59 +02:00
enricobuehler	2830cbe912	Merge pull request 'Say which GPU can do Vulkan Video, and why not when it can't' (#89) from worktree-vulkan-decode-probe into main ... Reviewed-on: #89	2026-08-07 10:50:26 +00:00
enricobuehler	413a3e3e76	feat(client): say which GPU can do Vulkan Video, and why not when it can't ... Field report from an Intel Arc + NVIDIA laptop: pinning the Vulkan rung on the Arc iGPU silently produced D3D11VA, and there was no way to tell whether the build had tried at all. That ambiguity was ours, in three places. The "unavailable" log printed three of the FIVE conjuncts that gate Vulkan Video. A device with 1.3, the features and a decode queue family — but no codec extension — logged dev_is_13=true features_ok=true decode_family=true next to the word "unavailable" and named nothing actionable. It now prints all five, plus which base extensions are missing, which codec extensions are present, the decode family's own advertised codec operations, and the device name and vendor. It also no longer says "VAAPI/software" on Windows, where the rung below is D3D11VA. The native-vulkan PIN refusal logged `video_decode` alone. On a device that decodes something but not THIS codec, that reads as a contradiction: refused, yet video_decode=true. It now carries the caps mask and the codec bit that was wanted, so "your GPU can't" is distinguishable from "we asked for the wrong thing" — only the second is our bug. And `--probe-decode` is new: per-adapter Vulkan Video capability with no session, no surface and no logical device. For each GPU it answers usable yes/no, the driver's own decode ops, the extensions, and — when the answer is no — which conjunct failed, in words. Separate from --list-adapters, which the desktop shells parse line-by-line for their GPU picker and which therefore keeps printing bare names. The listing is ordered like pick_device (discrete first) and marks entry 0 as the default presenter, because that ordering is very likely the reporter's actual answer: pick_device ranks DISCRETE_GPU above INTEGRATED_GPU, Vulkan Video decodes on the PRESENTER's device by design (that is what makes it zero-copy), and PUNKTFUNK_DECODER does not move the presenter. So on a hybrid laptop, pinning the decoder while the dGPU presents probes the wrong GPU entirely — PUNKTFUNK_VK_DEVICE=<index> is the knob that moves it, and the index printed is that value. To keep the probe honest, VIDEO_BASE and VIDEO_CODECS moved to module scope and the five-way AND became video_decode_gate(), called by both the probe and device creation. A probe holding its own copy of the rule is one that eventually reports a capability the session then refuses — which reads to everyone as a decoder bug rather than a probe bug. Gates: fmt clean; clippy -D warnings over punktfunk-client-session and pf-presenter. The Linux container was unavailable (the host's disk filled and took the docker daemon with it), so this ran on the macOS host target only — the container leg is owed, and CI covers it on the PR.	2026-08-07 12:42:33 +02:00
enricobuehler	f06b3d9d04	feat(console): the console answers a mouse and a finger, and host cards get a menu ... Two gaps, both found on the shared Linux/Windows console UI. **The settings tabs only moved for a gamepad.** They were bound to the shoulder buttons and to PgUp/PgDn, and the legend spells PgUp/PgDn out only when NO pad is attached — so with a controller plugged in a keyboard user had nothing to find, and a mouse or a touchscreen could not change section at all. The root cause was wider than the strip: `SkiaOverlay::handle_event` matched only `KeyDown` and `TextInput`, so every mouse button, wheel and touch contact fell past the console into the run loop, which routes pointer input exclusively at `stream.capture` — `None` while you are browsing. Nothing in the console had ever been clickable. Making just the pills answer would not have helped either: the settings screen is opened with X from home, so a mouse could not reach it. So the console gets a real pointer path: - `Overlay::handle_pointer` carries mouse/touch in SWAPCHAIN PIXELS. The run loop converts (it owns the window, hence the display scale, and mouse coordinates are logical while fingers are normalised); the console then hit-tests the very rects it drew last frame. Only DIRECT touch devices are offered — an indirect trackpad already drives the mouse. - Widgets act on the PRESS, not the release. The list and both carousels scroll the focused item toward the centre, so what you pressed has slid out from under your finger by the time it lifts; press-to-act has no such race and there is no drag gesture to compete with. - The hint bar became the pointer's button bar. It is already the console's only on-screen statement of what the face buttons do, and a pointer has none — so its Confirm/Back/Secondary/Tertiary pills are clickable on every screen, which is what puts Settings and Library within reach of a mouse at all. - Tab / Shift+Tab change section; PgUp/PgDn still do, and the keyboard legend now reads "Tab". - Right-click is Back everywhere, EXCEPT at the root: B there quits the launcher and a right-click is far easier to fire by accident. Quitting stays explicit. **Host cards had no menu.** Every other client hangs Wake / Copy link / Edit / Forget off a host card; the console could add a host and connect to one, and that was all — so a renamed machine or a fat-fingered address stayed wrong forever unless you opened a desktop shell. UP on a saved tile now opens that host's menu, the same gesture the Android console uses, on the one direction a horizontal carousel leaves free. - `ConsoleCmd::UpdateHost` edits the stored host IN PLACE. Removing and re-adding would silently drop the fingerprint, the learned MAC, the pinned cards and the profile binding — that is a rename, not a re-pair. - `ConsoleCmd::ForgetHost` drops it; if it is still advertising it returns as a discovered, unpaired row, which is the honest state. - Forget arms on the first press and fires on the second. The other clients forget outright; a console is driven by a thumbstick from across a room. - A pinned profile card offers only Unpin. It is a shortcut, not a second host, and offering to forget the host from it would blur exactly the distinction a pin draws. - "Edit…" REPLACES the menu on the stack rather than stacking over it, so Back from the editor doesn't land on a menu describing the host as it was before the edit. Verified in the pf-lxcheck2 container (this crate compiles to nothing on macOS — a bare `cargo check` there is vacuous): plain build and `clippy --all-targets` clean under `-D warnings`, 72 tests pass. Seven are new, and cover the reported bug directly — a press on a pill selects that tab, and each tab still keeps its own cursor when a pointer is what switched it.	2026-08-07 12:36:22 +02:00
enricobuehler	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	55aba3e936	feat(client/android): the phone's gyro can speak for a gyro-less pad ... Opt-in "Gyro from this phone" (gyro_on_phone, off by default): this device's IMU sources wire pad 0's motion while that pad is a controller with no motion source of its own. On Android that gate is exact — the only pads that forward motion are the capture links (USB DualSense / SC2, claimed as ExternalPads), so the mirror stands down per sample whenever GamepadRouter.padHasOwnMotion(0) says a capture link holds the index, and sends nothing while pad 0 has no slot at all (motion never creates a host pad). "Rumble on this phone"'s sibling, data flowing the other way: same read-once-at-attach settings plumbing, same hardware-gated rows in the touch and controller settings (a TV box has no gyroscope to mirror from). DeviceGyro registers TYPE_GYROSCOPE + TYPE_ACCELEROMETER at ~200 Hz on a dedicated HandlerThread with batching disabled (maxReportLatencyUs = 0 — batching is poison for gyro aim), converts with the wire contract shared with pf-client-core (rad/s → 20 LSB/°·s, m/s² → g → 10000 LSB/g; Android's accelerometer already reads specific force, the DualSense report's own convention), and rotates each sample from the natural-portrait sensor frame into the controller frame by display rotation — a phone clipped landscape yaws when the player yaws instead of rolling. The remap matrix and unit constants are pinned by DeviceGyroTest. A stand-down edge (capture link claims pad 0, or session teardown) sends one zero-gyro sample so the host's virtual pad never keeps integrating an angular velocity this device stopped producing — the gyro sweep's stale-rotation latch, avoided by construction here.	2026-08-07 11:38:31 +02: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	c6b183450a	Merge pull request 'docs: the 4:4:4 story catches up with the code that ships it' (#87) from worktree-docs-support-matrix-444 into main ... Reviewed-on: #87	2026-08-07 09:27:32 +00:00
enricobuehler	3a35773b70	Merge origin/main; 4:4:4 has no software floor, and the ABI is 17 ... Reconciling with #85 (FFmpeg is gone from the client). Two of my claims were true against the pre-merge tree and false against this one. Note 4 said the desktop clients need no 4:4:4 decode probe "because every rung can display full chroma — swscale converts for the software rung". There is no swscale any more. The CPU floor is openh264 + rav1d, it is 4:2:0 8-bit by contract and has no HEVC at all, so it refuses a 4:4:4 stream rather than converting one. The client still advertises the bit unprobed, which was the point of the original fix, but the honest reason is different: full chroma is a hardware path (Vulkan RExt, NVIDIA today), and what catches a box whose hardware 4:4:4 fails is note 2's codec reconnect, not a downgraded picture. Note 13 repeated the same wrong premise and now names both halves of its warning. The C ABI is 17, not the 14 I read before the merge. Textual side of the conflict: #85 rewrote the Codecs column and notes 1-3 of the same table while leaving note 4's stale 4:4:4 text alone. Theirs kept in full; only the 4:4:4 column and note 4 are mine.	2026-08-07 11:25:17 +02:00
enricobuehler	5aa1ca392e	Merge pull request 'fix(host/encode): the Windows host build stops failing on unused split-encode helpers' (#86) from worktree-fix-winhost-clippy-dead-code into main ... Reviewed-on: #86	2026-08-07 09:22:57 +00:00
enricobuehler	b245cb6b29	Merge pull request 'FFmpeg is gone from the client — native decode M0–M10' (#85) from worktree-native-decode-m0 into main ... Reviewed-on: #85	2026-08-07 09:21:45 +00:00
enricobuehler	f49f22a292	fix(host/encode): the Windows host build stops failing on unused split-encode helpers ... The Windows host job died in its clippy step: eight items in pf-encode's split-encode policy (`SPLIT_AUTO`..`SPLIT_DISABLE`, `resolve_split_mode`, `max_forced_split_mode`, `clamp_to_engines`) were reported as never used, and `-D warnings` turns that into a build failure. Nothing about the encoder was wrong — the items simply have no reader in one particular build of the crate, and nothing was telling the compiler that. `codec.rs` compiles on every platform, but the split policy only ever has a caller on Linux (the libav NVENC path reads it unconditionally) or on Windows with the `nvenc` feature (the direct-SDK backend). A featureless Windows build of pf-encode has neither, so every item in the cluster is genuinely dead there. Gate them on the union of their callers' cfgs, the way `forced_split_width` next door already is. The step lints pf-encode itself WITH `--features nvenc,amf-qsv,qsv`, where the items are live, which is why this was invisible there; the failure came from the next command in the same step, `clippy -p pf-vdisplay`, which pulls pf-encode in as a plain default-features dependency. Same item-level `dead_code` trap this crate has now hit five times. Verified: default-features pf-encode reproduces all eight errors before the change and none after (macOS default-features exercises the identical "cluster has no caller" arm as featureless Windows — the two remaining errors there, `vbv_frames_env` and a redundant closure call, are pre-existing and macOS-only; both items have real Windows callers). Linux default-features and Linux + nvenc `--all-targets` both stay clean, so the callers still see the policy. `cargo fmt` clean.	2026-08-07 11:11:15 +02:00
enricobuehler	f1e7ec3535	docs: the 4:4:4 story catches up with the code that ships it ... The support matrix said the desktop clients' Full chroma switch "has no effect today" and that only the Apple client asks for 4:4:4. Both stopped being true in July: `clients/session/src/main.rs` advertises VIDEO_CAP_444 whenever the setting is on, deliberately with no client-side probe, because every desktop decode rung can display full chroma — the Vulkan presenter samples the 2-plane 4:4:4 pool formats and swscale converts for the software rung. So Linux, Windows and Apple all ask; Android is the one that genuinely doesn't implement it. The other half was HDR. `9f72a3b6` gave the Windows IDD-push capturer a packed 10-bit BT.2020 PQ RGB output, so NVENC encodes HEVC Main 4:4:4 10 and the two compose — the matrix still said "4:4:4 and HDR together is refused", and hdr.md still called PyroWave the only exception. Linux is the side that keeps the trade: handshake.rs resolves the depth back to 8 for a 4:4:4 session, so full chroma wins and the stream is SDR. Three cells move ❌ → ⚠️ rather than ✅ on purpose. The client half is unconditional, but the host half is not: HEVC 4:4:4 means an NVIDIA host, or PyroWave on any vendor. The notes say which, and point at the stats overlay's `4:4:4→4:2:0` tag — this negotiation is the one that fails loudly. Also: C ABI version 13 → 14; PyroWave's ≈8K 4:4:4 block-index ceiling now has a note; and the roadmap no longer calls Intel 4:4:4 a hardware limit, which the matrix and vaapi.rs both contradict — VCN can't, VAAPI hasn't. Spot-checked and left alone as still accurate: the Linux client clipboard stub, VAAPI declining 4:4:4, Android having no 4:4:4 at all, and the wire / driver / gamepad-channel versions.	2026-08-07 10:58:58 +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	3608de25ed	Merge pull request 'fix(ci): runner hygiene stops eating its own jobs' (#84) from worktree-ci-runner-hygiene into main ... Reviewed-on: #84	2026-08-07 08:37:42 +00:00
enricobuehler	75dfab1d35	fix(host): a reconnecting session inherits its launch instead of starting it again ... Two defects, found while tracing M8's codec-fallback reconnect and recorded verbatim in d5e23146 as out of scope there. A client retry re-sends Hello::launch verbatim, and the host launched unconditionally. Steam and Epic URIs hide it — the launcher focuses the running copy — but a gog:/custom: target really did start a SECOND COPY of the game. The client cannot fix it by dropping the field: on Linux the per-session gamescope is re-adopted through pf-vdisplay's display registry, whose reuse key includes the launch command, so a retry without it orphans the running game. And the retry minted a fresh launch_stamp, so procscan refused to adopt a game started more than 2 s before it — the game was minutes old, so a reconnected session had no game-exit detection for the rest of its life. Both are now answered by a launch registry (launchreg.rs): one record per (client fingerprint, library id), written at launch time and INDEPENDENT OF THE TERMINATION POLICY. That independence is the point. The existing fingerprint-keyed reclaim only exists under GameOnSessionEnd::Always — under the default Keep, arm_grace is never called, so nothing was recorded at all in exactly the configuration the defect was reported in. The design correction that matters: at launch time the host knows NOTHING about the game's processes — that is the premise of the whole lease design. So identity flows BACKWARDS from the watcher, which publishes the concrete ProcRefs it adopted, and the registry's liveness is Scanner::alive over that recorded set, re-verified by (pid, start). Never a re-scan by spec: a later scan would find a copy the player started since, and adopting that is what procscan's rule 1 forbids. The published set is never cleared on exit either — the last thing the watcher saw is what makes a quit game read Gone rather than "no opinion", which is how it becomes relaunchable at once instead of being suppressed for the window. On rule 1: an adopting session inherits the older floor, so its own find() admits what the ORIGINAL session's lease already admitted for its whole life. That is the correct reading of "the same launch, continued" and not a new exposure — rule 1 forbids adopting processes that PREDATE the launch, and these postdate it. The match rule is pure and total (covers()): liveness is authoritative where it has an opinion, and only Unknown falls through to the tie-breakers — a live holder, or a 90 s in-flight window for a re-dial while the launcher is still working. Gone beats both, deliberately: a title that crashed on startup must relaunch at once. Both race orders are handled and neither is relied on. Teardown-first takes the Running arm; handshake-first (a fast re-dial on a half-open connection) takes the holders>0 arm, and the old teardown then sees superseded() and does nothing — without which, under Always, it would arm a grace the new session had already passed its chance to reprieve, and the reaper would kill the new session's game. Two tradeoffs taken deliberately: a custom: command with no detection hints stays Unknown forever, so that reconnect trades game-exit detection for not double-spawning; and IN_FLIGHT_WINDOW is a fixed 90 s rather than sharing disconnect_grace_seconds, because the two have opposite failure costs — grace being wrong leaves a game running, this being wrong silently swallows a launch the player asked for. Gates: fmt clean; clippy -p punktfunk-host --all-targets -D warnings green in the Linux container; 418 passed, +9 exactly the new tests. One failure, gamestream::stream::tests::sender_delivers_batches, is pre-existing and environmental — a UDP-loopback EINTR under qemu at stream.rs:1697, outside every hunk in this change (the last is at +448), and it fails identically on a pristine HEAD. I reproduced both the failure and its location myself rather than taking it on report. ⚠ OWED: the Windows leg is COMPILE-UNVERIFIED. cargo check --target x86_64-pc-windows-msvc dies in ring's C build on macOS and xcheck.sh does not cover punktfunk-host. The Windows edits are small restructures of existing branches plus a bool assignment, reasoned through but seen by no compiler. Run it on .133 before this merges. I narrowed that exposure by inspection afterwards, and it is smaller than the blanket warning suggests. The change presents exactly two things to a Windows compiler that a Linux one did not already see. launchreg gates only alive_count (lines 227/231), whose cfg(any(linux, windows)) arm calls Scanner::system().alive(procs) — the identical call gamelease.rs:563 already makes in code that compiles on Windows today. And the Windows launch arm at native/stream.rs:1666 reads only ungated bindings the Linux arm type-checks thirty lines below it (adopt_launch:1658, spawned_now:1663, launch_claim:1463) and calls only the pre-existing library::launch_title. No new type, no new signature, no Windows-only API. That is an argument, not a compile. The run on .133 is still owed.	2026-08-07 10:14:21 +02:00
enricobuehler	138a1f1b2f	fix(host/windows): the staging-dir SID checks document their unsafe blocks ... clippy's undocumented_unsafe_blocks (deny) flagged the three blocks that 81039581 introduced: the SAFETY comment sat outside the closure, so IsValidSid/EqualSid inside it read as undocumented, and from_raw_parts shared a comment that only covered the GetLengthSid line above it. Windows host clippy is the only leg that lints this cfg(windows) code, red since.	2026-08-07 10:11:04 +02:00
enricobuehler	39cfb7234c	fix(ci/docker): a cache-hit builders job stops failing on a login it never uses ... The LAN-registry docker login only serves the Push step (Reconcile and Tag-for-release authenticate via curl -u), but it ran unguarded — so a hit=true leg landing on a host with a misconfigured docker daemon failed at login with nothing to push (run 16044/16013 f44 leg). Gate it like Build/Push.	2026-08-07 10:11:02 +02:00
enricobuehler	c3cdee9bf5	fix(ci/prune): the 2-minute image prune stops deleting images mid-pull ... docker image prune -af --filter until=2h keyed on image CREATION time, so a base image built days ago that merely had no container at that instant was "aged" — including one a job had just pulled and not yet created. Measured 2026-08-07: three job failures, each coinciding with a prune tick to the second ("No such image: …punktfunk-rust-ci:latest", every step cancelled), plus a 4-7 GB re-pull of every idle base image within minutes. The routine tick now retires only what this host actually accretes — per-SHA app tags older than 2h (their creation time IS the local build time) — then sweeps dangling layers, which cannot touch a tagged image. The blanket -a prune survives only in the near-ENOSPC burst guard, where one re-pull beats every concurrent job dying. docker-reclaim.{sh,service,timer} are the hourly leak reclaimer that so far lived hand-installed on home-runner-1 only; home-runner-2 went without it and re-accumulated 176 leaked volumes (~60 GB) until jobs died of ENOSPC on 2026-08-06/07. Checked in so both hosts install the same files from here.	2026-08-07 10:10:59 +02:00
enricobuehler	dee97e893c	fix(vkdecode): the address the driver keeps is now the address we keep ... The AV1 use-after-free fix (cdd1f3ef) stabilised the wrong half. NVIDIA was measured retaining pColorConfig, so StoredParamsAv1 boxed the colour and timing blocks — but OwnedStdAv1SequenceHeader kept the Std struct ITSELF inline, so the pStdSequenceHeader we handed vkCreateVideoSessionParametersKHR was a stack address inside ensure_parameters, dead the moment it returned. The fix worked because of WHICH pointer that driver happened to hold. A driver retaining the outer one instead — no more of a spec violation than retaining pColorConfig was — reproduces the original bug exactly: plausible pictures, wrong content, no error and no counter moved. The same shape was in the shipping codecs, one step further from evidence: the H.264 and H.265 create paths pointed pStdSPSs/pStdPPSs/pStdVPSs at function-local Vecs, and both Add paths handed over the wrapper's inline std field and then moved the wrapper. Those are spec-legal — the object stores copies — and have never misbehaved on the fleet. They are fixed anyway, because that is precisely what was true of H.264/H.265 before the same class of bug was found in them, and a correctness argument that reduces to which vendor we tested is not one. So: the Std struct is boxed inside each owning wrapper (one level out from what _color_backing already did), and the contiguous create-time arrays are now fields of the stored parameters, assembled at their final address. Identical bytes at identical offsets — only where they live changed. The line drawn deliberately, in prose at session.rs:29: Std DATA is pinned; the VkVideoSessionParametersCreateInfoKHR chain itself is not. Retention there would be a different and far more extreme class of driver bug, and pinning it needs a self-referential struct over lifetime-parameterised builders. ⚠ NOT hardware-verified. No GPU has run this — the fleet is unreachable and the 250/250 parity that proved this code bit-exact cannot be re-run. That is why the change is constrained to address stability alone, and why it ships five CPU-only tests instead: three capture the pointer handed to Vulkan, perform the real move, and assert it survives — each verified FAILING first, with genuinely differing addresses, not a tautology. Two more pin the create-array ownership; those fail before the fix as compile errors rather than assertions, because the pre-fix bug there is a dangling pointer and asserting on it is UB. Also: caps.rs claimed the borrow checker pins a profile chain between wire() and its last use. False at exactly one site — decoder.rs took a raw *const, ending the borrow, leaving nothing but inspection to stop a future editor moving the chain before create_query_pool. Correct today, guarded by prose, which is how the first bug shipped. It is now compiler-enforced: the pointer write and the create call live inside one helper that takes the profile by reference, so the borrow is held across both by the signature. An audit cleared the chains otherwise — no entry point we pass one to retains it. Gates: fmt clean; clippy -D warnings over pf-vkdecode AND pf-client-core in the Linux container (its only real consumer, which cannot build on macOS at all — wol.rs uses deps its manifest gates to linux/windows, so workspace clippy has never passed there and does not now); 187 lib tests green on Linux, up from 182.	2026-08-07 09:57:39 +02:00
enricobuehler	93b8528d09	Merge pull request 'fix(encode): NVENC split-frame encode never engaged for HDR — engage it, measured' (#83) from worktree-nvenc-s1-split-reconfigure into main ... Reviewed-on: #83	2026-08-07 07:57:29 +00: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	515a3c2912	feat(pf-encode): wire split arbitration on Windows too ... The last coverage gap, and only worth building once S1 proved it possible: the Windows backend drives NV_ENC_DEVICE_TYPE_DIRECTX, and an in-place splitEncodeMode change had never been tested there. It works (071358cb), so the arbiter is now ungated from Linux-only to the union of both direct-SDK backends and wired into windows/nvenc.rs: the submit stamp, the feed hook on AU completion, apply_split_mode, split_key, arm_split_arbiter, and set_send_spread_us. Same gates as Linux, and they are correctness conditions rather than preferences: opt-in while it earns trust, an operator PUNKTFUNK_SPLIT_ENCODE pin always wins, a cached verdict short-circuits, >=2 engines, never H.264, and the sub-frame trade is only entered when the host has actually reported a send spread to price it with. The one Windows-specific difference is that `async_rt` is a real possibility here (opt-in two-thread retrieve) and the arbiter refuses it, because under pipelined retrieve the submit->AU span includes queue depth and the comparison would be noise. ⚠ Two more instances of the same item-level dead_code trap, caught by the Windows run and not by reasoning -- that is now 4 and 5: - `clear_split_verdicts` is called only by the Linux on-hw test, so it is dead on Windows; gated to `all(test, target_os = "linux")`. - The arbiter methods first landed inside `impl Encoder` rather than the inherent impl (the anchor I used, supports_chunked_poll, is a trait method), which the compiler caught as "not a member of trait Encoder". Verified .158 (RTX 4090 / Ada, driver 610.88, D3D11): clippy --features nvenc --all-targets -D warnings clean, and 2 on-hardware NVENC tests green including S1 re-run with the arbitration code in place (engines=2 latched, DISABLE->TWO_FORCED accepted, zero IDRs, reverse accepted). Verified .21: clippy clean with AND without the nvenc feature, 65 unit tests, 25/25 NVENC on-hardware. fmt clean.	2026-08-07 09:28:34 +02:00