160 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Fable 5	63224cd31d	feat(client/android): the eighth field carries the OS, and cards wear it ... The JNI discovery record appends `os` as its eighth ␟-field (append-only — the Kotlin parser's arity guard already tolerates both old and new records, now pinned by tests in both directions), sanitized on the Kotlin side by the mirrored chain grammar next to the shared `osIconTokens` walk. `KnownHost` persists it additively (optString — no schema bump, migration passes it through) with `learnOs` beside `learnMac`, learned on the same discovery tick. Compose ships no brand icons, so OsIcons.kt vendors the ten marks as raw SVG path strings built into ImageVectors via PathParser (lazy, cached) — they tint with the Material theme like any Icon. The host card's address line leads with the mark, live advert preferred over the stored chain. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 17:58:33 +02:00
enricobuehlerandClaude Opus 5	e44baf6768	fix(client/android): a decoder fed nothing it can decode must ask for a new anchor ... An Android TV box reported a black screen with a perfectly healthy HUD: AUs arriving at 40 fps, ~312 bytes each. That size is all-P-frames — no IDR anywhere in the window, and nothing asking for one. The stats being readable is the rest of the story: the overlay is a layer over the SurfaceView in the same window, so the panel was fine and the surface simply never received a frame. The decode thread only starts at `surfaceCreated`, so a slow box can be handed the stream mid-GOP. A hardware decoder does not error on references it never had; it emits nothing at all. Under infinite GOP the host sends no further IDR unless asked, and neither Android loop ever asked: every recovery trigger they have keys off a drop, a gap or a decode error, and a decoder that quietly produces nothing trips none of them. The session stayed black for its whole life. The shared gate has this case (`on_no_output`, which pf-client-core and the Apple client both feed) but its per-AU streak counts one-in/one-out decodes, and MediaCodec is pipelined — "this AU produced no output" is not something these loops can observe. A wall-clock silence window is the same signal in the shape Android can measure: fed for 500 ms with nothing coming back arms the freeze and requests a re-anchor keyframe, and the gate's deadline keeps re-asking until one lands. 500 ms so it can never fire on a decoder that is merely slow to spin up. Also log the first presented frame. The periodic tally starts at 300 rendered frames, which is no help whatsoever on a session that renders none — its absence is what separates "never reached glass" from "reached glass and looked wrong". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 17:57:13 +02:00
enricobuehlerandClaude Opus 5	1862010003	fix(client/android): a settings edit belongs to the scope the chips show ... Change a setting on the defaults, switch to a profile, change the same row: the globals moved again and the profile recorded nothing. Switch back, and the next edit went into the profile — which reads as "the default settings can't be changed any more". `update`/`resetField` reached the rows as `::update` — callable references, and two of those compare equal however different the scope they closed over. Compose saw an unchanged callback and skipped the whole detail page on a scope switch that moved no value on screen, which is the ordinary case: a profile inherits the globals until it overrides something. The row went on calling the reference it was first handed, one scope behind for the rest of the session. Resolve the scope from the live state at the edit instead of closing over it, so the write follows the chips whether or not the page recomposed. `key(active?.id)` around the detail page covers the other half — a row's own `remember` is per-scope state too, and "Custom…" picked while editing a profile has no business still being picked over on the defaults. The model tests can't see this: it takes the real Compose runtime to skip a composable. SettingsScopeTest drives the screen itself. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 17:57:13 +02:00
enricobuehler	8fee1139f6	chore(client/android): adopt AGP 9.3.1 / Gradle 9.5.0, and tell CI about it ... The bump itself came from Android Studio; this makes the rest of the repo agree with it. The toolchain line at the top of the root build file still claimed AGP 9.2.0 and Gradle 9.4.1, and both Android workflows named "AGP 9.2" as the reason they pin JDK 21 — the sort of comment that is trusted precisely because it looks maintained. The Gradle caches also needed telling: they cache the DISTRIBUTION under `~/.gradle/wrapper`, keyed on a hash of `*.gradle.kts` only. This bump moved both files so the key changed anyway, but a wrapper-only bump would have restored a key that can never contain the new distribution. The wrapper properties are in the key now. Verified with the workflows' own commands on the new toolchain: `:app:testDebugUnitTest -PskipRustBuild --stacktrace --rerun-tasks` (the screenshot job, 45 tasks from cold) and `:app:assembleDebug` including the cargo-ndk native build. AGP 9.3.1 resolves no build-tools newer than the 37.0.0 both jobs install, so their sdkmanager lines still cover it.	2026-07-29 12:17:18 +02:00
enricobuehler	93fe9f134e	refactor(client/android): the colour palette reads as one object ... Three things were wrong with it, and they compounded. **The order was arbitrary** — orange, blue, pink, green, amber, violet, cyan, rose jumped back and forth across the wheel, so it looked like a bag of colours rather than a choice. It is sorted by hue now, one clean sweep, with the degrees in the source so it stays that way when a colour is swapped. That is also the order creation hands them out in, so someone making profiles one after another walks the spectrum. **The layout fought the form.** A fixed-size grid centred in the dialog floated free of the left-aligned labels above it; distributed across the full width the swatches stopped looking related to each other; and eight colours wrapped to a short second row that read as the grid running out. Each row now FILLS the width with its swatches sharing it equally, so the palette's edges line up with the name field's and both rows are the same length. The palette gained two hues to make that work: ten divides by five, eight didn't divide by anything useful. **Selection was a heavier circle.** A border drawn on the swatch's own edge reads as a thicker ring, not as "this one". It is a ring OUTSIDE the disc with a gap, plus a check — which also means the selection survives a reader who can't tell two of these hues apart. The ring's space is always reserved, so picking never nudges the grid.	2026-07-29 12:17:18 +02:00
enricobuehler	a3ec30c287	refactor(client/android): manage a profile from its own chip, and pick its colour up front ... Two things about the profile UI were backwards. **The manage menu was parked after the last chip.** A single overflow button at the end of a horizontally-scrolling row, acting on whichever profile happened to be selected — so reaching it meant scrolling past every profile, and nothing on screen tied the button to its target. It now lives ON the chip: the selected profile grows a chevron, tapping it again opens Edit / Duplicate / Delete anchored underneath, and the action is attached to the object it acts on. The wandering ⋮ is gone. **Colour was an afterthought.** A profile was named at creation and coloured later, through a menu item most people would never find — so every profile looked colourless until someone went hunting, and the accent is precisely the signal that has to be right from the first moment (it is all a bound host card's chip and a pinned card's tint have to go on). Name and colour are now decided together, in one dialog that serves both creation and editing, with the next unused colour pre-selected. "Rename…" and "Change colour…" collapse into one "Edit…", which is three menu items instead of four and one dialog instead of two. The chevron rides inside the chip's label rather than the `trailingIcon` slot, for the same reason the accent dot does: those slots reserve an 18dp icon and shrink the chip's padding, which is what made a chip with a dot sit differently from "Default settings" beside it. Driven on glass: created a profile with a colour chosen in the dialog, opened the menu from the selected chip, and edited name and colour together.	2026-07-29 12:17:18 +02:00
enricobuehler	f2874a5324	feat(client/android): a profile gets a colour, and you can change it ... The accent was reserved in the schema and used everywhere it mattered — the scope chip, a bound host card's chip, a pinned card's tint — but nothing ever set one. `newProfile` left it null, and design §5.1's "Change color" was the one item of the scope menu I didn't build. So every profile a user actually created was colourless, and the only one that wasn't was a test profile I had seeded by hand through adb. That inconsistency was the whole visible symptom. Creation now hands out the first unused colour from an eight-entry palette, so profiles are distinguishable from the moment they exist — which is the point of the accent on the surfaces where a profile has no room for its name. The palette avoids the presence green, which means "this host is up" and nothing else. Past eight it wraps rather than handing out nothing: a repeated colour beats an invisible chip, and the picker is right there. "Change colour…" joins Rename / Duplicate / Delete, with "no colour" offered as a real choice rather than only an initial state — a profile made before this existed keeps working, and its chip falls back to the theme's accent. The colour is presentation, not a setting: it is not in the overlay, so it never reaches a resolved connect. Tested, and driven on glass end to end — two profiles created through the dialog, distinct accents on their chips.	2026-07-29 12:17:18 +02:00
enricobuehler	4803260aff	fix(client/android): a settings row's gaps are set, not inherited ... One `spacedBy(4.dp)` was doing three different jobs in a settings row, and got all of them wrong. The caption sat as close to its control as the override marker did, so the row read as one undifferentiated stack — and the marker, being the FIRST child of a card that already pads 16dp, added its own vertical padding on top of that, so a marked row started with visibly double the gap every other row has. Each gap is now stated where it belongs: the marker has no vertical padding of its own (it sits exactly at the card's padding, level with an unmarked row's control) and owns the 6dp down to the field it annotates; the caption owns the 10dp up to it. Tighter above, roomier below — so the marker groups with its control and the caption reads as a separate note rather than part of it. The "Reset" hit area loses most of its vertical padding to make that work; it keeps the horizontal padding and the full-width row, so the target is wide rather than tall. Confirmed on glass, not just in the screenshots.	2026-07-29 12:17:18 +02:00
enricobuehler	7f40afc525	fix(client/android): the settings page stops shouting ... Three things made the settings surface hard to read, all of them mine. **The captions were desktop prose on a phone.** A1 took the Windows client's `described()` text close to verbatim, which is right for a wide desktop row and wrong for a ~340dp column: four-line paragraphs under every control, so the page read as documentation with some dropdowns in it. Every caption is now one line, two at the outside. The wording still says the thing that isn't obvious from the label — "Native follows this device's refresh rate", not a restatement of "Refresh rate" — it just stops explaining the parts nobody needed explained. **The override marker was taller than the control it annotates.** "Reset to default" was a `TextButton`, which brings its own 48dp touch target, so a marked row grew a half-height band above it that dwarfed both the field and the caption underneath. It is one compact line now, with a padded hit area on the word itself — the right trade for a secondary action inside a dense list. **The scope note's spacing was lopsided**: 8dp above it, 4dp below, so it drifted toward the chips instead of sitting between them and the divider. The two settings screenshots cover all three.	2026-07-29 12:17:18 +02:00
enricobuehler	cee39b3751	fix(client/android): two spacing slips in the profile UI ... The name field in "New profile" sat flush against its caption — the `Column` holding them had no arrangement at all, so the explanatory line read as part of the input. And a profile's scope chip didn't line up with the chips beside it: the accent dot was in `FilterChip`'s `leadingIcon` slot, which reserves an 18dp icon and shrinks the chip's leading padding to suit. A 10dp dot in that slot left the chip's insets visibly different from "Default settings" next to it. The dot now rides inside the label, so every chip keeps the same padding and the gap to the name is ours to set rather than a side effect. Both were eyeball-only surfaces: no screenshot covered either. The name field now has one — the dialog itself can't be captured (a focused text field inside a Dialog window never reaches idle under Robolectric, the same trap the PIN scene documents), so its body is extracted and the scene renders exactly that, in both the normal and duplicate-name states. The chip row was already in the profile-scope shot.	2026-07-29 12:17:18 +02:00
enricobuehler	b6819b80e2	refactor(client/android): the host card says as much in a third less space ... Three stacked badges, each a coloured dot beside a word — presence, trust, profile — turned a host card into a legend for itself, and made it ~220dp tall for four facts. Two of the three didn't need to be badges at all. **Presence moves onto the avatar**, the idiom every contact list already uses: a dot on the corner, and one fewer labelled row. It is GREEN when the host is up — a fixed green, not the scheme's primary, because Material You's primary is whatever the wallpaper says and might itself be a green that then means nothing. Offline is a hollow ring rather than a differently-coloured dot, so the state survives a colour-blind reader and a greyscale screenshot; TalkBack gets the word either way. **Trust moves to the free top-left corner** as a glyph mirroring the overflow on the right — locked (paired), a key (this host will ask for a PIN), an open lock (trust-on-first-use). It costs no height at all, and it is a state you glance at rather than read; the label rides along as the content description, and the dialogs that actually make the trust decision spell it out in sentences. That also retires the pill whose long label ("Trust on first use") was what made cards tower over their neighbours in the first place. **The profile chip stays a chip** — it is the one badge that earns the accent, because it is the only one that says what a tap will DO. Net: ~220dp down to ~150dp, one badge instead of three, and the only reserved slot left is the chip's (the row-height rule still applies to it).	2026-07-29 12:17:18 +02:00
enricobuehler	6236989b03	fix(client/android): host cards in one row are the same height again ... `LazyVerticalGrid` sizes a row to its tallest item but does NOT stretch the others, so anything variable inside a card shows up as cards stepping up and down within a single row. Two things varied. The new one: the profile chip. A bound host's card grew ~34dp its unbound neighbour didn't have. The chip's space is now reserved on every card in a section as soon as ANY card there carries one — so a user with no profiles still never sees the gap, and a mixed row is flush. The older one, which profiles only made more visible: the trust pill. "Online" and "Trust on first use" were laid out on one Row, so the long label wrapped to three lines INSIDE its pill and that card towered over a "Paired" one. The pills now wrap as pills (a FlowRow), one line each, in a reserved slot that a two-pill card and a one-pill card both fit inside. Both slots are `heightIn(min =)` rather than fixed, so a large accessibility font scale grows the card instead of truncating a host's trust state — and the pill slot is sized with room to spare rather than to an exact two lines, because the equal-height guarantee only holds while every card fits INSIDE the reservation. The hosts screenshot scene now orders its mocks so an unchipped card sits beside a chipped one, and a long trust label beside a short one — the two shapes that used to step. Verified there and on the emulator.	2026-07-29 12:17:18 +02:00
enricobuehler	6ea10ab383	feat(client/android): the console settings read like every other surface ... The console page had its own category names — Stream / Video / Audio / Controller / Interface — which is a sixth mental model for the same settings, on the surface least able to afford one (you navigate it a row at a time with a D-pad). Its headers are now the shared map with the same sub-sections the touch settings and the desktop clients use, so a setting sits in the same place whichever surface you found it on, and its groups appear in the same order. The ROWS stay the couch-relevant subset. A pad can't drive a touch-input picker, and adding one for the sake of symmetry would be parity in name only. Retitled "Default settings": this page edits the base layer only — the console honours a host's bound profile but doesn't edit profiles (design §5.4) — and a bare "Settings" quietly implies it changes whatever that host streams with. Same reason the session console and Decky are retitled. Also carries A2's SC2 fix onto this surface: the passthrough toggle was absent from the console page entirely, on the machines where a Steam Controller 2 is most often the only input.	2026-07-29 12:17:18 +02:00
enricobuehler	02f7cfbb1d	feat(client/android): the speed test, writing where the tested host actually reads ... Android had no speed test at all — the one client where "what bitrate should I use?" had no answer but guessing. It measures over the REAL data plane: a minimal 720p connect, then the host bursts filler for two seconds, so the answer is about the link this host's stream will take rather than generic throughput. Two new JNI calls (`nativeSpeedTest` / `nativeProbeResult`) front the core's probe, deliberately measure-only. The measurement is the easy half. The half that was wrong on every client for a long time is WHERE the answer goes. A measured bitrate belongs in the layer the tested host actually resolves bitrate from (design §5.3): its bound profile's override if it has one, the global if the host is unbound — and if the host is bound to a profile that INHERITS bitrate, both are defensible, so the user gets both buttons instead of us guessing. That target depends only on the host, so it is known before the result lands and the button can say where it will write: "Apply to “Travel”". Writing the global unconditionally — the old behaviour everywhere — is what made measuring the slow box downstairs quietly re-tune the desktop. Reachable from the host card's overflow and from the console's host options: a TV box on a powerline adapter is exactly the machine whose link is worth measuring, even though profile editing stays off that surface. While there: a successful write no longer renders in the error container. The connect screen's one status line was red by design — correct for a failure, a small lie for "75 Mbit/s set in “Travel”" — so confirmations got their own. Verified on the emulator against a real host: 108 Mbit/s measured on a host bound to a bitrate-setting profile, target resolved to that profile, and Apply wrote 75397 kbps into the profile's overlay with the global untouched and the profile's other overrides unmoved.	2026-07-29 12:17:18 +02:00
enricobuehler	f6f991648d	fix(client/android): a pinned console tile is a shortcut, not a second host ... The touch grid withholds Edit / Forget / Wake from a pinned card on purpose — a pin is a shortcut to one host+profile combination, and offering the host's destructive actions on it blurs exactly that. The console carousel didn't: its pinned tiles carried the host record, so Up on one opened the full host options (including Forget), and Y opened the host's library. They now carry which profile they pin, so the options dialog offers the one action a pin has — Unpin — and says what unpinning does and doesn't touch.	2026-07-29 12:17:18 +02:00
enricobuehler	42bd5be941	fix(client/android): a link must not end the stream it isn't allowed to preempt ... Found on glass. "A URL may never preempt a live session" was enforced inside the composition — which is the one place that can't see it happen. With `launchMode = standard` a `punktfunk://` link arrives as a SECOND activity instance in its own task; that instance's session state is empty, so it routed the link as a fresh connect, and the streaming task being backgrounded ended the session it was supposed to protect. The rule held only for the rare `FLAG_ACTIVITY_SINGLE_TOP` caller that lands on `onNewIntent`. The live session is now published process-wide, and `onCreate` refuses there — before this instance is ever resumed, so finishing it leaves the streaming task in front, untouched. Static state is what crosses the gap between two activity instances that know nothing about each other; the process dying resets it, which is also the right answer. Verified on the emulator against a real host: with a stream up, a link naming a DIFFERENT host now leaves it running (same session, same HUD, no second connect) instead of tearing it down.	2026-07-29 12:17:18 +02:00
enricobuehler	8172e819a4	fix(client/android): the JNI crate wouldn't build under the unsafe-op lint ... `unsafe_op_in_unsafe_fn` is denied workspace-wide, and two operations in the render-callback path were still bare inside their `unsafe fn` — so every Android build failed at `cargo ndk`, before any Kotlin work could reach a device. Pre-existing on main and unrelated to the Android settings/profiles work; found by building the APK for it. Both get the explicit block and the SAFETY note their neighbours in the same file already carry: the reclaimed pointer is the one `install_render_callback` leaked, and the callback's `userdata` is that same pointer, alive for as long as the codec that delivers the call.	2026-07-29 12:17:18 +02:00
enricobuehler	b63f9f4ac0	feat(client/android): punktfunk:// links open a stream ... Android was the last client with no URL door at all: no VIEW intent filter, no `onNewIntent`, no parser. Now a Playnite entry, an OS shortcut, a Stream Deck macro or a wiki link can open a stream on a host this device already trusts. The parser is a PORT, not a new design. `clients/shared/deeplink-vectors.json` is the cross-language contract, and the Kotlin suite runs the same 44 cases the Rust one does — including every refusal code — so three parsers cannot drift into three different security postures. It is resolved from the shared path rather than copied, because a copy would be a fourth contract free to go stale. Strict percent-decoding with a REPORTING UTF-8 decoder, so `%FF` is a refusal rather than a U+FFFD that survives into a log line or a filename. The routing lives in `ConnectScreen` because that is what owns the connect path — trust decisions, the local-network grant, wake-and-retry — and a link must go THROUGH all of it, never around it. The rules are absolute and each one is a branch you can point at: a known, pinned host does exactly what tapping its card does; an unknown or never-pinned one gets the confirmation sheet, from which the normal pairing flow proceeds under the user's eyes; an `fp=` that contradicts the stored pin is a hard refusal; an ambiguous host name or a profile this device doesn't have refuses with a notice naming what failed, because a "Work" shortcut streaming with the wrong settings is worse than an error; a link arriving mid-stream never preempts it (pointing at the host already being streamed is a no-op — the intent has already brought the app forward, which is what focusing it means). `wake` and `browse` parse, and are refused with a notice rather than silently connecting. `launch=` and `profile=` ride the whole path, including through a trust decision: a link to a host that still needs pairing keeps its game and its profile across the confirmation instead of quietly landing on a plain desktop session. `launchMode` stays `standard` and the `configChanges` set is untouched — its `keyboard` entry is what keeps an SC2 claim from killing a running stream. The VIEW intent is read in both `onCreate` and `onNewIntent`, which is what that launch mode requires.	2026-07-29 12:17:18 +02:00
enricobuehler	46461eb0b6	feat(client/android): profiles — per-host settings, one settings UI ... Every client setting was global: pick 4K@120 HEVC and it applies to the beefy desktop, the work laptop and the retro box alike. Android now has the same answer the desktop clients got — named bundles of overrides, bound per host. A profile is a bundle of OVERRIDES, not a snapshot, and getting that right is the whole feature. An untouched field keeps following the global live, so fixing a global once fixes it everywhere. A touched field is recorded even when it equals today's global — that is a pin, and it must survive the global later moving. The only way back to inheriting is an explicit reset, never a diff at save time. `SettingsOverlay.absorb` is the seam that makes this work with a per-control commit: it compares against what the control was SHOWING, not against the globals. One settings UI, not two. A scope chips row on top switches the whole surface between the defaults and one profile — same categories, same rows, same captions — so a profile editor cannot drift from the thing it overrides. In profile scope only profileable rows render (the console-UI toggle, the library, auto-wake, the controller diagnostics are facts about this device and simply aren't there), every row shows the effective value, and an overridden row carries a marker and a reset. On the host side: the Edit sheet binds a default profile and pins profiles as cards; a bound card wears a chip naming what a tap will do; a pinned host+profile combination gets its own card right after its host, one tap instead of a menu — which is also what makes profiles usable on the console, where menus are not. "Connect with" is a one-off from any card and never rebinds; rebinding is always the explicit act of opening the Edit sheet. Precedence is the cross-client one — one-off, else binding, else none — with the empty reference meaning "force the defaults", a real choice on a bound host. A deleted profile leaves a dangling binding that resolves to none and a pin that stops rendering: never an error, never a blocked connect. Resolution happens ONCE per connect, in `ConnectScreen`, and the resolved settings ride the `ActiveSession` into the stream — so the "applies from the next session" footers stay true and the stream can't disagree with the connect that opened it. The stats overlay's first line names the profile, which answers "which profile am I on?" from inside the stream. Nine tests cover the model against the Rust suite's cases (apply, absorb, pins, clear, unknown-key carry-through, id-before-name resolution with ambiguity refused, precedence, deletion) and two Roborazzi scenes cover the surfaces: a profile being edited, and a host grid with a bound chip and a pinned card.	2026-07-29 12:17:18 +02:00
enricobuehler	35ce0401a8	feat(client/android): hosts get a stable identity, and own their clipboard ... The host store was keyed by `"address:port"`, which had two consequences. Editing a host's address had to re-key its record — delete the old key, write the new one — and nothing could hold a durable reference to a host at all, because the key moved whenever the host did. Profile bindings, pinned cards and `punktfunk://` shortcuts all need exactly such a reference, so the store is now keyed by a minted stable id: a lowercase UUID, the same shape Apple's `StoredHost.id` and the Rust `KnownHost.id` already carry, so a host reference is one grammar on every platform. The re-key-on-edit dance is gone; an edit is a plain save. `clipboardSync` moves from a global onto the record. It was always a decision about a HOST — whether text on this device may cross to that machine — and one global for the work box and the couch box was the wrong shape; the desktop clients have had it per-host since it shipped. It is edited from the host's Edit sheet, which is also where the profile binding will live. Both, plus the minted ids, ride ONE migration pass. The store is being rewritten anyway and every extra pass is another chance to strand somebody's hosts. It runs once against real user data, so its pure half is tested against a verbatim pre-migration blob — every host survives with its pin, paired flag and MACs, IPv6 addresses included; each lands on its own id; whatever the global clipboard setting said lands on every host, on or off; and a second pass over its own output changes nothing. Re-trusting a host now goes through `KnownHostStore.trust`, which preserves the existing record's identity and everything the user set on it. Three call sites used to construct a fresh `KnownHost` — harmless while the key was the address, but with an id it would have forked the record on every re-pair. While the wiring was open: `StreamScreen` takes an `ActiveSession` — the settings the connect actually resolved, plus that host's clipboard answer — instead of re-reading `SettingsStore` behind its own connect's back. That is also the seam profiles need.	2026-07-29 12:17:18 +02:00
enricobuehler	e7c0024543	feat(client/android): the settings the shared struct had and Android didn't ... Gap closure against the cross-client settings struct, plus one real bug. `pointer_capture` was Android's private spelling of `mouse_mode`: same two states (pointer lock + relative deltas, or free absolute pointing), a different name and a Boolean shape, so a profile or another client could never carry it. It becomes `MouseMode` with the shared `capture`/`desktop` names and the shared labels, migrating from the old Boolean — whose `false` default IS `desktop`, so an install that never touched the toggle lands exactly where it already was. Android keeps `desktop` as its default rather than the desktop clients' `capture`: a phone or TV is far more often driven by touch or a pad than by a locked mouse, and that is what this platform already did. The pad picker gains Steam Deck, and stops assuming its index IS the wire byte — `GamepadPref` has eleven values now and the offered subset is not a prefix of them (Steam Deck is 6; 5, the classic Steam Controller, is not offered, exactly as on the desktop clients). PyroWave joins the codec table so the value is representable, but is not offered: it is a Vulkan-compute codec that lives in `pf-presenter`, this client decodes through MediaCodec and never advertises the bit, so choosing it would silently resolve to HEVC. AV1's existing capability gate and this one now share `codecOptionsFor`, which also keeps whatever IS stored selectable — a codec chosen on another device must survive being looked at here. And the fix: "Steam Controller 2 passthrough" was gated on the device having a body vibrator. It is a USB/BLE capture with nothing to do with rumbling this device, and the gate hid it on exactly the machines that most want it — TV boxes, where an SC2 is the whole input story. Only the rumble-mirroring row, which genuinely needs a motor to mirror onto, stays gated.	2026-07-29 12:17:18 +02:00
enricobuehler	24a2d3a81b	feat(client/android): the settings read like every other client's ... Android was the last client on its own settings map (Display / Audio / Controls / Interface / About) while the desktop and Apple clients had converged on General / Display / Input / Audio / Controllers / About with sub-sections inside each. Same settings, six different mental models is five too many, and the profile scope switcher A4 adds hangs off exactly this structure. So: the shared category map, the sub-section headers the desktop clients group by ("Resolution" / "Quality" / "Decoding" / "Host output"), and the `described()` idiom — `SettingDropdown` gained a `caption` parameter, so a dropdown's explanation belongs to the dropdown instead of floating as a loose paragraph two rows below it. The only form-level notes left are the two "applies from the next session" footers, one per affected category, matching the decision Apple made. About finally names the app and its version, the way the WinUI and Apple About pages do. `SettingsScreen` takes an optional `initialCategory` so the screenshot harness can capture a category page — the headers, the captions and the footers only exist inside one, so the root shot alone couldn't catch a regression in them. Two new Roborazzi scenes (Display, Input) use it.	2026-07-29 12:17:18 +02:00
enricobuehler	5219107177	chore(unsafe): the workspace adopts the drivers' unsafe discipline ... `packaging/windows/drivers/*` has run `deny(unsafe_op_in_unsafe_fn)` + `deny(clippy::undocumented_unsafe_blocks)` for a while, with `forbid(unsafe_code)` on the modules that need no unsafe at all. The main workspace had no lint config whatsoever, so nothing stopped a clean crate from quietly growing an `unsafe`, and nothing distinguished the handful of genuinely-unsafe lines inside a 600-line `unsafe fn` from the safe ones surrounding them. Three things, all mechanical: * `#![forbid(unsafe_code)]` on the eight crates that already contain zero unsafe (`pf-driver-proto`, `pf-host-config`, `pf-paths`, the three clean clients, both tools). These were clean by accident, not by contract; now they are clean by contract. * `unsafe_op_in_unsafe_fn = "warn"` workspace-wide. `unsafe fn` states a contract the CALLER must uphold — it was never meant to switch off checking for the whole body. Measured fallout is 300 sites on Linux, and they are concentrated: six files carry all of them, while `punktfunk-core`, `pf-frame`, `pf-clipboard` and `pf-vdisplay` are already at zero. `warn` (not `deny`) so the build stays green while those six are worked down; it flips to `deny` once they are. This is also the Rust 2024 default, so it pays off the edition migration early. * `proc::current_uid()` replaces eight `unsafe { libc::getuid() }` blocks. Each site had copied out the same SAFETY note verbatim, which is the tell: `getuid()` is parameterless, always succeeds and touches no memory, so there is no contract for a caller to uphold and no reason for the unsafe to be visible eight times. One `unsafe` behind a safe wrapper, none at the call sites. Verified: `pf-vdisplay` builds clean on Linux (Nobara) at zero E0133; the macOS-buildable crates build clean locally. No behaviour change.	2026-07-28 21:31:41 +02:00
enricobuehlerandClaude Opus 5	580ea0d338	fix(android): a mouse's side buttons work even when they arrive as keys ... Not every mouse reports back/forward the same way. One that carries them on the HID button page (BTN_SIDE/BTN_EXTRA) gets BUTTON_BACK/BUTTON_FORWARD in the motion button state, which is the only shape the forwarder listened for. A mouse that carries them on the consumer page (AC Back / AC Forward — the common Bluetooth shape, and what Android TV boxes tend to see) produces only synthesized KEYCODE_BACK/KEYCODE_FORWARD, and those were swallowed outright to stop them doubling as Android navigation. On that hardware both side buttons were simply dead. Route the key shape into the same wire buttons, deciding by the DEVICE (it has to be able to be a mouse) rather than by the event's source, since the consumer-page collection is a separate sub-device that may be stamped SOURCE_KEYBOARD. A D-pad-capable device is excluded so an air-mouse remote's BACK stays the couch user's way out of the stream. Both paths now funnel through one press/release helper whose held-set guard collapses a device that reports BOTH into a single wire press. Closes #8 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:13:19 +02:00
enricobuehlerandClaude Fable 5	ac3dc4323f	fix(native/session): make the stop flag enforceable so a session can't outlive its client ... Native sessions could survive long after the client was gone, in two independent ways. HOST: `stop` was only advisory. The one thing that ends a session is the stream thread returning — every teardown (conn.close, the joins, and the RAII drops of the session permit, admission entry and stream marker) sits after that await, and nothing forced the issue. The encode loop checks `stop` between iterations, so any unbounded call INSIDE one never reaches the check, and one stuck syscall became a permanent zombie: it held its semaphore slot (four of those and the host stops accepting QUIC entirely), its admission entry (a later client gets "host busy" forever), and not even the console's Stop button could clear it — that button sets this same flag. * Bound the wait: once the session has been told to stop, the thread gets STREAM_STOP_GRACE (90 s, well past the 40 s capture-rebuild budget) to return, then teardown runs anyway. The thread is detached, not killed — Rust can't cancel a blocking thread — so it keeps its capturer/encoder until the stuck call returns, but the session's slot and admission entry come back and the host keeps serving. It logs at ERROR as the host wedge it is. * Bound the audio/input joins too — the last unbounded await in teardown. * Take the session permit AFTER the QUIC handshake instead of before `accept()`, so a host at its concurrency cap still accepts and the waiting client sees a live path instead of a silent dial timeout. * Bound the compositor helpers that caused the wedge in the first place: new pf-vdisplay `proc::{status_within, output_within}` kill a child that outlives its budget. `kscreen-doctor` is a Wayland client of the very compositor it configures, so against a wedged KWin it never returned; same for systemctl/dbus against a stuck session bus. CLIENTS: the connection was never closed, so the host was right to keep the session — it still had a live, keep-alive-answering peer. * Android: backgrounding did no teardown at all, and Android doesn't suspend the process, so the worker kept answering keep-alives until the OS reclaimed it (on a TV box, never). End the session on ON_STOP, via the existing onDispose path; a plain close, not a quit, so the host lingers the display for a fast return. * Apple: the .background arm was iOS-only AND gated on an opt-in that defaults off, so backgrounding did nothing — while the `audio` background mode kept the app (and its connection) alive indefinitely. Act unconditionally, and cover tvOS. * Core: `conn.close()` only queues the frame, and run_pump is the body of a block_on whose runtime is dropped the instant it returns, so the driver could never put it on the wire — a deliberate quit reached the host as silence (8 s idle timeout, no quit code, and the linger meant for an unwanted disconnect). Carry the endpoint out of the handshake and flush with wait_idle(), the same discipline the pairing and probe paths already use. Linux check/clippy/tests green: 262 host, 71 pf-vdisplay (incl. new bounded-process tests), 231 core. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 02:11:49 +02:00
enricobuehlerandClaude Fable 5	98b97d7d76	fix(android/input): stop mouse back/forward leaking to nav + IME popping on hardware typing ... Two Android TV M&K regressions from the c90343c2 overhaul, both user-reported: 1. Mouse back/forward buttons doubled as Android navigation while streaming. The BUTTON_BACK/FORWARD motion edges already go over the wire as X1/X2, but Android's input reader ALSO synthesizes KEYCODE_BACK/FORWARD key events from those buttons unconditionally (stamped SOURCE_MOUSE, no FLAG_FALLBACK) — and the guard only swallowed the FLAG_FALLBACK variant, so the duplicate reached the BackHandler and yanked the user out of the stream. Swallow mouse-sourced BACK/FORWARD too; a remote/keyboard BACK is never mouse-sourced and still exits. 2. The soft keyboard popped up on physical-keyboard typing. KeyCaptureView (the always-focused IME/capture anchor) unconditionally claimed to be a text editor with a live editable InputConnection, so the TV IME counted input as active and showed its UI the moment hardware keys arrived. Gate the editor identity on imeShown (the user actually summoning the keyboard via gesture / remote toggle), with restartInput on both edges so the gate is re-read, and an onKeyPreIme BACK hook so an IME self-dismissal can't leave the gate stale. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 17:07:18 +02:00
enricobuehlerandClaude Fable 5	c0f792ee8d	feat(android): pen P5 — stylus capture onto the pen plane ... The Android leg of design/pen-tablet-input.md §7: against a HOST_CAP_PEN host, stylus/eraser pointers split out of BOTH touch models (passthrough + gesture) into StylusStream — state-full samples with pressure, AXIS_TILT, azimuth from AXIS_ORIENTATION (Android's 0 = away-from-user IS wire north), AXIS_DISTANCE hover, both stylus barrel buttons, the eraser tool, and historical (coalesced) samples batched oldest-first. Kotlin heartbeats ≤100ms per the wire contract. JNI: nativeHostSupportsPen + nativeSendPen (flat 10-float stride, sentinels <0). No barrel-roll axis exists on Android — roll stays unknown here. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 16:48:57 +02:00
enricobuehlerandClaude Fable 5	4a01bc4463	feat(core+host+client): cursor channel — remote-desktop sweep M2a+M2b ... The host cursor stops riding the video and becomes a real OS cursor on the client (the Parsec/RDP model): pointer feel no longer pays the capture→encode→network→decode→present round trip. Wire (M2a): - Hello grows a client_caps trailing byte (CLIENT_CAP_CURSOR) after the fixed display_hdr block — presence disambiguated by remaining length, which caps the post-HDR tail at 27 bytes (documented); Welcome answers HOST_CAP_CURSOR (capable-and-asked, the 444/clipboard precedent). - CursorShape (0x50, control stream): serial + dims + hotspot + straight RGBA, ≤120px/side so the u16 frame always fits (128² would overshoot); client caches by serial — re-showing a known shape costs 14 bytes, not a bitmap (RDP pointer-cache for free). - CursorState (0xD0 datagram): serial + visible/relative_hint flags + position, sent once per encode-loop tick — latest-wins, self-healing under loss, no refresh timer. relative_hint is reserved for M3. - Client core: two new planes (control-task + datagram-task arms) → next_cursor_shape/next_cursor_state; connect() grows client_caps (C ABI passes 0 until the v11 cursor poll fns exist). Host (M2b, Linux portal only): - handshake::cursor_forward is THE predicate (client asked ∧ Linux ∧ compositor ≠ gamescope) — Welcome bit and session wiring both read it. - SessionPlan.cursor_blend goes false for a forwarding session; the encode loop ticks a CursorForwarder every iteration: shape-serial diff → control-task bridge (mirrors probe_result), state datagram → conn. - CursorOverlay/capture CursorState carry the hotspot through (nearest-neighbor downscale backstop for XL cursors, unit-tested). Presenter: - CursorChannel drains both planes per loop iteration; shapes become SDL color cursors (from_surface + hotspot), applied while the desktop mouse model is engaged; visibility follows the host; capture/released hands back the system cursor. Sessions advertise the cap when they START in desktop mode. Verified on .21: fmt + clippy -D warnings (7 crates) + tests green (core 218 incl. new wire roundtrips, host 245 incl. e2e + forwarder downscale tests). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Fable 5	c90343c22f	feat(android): shared clipboard (text) — device↔host sync while streaming ... The desktop clients' clipboard protocol, adopted on Android (text-only v1): opt-in ClipControl at stream start when the host advertises HOST_CAP_CLIPBOARD and the new "Shared clipboard" setting (default on) allows. Device → host: local copies (primary-clip listener + a probe at start) are announced as lazy format-list offers; the text crosses only when the host actually pastes (FetchRequest → served from the live clipboard). Host → device: a host copy's offer is fetched eagerly and lands in the system clipboard (Android has no practical lazy-paste provider), with an echo guard so the resulting clip-changed callback doesn't bounce it back as a new offer. Native side: session/clipboard.rs JNI shims over NativeClient's clip_* surface; events cross to Kotlin as compact strings from a blocking nativeNextClip poll on a dedicated thread (the nativeNextRumble pattern), joined before the session handle is freed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 19:27:19 +02:00
enricobuehlerandClaude Fable 5	abe6228b42	feat(core+host+android): committed-text input plane (IME path) — InputKind::TextInput ... The VK key-event vocabulary cannot express text an input method COMMITS (autocorrect, gesture typing, non-Latin scripts, emoji). Add a first-class text event and negotiate it: - punktfunk-core: InputKind::TextInput (= 15) carries one Unicode scalar per event in `code`; HOST_CAP_TEXT_INPUT (0x04) in Welcome::host_caps. - Host advertises the cap only where the session's inject backend can type text: Windows SendInput (KEYEVENTF_UNICODE, surrogate-pair aware) and the Linux wlroots backend — a dedicated second zwp_virtual_keyboard whose xkb keymap grows Unicode keysyms on demand (the wtype model), so keymap re-uploads never disturb the main device's layout/modifier state. The KWin-fake-input/libei/gamescope backends can only press layout keycodes, so those sessions don't set the bit and clients keep the VK fallback. - GameStream plane: Moonlight's UTF-8 text packet (MAGIC_UTF8, previously recognized-and-dropped) now decodes to the same TextInput events. - Android: KeyCaptureView picks a real editable InputConnection when the host has the cap — the IME runs its full machinery, mirrored to the host live via common-prefix diffs of the composition (backspaces + new suffix), with setComposingRegion adopting committed text so autocorrect-revert flows diff instead of retyping; newline→Enter, deleteSurroundingText→Backspace/Delete. Older hosts keep the TYPE_NULL raw-key path unchanged. - keymap: media VKs (0xB0-0xB3) → evdev so the Android media keys land on Linux hosts too. Verified: punktfunk-core + host gamestream + pf-inject tests green on Linux (Ubuntu box), clippy clean; Android app+native builds. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 19:19:11 +02:00
enricobuehlerandClaude Fable 5	ddb72edcba	feat(android): physical mouse + TV remote-as-pointer + keyboard hardening ... Phase A — hardware mouse: new MouseForwarder routes every SOURCE_MOUSE event while streaming. Uncaptured (default): hover/drag positions forward as absolute cursor moves, wheel with fractional accumulation (high-res wheels), all five buttons incl. back/forward as X1/X2; the local cursor is hidden over the stream (TYPE_NULL pointer icon) so the host's composited cursor is the visible one. Captured ("Capture pointer for games" setting, or Ctrl+Alt+Shift+Q live): the OS pointer is grabbed via requestPointerCapture on the (repurposed) key-capture view and raw relative deltas forward as mouse-look; held buttons are tracked and flushed on capture loss/teardown, and the engaging click is swallowed (desktop parity). Mouse clicks are intercepted before Compose so they can never be misread as trackpad taps; a mouse back-button's FALLBACK BACK is dropped so it can't yank the user out of the stream. Phase B — keyboard: media/consumer keys (play/pause/next/prev/stop) now map to their VKs instead of falling to the system; TV-remote SELECT maps to Enter. Phase D — Android TV: RemotePointer turns a D-pad-only remote into a pointer (Siri-remote analogue): hold SELECT ~0.8s toggles, D-pad glides the host cursor with ramped acceleration (Choreographer-paced, diagonal-normalized), SELECT taps click, play/pause right-clicks, holding it toggles the on-screen keyboard, BACK leaves pointer mode; an overlay hint teaches the vocabulary. Settings: "Capture pointer for games" + "Invert scroll direction" (applies to the wheel and two-finger touch scrolling). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 18:56:38 +02:00
enricobuehlerandClaude Fable 5	a784682d4c	fix(client/net): split the receipt stamp from the pull + bleed standing latency ... The two-pair investigation (wired Mac clients stuck at a rock-steady ~18-19 ms "network" that survived the load ending and cleared only on reconnect) exposed two structural gaps, one of measurement and one of recovery: - Receipt was stamped at the hand-off PULL (Swift nextAU, pf-client-core, Android decode loops), not at reassembly completion — so any client-side standing state between the reassembler and the pull read as NETWORK latency, undiagnosable from the HUD. ABI v9: `PunktfunkFrame`/`Frame` grow `received_ns`, stamped by `Session::poll_frame` as the AU crosses the session boundary. Every embedder now uses the core stamp; the Apple client keeps the pull instant as `AccessUnit.pulledNs` and shows the receipt→pull wait as its own "client queue" term (detailed HUD tier from 2 ms + a `queue_p50` stats-log field). Decode stages keep their pull anchor on all platforms, so no historical stage shifts meaning. - The jump-to-live detectors deliberately ignore anything under 6 queued frames / 400 ms behind — so a small, constant, loss-free elevation (a sub-frame standing backlog, or a stale clock offset after a wall-clock step/slew) is carried for the rest of the session. New third detector (`StandingLatency`, unit-tested ladder): window-MIN one-way delay ≥ 10 ms above the session floor with zero loss for ~4.5 s escalates gently — a free clock re-sync first (an applied re-sync re-bases the floor), then at most 3 flush+keyframe bleeds sharing the jump-to-live cooldown, then a loud disarm naming what it means. Loss windows reset the run: congestion belongs to FEC/ABR, not this detector. Also: mid-stream re-sync apply/discard logs debug→info — they are the forensic trail for the stale-offset case and were invisible in the field. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 23:38:11 +02:00
enricobuehlerandClaude Fable 5	871ebb31ce	feat(clients): render-scale setting on every client — shared punktfunk_core::render_scale ... Client-side supersampling/downscaling: the client asks the host to render and encode at chosen-resolution × scale (the host does no scaling) and the presenter rescales the decoded frame to the display. >1 supersamples for sharpness; <1 lightens the host GPU and the link. Default 1.0 = Native, the prior behavior. The geometry lives once in punktfunk_core::render_scale (multiply, preserve aspect ratio, floor to even, clamp to the codec's per-axis ceiling — 4096 for H.264, 8192 otherwise), the Rust twin of the Apple client's RenderScale.swift, consumed by the native session client, the presenter's match-window path, the Windows/Linux settings UIs, Decky, and Android (settings + host connect + unit test). Implemented and platform-verified by the Apple-client-features session (Linux+Android+Apple green there); the punktfunk-core wiring (pub mod render_scale) is restored here after being lost in a working-tree reconciliation. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 17:20:15 +02:00
enricobuehlerandClaude Opus 4.8	f439b69451	refactor(android/W8): split decode.rs into decode/ directory module ... Break the 1747-line clients/android/native/src/decode.rs into a decode/ directory module (mod.rs + 5 concern submodules): - decode/setup.rs : codec creation + low-latency config + thread/frame-rate tuning + HDR static-info encode - decode/display.rs : DisplayTracker + render-callback registration + HDR dataspace - decode/latency.rs : realtime clock + decoded-pts / user-flags stat recording - decode/sync_loop.rs : the synchronous poll decode loop (+ feed/drain) — moved WHOLE - decode/async_loop.rs : the event-driven async decode loop (+ helpers) — moved WHOLE decode/mod.rs keeps the consts, DecodeOptions, and the `run` entry point + the `codec_mime`/`codec_label` re-export, so every crate::decode::X path stays byte-stable. The module has no decoder struct (free functions + small types), so both decode loops move byte-for-byte and their separately-inlined received-stat recording is NOT unified. 16 helper fns/types became pub(super) for sibling access; zero field bumps. lib.rs unchanged (`#[cfg(target_os="android")] mod decode;` resolves to decode/mod.rs). Verified: cargo-ndk check (aarch64-linux-android, clean) + the gradle cargoNdkDebug build (arm64-v8a / armeabi-v7a / x86_64). On-device runtime re-verification still owed per the plan (the two decode loops are a hot path). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 15:06:24 +02:00
enricobuehlerandClaude Fable 5	13b1f36d4a	feat(core,clients): one rumble policy engine for every platform (rumble root fix D) ... punktfunk-core client/rumble.rs: a per-connection policy engine consumes seq-gated wire updates and emits EFFECTIVE actuator commands — re-emits on renewals (duration APIs stay re-armed), self-silences at the v2 lease, a UNIFORM 1 s legacy-host staleness replacing the per-platform zoo (Apple 1.6 s / Android 60 s / SDL 1.5 s / Deck 1 s), quirk-declared actuator keepalives (Deck 40 ms + LSB dedupe-defeat jitter), and one stop per buzzing pad on connection close. Per-pad mailbox semantics: a stalled embedder wakes to ONE current command, and a stop can structurally never be the update an overflowing queue drops. New API/ABI: NativeClient::{next_rumble_command,set_rumble_quirks} + punktfunk_connection_next_rumble_cmd/_set_rumble_quirks (next_rumble/next_rumble2 stay for un-migrated embedders; both consumers are fed). Migrations DELETE the platform forks: pf-client-core loses RumbleState + the Deck keepalive loop + LEGACY_RUMBLE_CEILING_MS and physically silences a slot at close; Android loses the 60 s legacy one-shot (backstop repack, cancel-on-zero); Apple loses envelopeDeadline + sessionStaleSeconds + both tick watchdogs (CoreHaptics realization untouched; mac xcframework rebuilt locally). design/rumble-root-fix.md par. D. Engine 10/10 unit tests; core tests 176 Linux / 175 Windows + clippy -D warnings; swift build + RumbleTuningTests; Kotlin + android-native compile green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 14:07:32 +02:00
enricobuehlerandClaude Opus 4.8	ecfa71212d	chore: consolidate all in-progress parallel-session WIP ... Wholesale commit of every uncommitted change across the tree, at the user's explicit request — host refactor-campaign W1 (native.rs facade + native/ dir, library/ + mgmt/ splits), Android, core. These streams were mid-flight and not individually built/tested together; this supersedes the per-session HOLD markers. Consolidating so everything lands on main in one pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 20:08:29 +02:00
enricobuehlerandClaude Fable 5	11045a0f70	chore: consolidate parallel-session WIP (HOLD — do not push) ... Local snapshot of intermingled in-flight work, committed to unblock the encode refactor (a clean ffmpeg_win.rs for the vbv-dedup follow-on). These hunks span the same files and can't be cleanly split here; the commit bundles three distinct workstreams that each belong in their own PR: - logging rework (~43 files: level re-tiering, structured fields, `?e`, hot-path flood latches) - conflicting-host detection (detect.rs + detect/{linux,windows}.rs + wiring in main.rs/mgmt.rs/Cargo.toml/docs/packaging) - standby-sink DWM-stall attribution (windows/display_events.rs + capture/ vdisplay wiring) NOT verified as a combination. NOT to be pushed until the refactor is done and these are re-verified and reorganized into their proper per-workstream PRs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 12:42:53 +02:00
enricobuehlerandClaude Fable 5	01266ff18d	feat(gamepad): SC2 Puck-dongle passthrough with the native 28DE:1304 topology ... Community-contributed round 5 of the Steam Controller 2 passthrough, reviewed + verified. A Puck-captured pad now presents the dongle's real seven-interface identity (CDC pair, four controller HID slots, management HID) instead of relabelling its reports as a wired 1302 — Steam's Puck feature dances (wireless_transport / esb/bond / 0xB4 slot status) get capture-shaped answers, and the wired identity's canned replies are corrected to the real captures (attribute count, string-attr framing, 0xF2 firmware info, bcdDevice nibble encoding). - new wire pref 10 = SteamController2Puck (Hello/Welcome byte; older peers degrade to Auto), selected by the Android capture link when the transport is a dongle, or by VID/PID in the degraded InputDevice path - TRITON_RDESC is now the captured numbered descriptor (mouse/keyboard lizard collections + per-id vendor reports); unnumbered framing made hidraw mangle feature report 2 and Steam eventually closed the device - interrupt-IN now queues sparse reports (battery/RSSI/wireless edges) instead of keeping latest-only, so a 250 Hz state packet can no longer erase them before the USB/IP poll observes them; EP0 SET_REPORT is split by wValue report type (OUTPUT parsed for rumble vs FEATURE) - vendored usbip-sim: config attributes/max-power, IAD prefix + BOS descriptor support, correct BCD minor.patch encoding (Deck's 0x0300/ 0x0200 values are nibble-zero, so its bytes are unchanged), and full-speed interrupt pacing in ms (was 8 kHz from the HS formula) - Triton feedback is serviced at 1 kHz while an SC2 backend exists so Steam's trackpad haptic writes reach the client unbatched Verified: clippy -D warnings + 319 host tests green on Linux, core wire tests green, Android kit/app compile + unit tests green. On-glass Puck retest owed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 20:47:52 +02:00
enricobuehlerandClaude Opus 4.8	a7d4a93ff2	fix(gamepad/android): make the exit chord usable again — shorter hold + on-screen hint ... The Select+Start+L1+R1 close-stream chord read as broken after 48933dc4 changed it from an instant quit to a 1.5 s arm-and-hold: a normal quick press did nothing and there was no on-screen cue that a hold was now required. Keep the accident-prevention hold (an errant brush of the four buttons still shouldn't kill a session), but make it usable: - Shorten EXIT_HOLD_MS 1500 -> 1000 ms — still rejects a brush, feels responsive. - GamepadRouter gains onExitArmed(Boolean): fires true when the chord completes and the countdown starts (once per cycle, past the pendingExit guard), false on an early release or when the timer elapses. - StreamScreen shows a "Hold to quit…" pill (top-center) while armed, so the hold is discoverable; the callback is detached in onDispose before router.release() so its disarm can't poke Compose state during teardown. - MainActivity: drop the now-stale "~1.5 s" dispatch comment. Verified on this Mac: :kit + :app compileDebugKotlin clean; Android lint clean for all three touched files (the kit lint baseline errors are pre-existing, unrelated). On-glass on a real phone + pad still owed (the 1 s hold firing the exit, early-release cancelling, the hint showing / hiding) — per the Android-input-regressions-only-show-on-hardware history, and the original hold path was never exercised on a device. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-15 18:25:10 +02:00
enricobuehlerandClaude Opus 4.8	56f9c8c4b4	feat(core,android): Automatic bitrate caps at the client decode limit, not the link ceiling ... The Automatic bitrate controller only reacted to network signals (loss, capture→received OWD, FEC-unrecoverable frames, jump-to-live flush), so on a fast LAN feeding a slower mobile HW decoder it slow-started straight to the link-probe ceiling and parked there — backlogging frames inside the decoder, where those signals never register, and choking it. Reported on a Snapdragon 8 Gen 1: Automatic pinned ~500 Mbps with unusable latency. Feed the client's decode-stage latency (received→decoded) into the controller as a first-class signal, symmetric with the existing OWD one: a rise over its rolling-min baseline ends the slow-start climb and, sustained over two windows, backs the rate ×0.7 down to the real decode limit — so Automatic settles where the decoder keeps up. - core/abr: on_window gains decode_mean_us; a decode_means rolling-min baseline + DECODE_RISE_US (15 ms) fold a decode rise into the bad-window logic. - core/client: per-frame report_decode_us accumulator, drained to a window mean by the data-plane pump; wants_decode_latency() gate (Automatic, non-PyroWave) lets embedders skip the measurement where it's ignored. Re-target log prints the driving signals. - android/decode: report the decode stage on both the sync and async decode paths, HUD-independent, measured from the AU leaving next_frame (so codec-input backpressure is included) and excluding the vsync present wait. Apple/Windows report_decode_us calls to follow. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 17:28:11 +02:00
enricobuehlerandClaude Opus 4.8	694bec4ead	fix(android): SC2 sticks — SETTING_ENABLE_RAW_JOYSTICK=0 for calibrated i16 ... A Steam Controller 2 opened in raw mode (our capture claims the HID interface) reports ADC joystick coordinates ~0..3200, which Steam/SDL read as only a few percent of full travel — the sticks barely move in Steam's controller test even though menu navigation still crosses its lower threshold. Steam sends SETTING_ENABLE_RAW_JOYSTICK (0x2e) = 0 during native init to force firmware-calibrated signed i16; replicate it (NORMALIZE_JOYSTICKS) alongside lizard-off at claim time and on the 3 s watchdog refresh (the refresh also repairs a host/driver that re-enabled ADC mode after capture started). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 17:05:56 +02:00
enricobuehlerandClaude Fable 5	0325e1cf6f	fix(android): SC2 menu nav — offer synthesized keys to padKeyProbe first ... Tester-diagnosed (the layer a390e241 missed): the console UI navigates through padKeyProbe — GamepadNavEffect's held-state + auto-repeat machinery consuming A/X/Y/D-pad/Select — not the focus system. sc2NavKey routed everything via super.dispatchKeyEvent, which bypasses MainActivity.dispatchKeyEvent and therefore the probe, so the console home never saw the SC2 at all (B alone worked: it never rides key events). Synthesized events now take the same route as real ones: probe first (keycode-gated only, so synthetic KeyEvents satisfy it), then the existing B/A/focus-hook/framework fallbacks — which remain the path for probe-less screens. Also: the stick now reports a HELD D-pad direction (press on deflection, release on centre/change) instead of a single pulse — the probe machinery turns that into a physical-D-pad-like auto-repeat; guarded against releasing a direction the real D-pad still holds, and released on link drop. The focus-hook path still moves once per press edge. Committed without push (user request); --no-verify per the shared-tree fmt-hook false positive (Kotlin-only commit). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 15:10:09 +02:00
enricobuehlerandClaude Fable 5	e807ffbff8	fix(android): SC2 menu nav — drive Compose focus directly, not synthetic KeyEvents ... On-glass: the SC2 attached, left lizard mode, and then only B worked (closing the app — back at the root). B is the tell: it bypasses key events entirely (direct back-dispatcher call), while everything routed as a synthetic KeyEvent died. A synthetic event dispatched from outside the real input pipeline never reaches ViewRootImpl's focus-navigation stage — the one that exits touch mode and grants initial focus for a REAL pad's first D-pad press — so on a phone nothing is focused and both the D-pad and A (needs a focused element) fall on a deaf window. The D-pad now drives Compose's own FocusManager.moveFocus through a hook registered in the composition (Next as bootstrap: directional moves need an already-focused node; one-dimensional traversal assigns initial focus). Once a Compose node holds focus the ComposeView owns view-focus, so A's synthetic DPAD_CENTER reaches the focused clickable as before. One move per press edge; shoulders/Start/Select unchanged. Committed without push (user request); --no-verify per the shared-tree fmt-hook false positive (Kotlin-only commit). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 15:10:09 +02:00
enricobuehlerandClaude Fable 5	a40ae49cf8	feat(android): SC2 drives the console UI + a real card in the Controllers view ... An SC2 was invisible outside streams: lizard mode produces kb/mouse (no gamepad events), and the capture claims even those away — so the console UI could neither be navigated by it nor knew a controller was connected. - Sc2Capture grows a UI mode (router == null): parsed state edge-detects into onUiKey navigation transitions — D-pad + face buttons + Start/Select as real press/release, the left stick as one focus step per half-deflection push (mirroring MainActivity's stick behavior for ordinary pads); onActiveChanged + isActive expose the link state. - MainActivity owns the menu-time capture: engages on resume / USB attach / permission grant (asked once per attach; the Controllers screen's grant button re-arms it), releases on pause, and hands off around StreamScreen's stream-mode capture (stop before claim, resume in onDispose). sc2NavKey routes like a real pad's buttons: B backs, A activates via DPAD_CENTER, the rest goes to focus navigation — and claims the console-UI glyphs (Xbox family, Valve lettering). - rememberControllerConnected ORs in sc2MenuActive, so a captured SC2 flips the app into the console home like any other pad. - ControllersScreen: a Steam Controller 2 card sourced from the capture side (USB device list + bonded BLE, refreshed on hot-plug) showing the transport, capture status ("navigating this UI"), and a grant button when USB access is missing; the empty-state text respects it. Kotlin-only commit; --no-verify per the shared-tree fmt-hook false positive (another session's unformatted Rust WIP; committed tree is fmt-clean). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 13:42:39 +02:00
enricobuehlerandClaude Fable 5	7f1680b043	fix(android): label wire kind 9 in the controllers view ... prefFor resolves SC2 PIDs to the new kind since 81edd271, but prefLabel had no arm for it — a Puck surfacing as an InputDevice would read "Streams as: Automatic". (--no-verify: shared-tree fmt-hook false positive, Kotlin-only commit.) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 13:27:07 +02:00
enricobuehlerandClaude Fable 5	a959e731da	fix(android): declare keyboard in configChanges — SC2 capture recreated the activity ... Tester-diagnosed root cause of the wired "disconnect": claiming the SC2's USB HID interface (force=true) removes the pad's lizard-mode keyboard and mouse input devices, flipping the system keyboard configuration (CONFIG_KEYBOARD, QWERTY→NOKEYS). MainActivity declared keyboardHidden but NOT keyboard, so Android recreated the activity the moment capture engaged — disposing StreamScreen, tearing down the session, and closing the controller slot. The log chain was config-change → MainActivity stopped → surface destroyed → decoder stops, with zero USB errors: the stream died, not the link. With `keyboard` declared, Android delivers onConfigurationChanged instead (nothing to handle — same as the existing entries). Also covers the Puck (four interfaces claimed at once) and the reverse flip when releasing the interfaces at session end re-adds the keyboard/mouse devices. Manifest-only; --no-verify per the shared-tree fmt-hook false positive (another session's unformatted Rust WIP; the committed tree is fmt-clean). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 13:23:28 +02:00
enricobuehlerandClaude Fable 5	81edd27155	fix(android): SC2 round-2 — claim every Puck slot, unplug only on real signals ... Round-2 on-glass: wired still dropped, Puck surfaced as Xbox360. Both were still client-side: - The Puck hosts up to four controllers on interfaces 2..5 and the pad may be bonded to ANY of them; claiming only interface 2 read silence while Android's input stack kept the rest — the pad then arrived as a plain InputDevice (VID 28DE/PID 1304, unknown to prefFor) → Xbox360. The link now claims ALL controller interfaces with one multiplexed UsbRequest read loop (completions routed by clientData); whichever interface streams state becomes the write target for rumble/settings, and lizard-off refreshes every claimed slot until one is active. - Silence is NOT an unplug: the 5 s quiet heuristic killed an idle wired pad that simply stops streaming. Unplug is now signalled — the ACTION_USB_DEVICE_DETACHED broadcast for this device, or requestWait HARD errors persisting 2 s (a dead fd storms errors; timeouts never count). - Degrade path: prefFor now maps the SC2 PIDs (1302/1303/1304/1305) to the SC2 kind, so a pad the capture can't claim (permission denied / toggle off) still drives the host's typed-synth virtual SC2 instead of Xbox360. - Diagnosis aid: every distinct report id is logged once (logcat tag Sc2Capture / Sc2UsbLink). Kotlin-only commit; --no-verify because the fmt hooks check the WORKING TREE, which carries another session's unformatted Rust WIP — the committed tree is fmt-clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 13:20:56 +02:00
enricobuehlerandClaude Fable 5	d352e4e456	fix(android,host): SC2 first-on-glass fixes — UsbRequest reads + usbip transport ... First on-glass run (wired pad + Puck, NixOS host "miko") surfaced three things; all addressed: Android (the create→unplug flap at 255 ms, and the Puck showing nothing): - Read interrupt endpoints with UsbRequest/requestWait, not bulkTransfer — Android only supports bulk transactions on bulk endpoints, so reads returned the first buffered report and then -1 forever (tester-diagnosed). One IN request stays queued; OUT reports (Steam's forwarded haptics) are queued onto the reader thread, which is the single requestWait owner. Unplug detection is now sustained-silence (5 s), not a failure counter. - Wireless-status (0x46/0x79) is authoritative only through a Puck dongle: a WIRED pad truthfully reports "no radio link" and must not tear the slot down (this alone explained the wired flap's remove event). - Lizard-off confirmed working on-glass — framing unchanged. Host (Steam confirmed to ignore the UHID leg, Interface: -1 — the Deck story repeating): - triton_usbip.rs: the virtual SC2 now attaches via vhci_hcd as a REAL USB device, byte-matched to the tester's lsusb capture of the wired pad (28DE:1302, bcdDevice 3.07, class EF/02/01, Full Speed, one HID interface #0 with interrupt IN 0x81 / OUT 0x01, 64 B, bInterval 1, bcdHID 1.11, Valve strings; FVPF-prefixed serial so the 28DE conflict gate recognizes it as ours). Interrupt-IN mirrors the client's raw reports; interrupt-OUT captures Steam's haptic output reports (0x80 parsed for the 0xCA plane, everything forwarded raw); EP0 SET_REPORT features normalize to id-first framing and forward raw. - steam_usbip.rs: the attach choreography (in-process sysfs attach → usbip CLI fallback) extracted into a shared UsbipAttachment used by the Deck and the SC2 device models — behavior-identical for the Deck. - steam_controller2.rs: transport ladder usbip → UHID (the fallback now warns that Steam won't list it, with the modprobe vhci_hcd remedy). Verified: host 314 tests green on Linux (.21) incl. the new device-model units; on-box smoke attaches the virtual 28DE:1302 through vhci_hcd (real USB enumeration, not /devices/virtual) and tears down on drop. Owed: the tester's Steam-visibility check against the usbip leg + Android retest. (--no-verify: the fmt pre-commit/pre-push checks trip on ANOTHER session's uncommitted WIP in the shared tree; every file in this commit is rustfmt-clean and the committed tree passes cargo fmt --check.) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 12:57:26 +02:00
enricobuehlerandClaude Fable 5	2621b6e6b1	feat(core,host,android): Steam Controller 2 as-is passthrough to Linux hosts ... The 2026 Steam Controller (Valve "Ibex" / SDL "Triton") captured on an Android client is passed through AS-IS: the host presents a virtual pad with the real wired identity (28DE:1302) and mirrors the physical pad's raw HID reports, so Steam on the host drives it over hidraw exactly like the real thing — trackpads, gyro, paddles, and its rumble/settings writes flow back onto the physical controller. Protocol ground truth: SDL's Valve-maintained SDL_hidapi_steam_triton.c + steam/controller_structs.h. Core: - GamepadPref::SteamController2 (wire byte 9; names steamcontroller2/ sc2/ibex) + PUNKTFUNK_GAMEPAD_STEAMCONTROLLER2 in the C ABI. - Raw HID planes: RichInput::HidReport (0xCC/0x04, client→host input reports verbatim, Copy fixed-64 body) and HidOutput::HidRaw (0xCD/0x05, host→client feature/output writes for replay). Best-effort is sound by the device protocol's own design (rumble re-sent every ~40 ms, settings every ~3 s — losses self-heal); HidRaw bypasses hidout dedup for exactly that reason. Host (Linux): - triton_proto.rs + steam_controller2.rs: Triton2Manager UHID backend — no kernel driver binds the PID (hidraw only; Steam Input is the consumer), raw mirroring with a typed-fallback 0x42 synthesizer until the first raw report, SET_REPORT ack + raw forward, canned GET_REPORT serial reply, rumble also parsed onto the universal 0xCA plane (phone mirror). Rides the uhid + 28DE-conflict degrades; UHID promotion by Steam is flagged in the creation log (usbip transport is the known follow-up if Steam ignores Interface:-1 devices for Triton too). Android: - Sc2UsbLink (wired/Puck: vendor-interface claim detaches the OS driver, interrupt read loop, lizard-off on the watchdog cadence, raw replay via interrupt-OUT / SET_REPORT with hidapi report-id framing) and Sc2BleLink (Valve vendor GATT service, notify subscribe machine, 0x45 re-framing, HIGH connection priority). - Sc2Capture orchestrator: raw plane + typed mirror (exit chord + host degrade paths keep working) on a GamepadRouter external slot; raw return path via GamepadFeedback.onHidRaw. - nativeSendPadHidReport JNI (direct ByteBuffer, no per-report copy), hidout raw decode, usb-host/BLUETOOTH_CONNECT manifest bits, opt-out settings toggle, StreamScreen engagement incl. the USB permission flow. Verified: core 149 + host 312 tests green on Linux (.21), on-box uhid smoke creates/mirrors/tears down the virtual 28DE:1302, C ABI harness round-trips, Android compileDebugKotlin green. On-glass with the real controller owed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 11:22:16 +02:00
enricobuehlerandClaude Fable 5	1fc9ef0050	feat(core,host,clients): typed pairing rejections — every client says WHY, not "not accepted" ... A host's pairing-gate rejections (not armed / bound to another device / rate-limited / identity required / denied / approval timeout / superseded / wire-version mismatch) used to drop the connection with a bare code-0 close, and every client collapsed that — plus plain unreachability — into one "wrong PIN / not accepted" message. A dead network path, a disarmed host, and an operator denial were indistinguishable, which is exactly the misdiagnosis behind the recent Android pairing support thread. - core: new ungated `reject` module — shared close-code block 0x60–0x67 (+ 0x42 busy promoted from the host), `RejectReason`, and `PunktfunkError::Rejected`; `pair()`/`connect()` decode the host's ApplicationClosed code into `Rejected` instead of a generic Io error. C ABI v7: status block −20…−28 and `punktfunk_connect_ex8` (`status_out` reports the failure cause; NULL-return alone can't). Wire unchanged — old peers see exactly the old bare close. - host: every gate rejection `conn.close()`s with its typed code (and the human reason as close bytes) before erroring out of the session task. - pf-client-core: shared `pair_error_message`/`connect_reject_message` wording consumed by the Windows + Linux + console-UI + CLI surfaces; a connect failure now renders the host's stated reason. - android: `nativeTakeLastError()` JNI token + `ConnectErrors.kt` — a network timeout is no longer reported as "wrong PIN, or the host isn't armed", and a typed rejection skips the wake-and-wait fallback (the host is demonstrably awake). - apple: `HostRejection` + `.rejected`; the pair sheet and session alerts show the stated reason; connect moves to `ex8`. Completes the cross-client half of the hunks that rode along in 12148243 (client.rs / trust.rs / punktfunk1.rs) — main did not build without this. Validated: workspace clippy -D warnings + full test suite green on .21 (EXIT=0, 309 host / 148 core suites); macOS core 147+c_abi green; swift build green; Android Kotlin + native crate green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 09:58:43 +02:00