476 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	bf98102714	feat(packaging): ship punktfunk everywhere, and deprecate the session's stray pairing flag ... The rest of C1. A CLI that only exists in a dev tree is not a door anyone can use, so it now builds and installs in deb, rpm, arch, nix, flatpak and MSIX alongside the client and the session. On Windows it gets its own `AppListEntry="none"` application with the alias `punktfunk.exe` — a command, not a Start-menu tile — which is what the Playnite importer will shell to for `punktfunk library <host> --json`. `punktfunk-session --pair` prints a deprecation notice and forwards. Pairing is a trust ceremony and belongs to the brain, fronted by `punktfunk pair` or a shell; a renderer owning one is precisely the mixing of concerns this split exists to undo. It keeps working for a release, because someone's provisioning script is calling it today. Decky's invocations are untouched and verified still working (`--list-hosts` JSON shape unchanged, `--reachable` exit codes unchanged): those flags are a frozen compat contract until Decky migrates to the verbs at its own pace. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 01:16:17 +02:00
enricobuehlerandClaude Opus 5	f32c3aaa71	feat(session): spec mode — the renderer stops resolving policy and stops writing settings ... C2 of design/client-architecture-split.md, and the last of the session's overreach. `--resolved-spec <path>` hands the session everything it needs already resolved — effective settings, the host's clipboard decision, the profile's name — and in that mode it performs ZERO store reads. It had been re-deriving all three, which meant policy was being evaluated inside the thing that draws pixels, and that the spawner and the child could disagree about a file either of them might have written in between. First-party spawns (the shells, the CLI) always pass one now. The compat path stays for hand-run `punktfunk-session --connect` and old Decky scripts — but it calls the SAME helper, so the two modes cannot drift; it is the identical function invoked in-process instead of by the parent. A spec that is named but unreadable fails loudly rather than quietly falling back: a spawner that asked for exact settings must not get store-derived ones instead. The match-window write-back is gone too. The callback used to load-modify-save the shared settings file from inside the renderer — one of that file's five concurrent writers, for a value only the parent needs. It now reports `{"window":{w,h}}` on stdout and the spawner persists it, on a real change only. A hand-run session still persists its own window, because nobody is listening to its stdout there and the event alone would drop the value. Verified on .21: a spec naming a profile that doesn't exist in the catalog is honoured (proving no lookup happened), a missing spec errors instead of falling back, and the CLI's spec file is written and cleaned up per launch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 01:16:17 +02:00
enricobuehlerandClaude Opus 5	0594056e02	feat(cli): punktfunk — one headless front-end over the brain ... C1 of design/client-architecture-split.md. There were four overlapping, none-complete CLIs: the Linux shell's rich headless verbs, the Windows shell's near-none (it could not start a stream at all), the session's own, and punktfunk-probe's diagnostics. This is the one a script or a plugin should reach for, and it is a FRONT-END, not the brain — policy stays in `pf-client-core` and the GUI shells keep calling it in-process. Shelling out for connects would have traded duplicated code for a duplicated IPC protocol. punktfunk pair | hosts list/add/forget | wake | library | launch | open reachable | speed-test | profiles list | reset Because it runs the same plan builder and the same wake machine as a card click, `launch` and `open` WAKE A SLEEPING HOST — which the Linux shell's exec-style `--connect` never did; it fired a packet at best and dialled into the void. Host references resolve through the shared `resolve_host`, so `punktfunk launch desk` and `punktfunk://connect/desk` cannot disagree about which box "desk" is. Exit codes extend the session's contract so a consumer can branch without parsing prose: 0 ok, 2 connect, 3 trust, 4 renderer, 5 nothing matched what you named, 6 refused because it needs a person. That last one is why `pair` and `reset` check for a terminal before prompting — a CLI that blocks a CI job on a hidden question is a hang, not a UX. Two deliberate non-features. `speed-test` measures and prints but does NOT apply: which layer a bitrate belongs in is a decision the GUI makes with the user (global vs the bound profile), and a CLI silently rewriting a profile is exactly the surprise that rule exists to prevent. And `open` refuses an unknown host rather than pairing it — a URL may never pair or trust on its own, at any surface. `library` keeps TSV as its default output because that is what Decky's consumer parses; `--json` is the door for tools, and the Playnite importer shells to exactly that. The existing shell flags are untouched: they are a frozen compat contract until Decky migrates. Verified on .21 against hand-authored stores: hosts list (TSV and JSON, with each host's resolved profile and pins), profiles list, a launch honouring the binding ("Game"), a one-off overriding it ("Work"), the same through `open` with `profile=`, and the refusal codes (6 for an unknown host, 5 for `punktfunk://pair/...`). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 01:16:17 +02:00
enricobuehlerandClaude Opus 5	c27065c260	feat(client/windows): punktfunk:// opens the Windows client, and cards can write a shortcut ... WP4 / D2. Protocol activation of a full-trust packaged app delivers the URI as the command line, so a browser prompt, `start punktfunk://…` and a written `.lnk` all arrive the same way — as a positional argument, the same door the Linux shell uses. What Windows does not give us is single-instancing: unlike GApplication, a second activation is simply a second process. So the first instance claims the named mutex `unom.punktfunk.client` and any later one hands its URL to the winner over `WM_COPYDATA` and exits — one window, and the link opens where the user's hosts already are. The hand-off retries while the primary's window is still coming up (a shortcut double-clicked during startup is the ordinary case), and a hand-off that finds nobody falls through so this process becomes the shell that opens it. A link is never silently dropped, which is also why the inbox is a queue: two shortcuts in quick succession are two links. Routing is the same four lines of translation as on Linux, because the decisions belong to `plan_from_link`: a resolved link becomes the call a tile click makes, with the same wake, trust and error surfaces. Never preempting a live session is checked here, since only this layer knows one is running. The manifest declares the protocol and an app execution alias rather than writing registry keys, so uninstall leaves nothing behind — and Windows' own "allow this app to handle punktfunk links?" prompt is the origin friction the design wants, not duplicated in-app. (Manifest comments are free of double hyphens: XML forbids them and makepri rejects the whole file, which is how the console flag broke the v0.15.0 build. A test parses the substituted manifest and asserts both declarations, so that can't rot silently.) "Create shortcut…" writes a `.lnk` targeting the ALIAS with the URL as an argument, not a `.url` internet shortcut: both work while the scheme is registered, only this one still works if it isn't, and targeting the alias keeps it valid across updates when the package path changes. Verified on the CI VM (192.168.1.133): clippy -D warnings clean and its tests green. Not yet exercised on glass — `start punktfunk://…` cold and with the app running, and a written shortcut, still want a real desktop session. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 00:49:56 +02:00
enricobuehlerandClaude Opus 5	f5de661c9e	feat(client/windows): overridden rows are marked and resettable, and the speed test targets the right layer ... The two remaining pieces of P1 on Windows, both closing the same kind of gap the Linux client closed earlier. Overridden rows in profile scope now say so — an accent-marked caption — and carry the only way back to inheriting. Without it a profile is a one-way door here too, because overrides are recorded on touch and never inferred from comparing values. Reset calls the shared `SettingsOverlay::clear`, so the list of what can be cleared stays in one place across both shells. It also bumps a revision counter: the catalog changes behind the controls and nothing the page reads as state does, and root state compares before re-rendering, so without the bump the row would keep showing the value it just dropped. The speed test writes to the layer the TESTED host reads bitrate from, not the global — measuring one host used to re-tune every other one. Resolved exactly the way a connect resolves it: the one-off the test was started with (a pinned tile carries one), else the host's binding, else the global; a dangling binding falls back. The button names its target, so it says where it will write before you press it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 00:21:13 +02:00
enricobuehlerandClaude Opus 5	3d25482469	feat(client/windows): pinned host+profile tiles render in the grid ... The menu could pin since the last commit but nothing appeared, which is worse than not offering it. Each host's pins now render right after it, sharing its live status because they read the same record, with the profile named on an accent chip. A pin whose profile was deleted simply doesn't render. A pinned tile carries no menu of its own: it is a shortcut, not a second host, and pin/unpin already live on the primary tile's menu — the one place you decide it. Its hover key is `<fp>#<profile-id>` so two tiles for one host don't light up together. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 00:18:12 +02:00
enricobuehlerandClaude Opus 5	2a088e13a4	feat(client/windows): bind a host to a profile, connect with one, pin one, copy its link ... The WinUI half of §5.2: `Target` carries a one-off profile into the session's `--profile`, the host editor gains the binding picker, and the tile names its bound profile on a chip so what a plain click will do is visible without opening anything. Shape notes, both forced by this toolkit rather than chosen: - The flyout has no submenus, so "Connect with", "Pin as card" and "Unpin card" are flat items, one per profile, matched by prefix. The prefixes end in ": " so a profile named "Copy link" can't collide with a fixed entry. - The binding picker commits on change rather than at Save. The rest of that sheet is text boxes with draft refs, which need a Save; a ComboBox doesn't, and making it wait would be the odd one out. Semantics stay identical to the Linux client, because they are the design's, not the platform's: "Connect with" never rebinds, "Default settings" is `Some("")` so it really does override a bound host for one session, and a binding whose profile was deleted reads as Default settings and resolves to it. `pf_client_core::clipboard::set_text` is the small addition the crate needed for "Copy link" — the OS clipboard plumbing was already there, just private to the streaming bridge. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 00:17:15 +02:00
enricobuehlerandClaude Opus 5	b220daf537	feat(client/windows): the settings screen edits profiles too ... P1 on the WinUI shell. The same surface now edits either layer, switched by a combo above the section title — one settings UI, not a second editor that drifts from the first. The interesting difference from GTK is where the override gets recorded. This shell commits PER CONTROL, so it cannot hand over a list of touched rows the way a commit-on-close dialog can. Instead each control hands `SettingsOverlay::absorb` the effective settings before and after it fired, and absorb records the field that moved. The comparison is against what the control was SHOWING, not against the globals, so setting a value to whatever the global happens to be still records an override — the pin the design asks for — and nothing is ever removed by inference. ⚠️ The content key becomes `(scope, section)`. Keyed on section alone, switching scope diffs one scope's controls into the other's, which re-sets each reused ComboBox's items (clearing WinUI's selection) while skipping `selected_index` wherever the two scopes' values compare equal — the combos then render blank until touched. That is the same trap the section key already existed for, one axis wider. Only profileable rows render in profile scope: auto-wake, the library toggle, the decoder and GPU pickers and the forwarded-pad picker are facts about this device or this network, not about "Game vs Work". Two shapes follow from this toolkit rather than from the design. Creating a profile takes an auto-numbered name and is renamed from the row below, because ContentDialog here is text-only and cannot hold a text field — the same constraint that put the host editor in a tile. And Delete arms a root state that renders the confirmation declaratively, since dialogs here are elements with `is_open`, not calls. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 00:12:43 +02:00
enricobuehlerandClaude Opus 5	ad99be2fb2	feat(client): the overlay learns absorb + clear, so per-control shells can edit profiles too ... Groundwork for the Windows half of P1, and a dedup of the Linux one. The two shells commit differently: GTK writes once when the dialog closes (so it can hand over a list of touched rows), WinUI writes on every control change (so it can't). `absorb` serves the second shape — give it the effective settings before and after one control fired, and it records the field that moved. That is deliberately NOT the diff-on-save the design rejects. The comparison is against the EFFECTIVE settings, i.e. what the control was actually showing, not against the globals — so setting a value back to whatever the global happens to be still records an override, which is exactly the pin the design wants. It only ever adds; removing an override stays an explicit, separate operation. `clear` is that operation, keyed by the overlay's own field names, with `resolution` as the one alias for the width/height/match-window tri-state a single control drives on every client. The GTK reset path now calls it instead of carrying its own `match` — that second list was already a place where the two could drift, and the next client would have made it a third. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 00:04:26 +02:00
enricobuehlerandClaude Opus 5	22cb975659	feat(client/linux): "Create shortcut…" — a double-clickable entry for a host or a pinned profile ... D1's last Linux piece (design/client-deep-links.md §5). The shortcut is a CONTAINER FOR A URL, not a second launch mechanism: it invokes the client with a positional `punktfunk://…`, the same door xdg-open and a browser prompt use. That is what makes it survive things it has no control over — scheme registration being lost, the host moving to a new address, the store being wiped — because the URL itself carries the stable id, the address and the pin. A pinned card writes its profile into the shortcut, so "Desktop · Work" on the app grid is one double-click to that exact session. Two sanitisation points that are not cosmetic: the filename is slugged to ASCII (a host called "Büro · Mac" must still produce a writable name), and the `Name=` value is flattened to one line — desktop entries are line-oriented, so a newline in a host name would end the key and turn the rest into another one. Under flatpak the sandbox cannot write ~/.local/share/applications, so the user gets the URL to place themselves — the fallback the design already sanctions. The `org.freedesktop.portal.DynamicLauncher` route, which exists for exactly this and shows its own confirmation, is the intended upgrade there and is not built yet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 00:01:46 +02:00
enricobuehlerandClaude Opus 5	bd0103b1ac	feat(client/linux): a host edit sheet, and with it the clipboard toggle Linux never had ... Linux had "Rename" and nothing else, so two per-host settings that already existed in the store and on the Apple and Windows clients had no surface here at all: the per-host clipboard opt-in, and now the profile binding. A Linux user could not turn on a feature they were already paying the storage for. The sheet holds exactly the things that are properties of the HOST rather than of the stream — its name, whether this machine shares its clipboard with it, and which settings profile a plain click uses. A binding whose profile was deleted reads as "Default settings" and is cleaned up on save, which is the same "dangling resolves as none" rule the connect path follows. The menu entry becomes "Edit…", and the function and message follow: a `rename_dialog` that opens an "Edit Host" sheet is exactly the drift that confuses the next reader. Pinning stays in the card menu rather than doubling as a list of toggles here — one place to pin is enough, and it is the place you are already looking when you decide to. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 23:54:50 +02:00
enricobuehlerandClaude Opus 5	b9a7163556	feat(client/linux): the speed test writes where the tested host reads, and cards can copy their link ... Two WP3 pieces. **Speed test (§5.3).** Measuring the slow retro box downstairs used to re-tune the desktop upstairs: Apply always wrote the GLOBAL bitrate, which the design calls the sharpest existing symptom of the missing feature. It now writes the layer that host actually resolves bitrate from — the bound profile's override if it has one, the global if the host is unbound. A bound host whose profile inherits bitrate could legitimately mean either, so it gets both buttons instead of a guess. The target depends only on the host, so it is resolved before the test finishes and the button says where it will write ("Set in “Game”"). A one-off (a pinned card's profile) wins over the binding, and a dangling binding falls back to the global — the same precedence a connect uses. **Copy link.** Host and pinned cards can copy their own `punktfunk://` URL — the self-emitted form carrying the stable id *and* host+fp, so a link pasted into a Playnite entry or a Stream Deck macro still resolves after the host re-addresses or the store is wiped. A pinned card copies its profile with it, which is the whole point of pinning it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 23:53:20 +02:00
enricobuehlerandClaude Opus 5	08ec0f4239	feat(client/linux): pin a host+profile as its own card ... §5.2a: a profile you reach for regularly shouldn't live behind a context menu. Pinning one puts *Desktop · Work* in the grid next to *Desktop*, and clicking it is a plain one-click connect with that profile. The pin is presentation state on the host record — `pinned_profiles`, which has been in the store since P0 and unused until now. Deliberately NOT a duplicated host entry: that would fork pairing, WoL MACs and renames, and every host-level action would then need a "which card owns this" rule. So a pinned card is the same record rendered again with a profile attached: it shares the host's live status because it reads the same record, and a pin whose profile was deleted simply doesn't render. What each card offers follows from what it is. The primary card keeps the host actions and gains "Pin as card ▸" (listing only profiles not already pinned; "Default settings" isn't pinnable — the primary card is that). A pinned card offers the one-offs and its own removal, and deliberately not pair/rename/forget — it is a shortcut, not a second host, and offering destructive host actions there would blur the distinction. One action serves both directions: which kind of card it sits on decides whether it pins or unpins. Verified on .21: a host bound to "Game" renders its primary card with a neutral Game chip and, right after it, the pinned "Work" card with an accent chip, both showing the same online/paired state. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 23:49:06 +02:00
enricobuehlerandClaude Opus 5	b485f91f52	feat(client/linux): overridden rows say so, and can go back to inheriting ... The gap in what the scope switcher shipped: a profile was a one-way door. Overrides are recorded on touch and never inferred from comparing values — which is the right model, and exactly why "not overridden" needs an explicit way back. Each overridden row now carries an accent dot in its prefix and a reset button in its suffix, so which settings a profile actually changes is legible without reading every value against the defaults. Reset queues the field, re-opens the dialog in the same scope and lets the close handler commit everything else first — so one code path still builds the rows, including the rebuilt ones showing the inherited value again. Clears are applied after the touched fields for a reason: resetting a ComboRow can fire its change handler on the way past, and "back to inheriting" is the later, explicit intent. An unknown field in the cleared set warns rather than silently doing nothing — this list and the write-back list have to stay in step. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 23:34:42 +02:00
enricobuehler	6de325a6b6	fix(ci): the unsafe lint said warn while CI enforced it as deny, and main went red ... `unsafe_op_in_unsafe_fn = "warn"` was adopted workspace-wide in 39513528 on the assumption that `warn` is a soft setting you can clear at leisure. It is not: ci.yml runs `cargo clippy … -D warnings`, which promotes it to a hard error, so main has failed on EVERY commit since — Linux `rust` and `rust-arm64` both dying on `pf-client-core` with 70 E0133 errors, and windows-host.yml alongside them. A lint level that understates its own severity is worse than a strict one, so this states what CI already does — `deny` — and writes the exemptions down instead. Fourteen GPU/FFI backend files take `#![allow(unsafe_op_in_unsafe_fn)]`, each with its reason and the workspace Cargo.toml carrying the argument in full. They are not "not done yet": measured across them, 64% of the sites are a single third-party FFI call (ash, pyrowave-sys, libav, the NVENC/AMF entry tables), and of the 44 `unsafe fn`s only 4 have a body containing no unsafe operation at all. Since pf-encode also denies `undocumented_unsafe_blocks`, narrowing them means a hand-written SAFETY comment per line that could only restate the signature — the exact noise that made `unsafe` stop meaning anything here before. Everything else stays at zero and enforced, and each allow is removable on its own terms. Two smaller things this had to clear, both invisible to the job that would have caught them: - `service.rs`: `undocumented_unsafe_blocks` wants the proof on EACH block, and a comment covering a group of consecutive `unsafe` statements only credits the first — so the two `OwnedHandle` wraps became their own statements. Windows-gated, so only the .47 gate sees it. 37a42078 fixed the same class of failure in pf-frame/dxgi.rs concurrently; that fix is taken as-is here. - `clients/linux/ui_settings.rs`: `show`'s deletion left its doc comment stranded on `show_scoped`, which silently merged two unrelated doc blocks onto one fn. Removed. Verified by running the real CI commands, not proxies: on .21 fmt + `clippy --workspace --all-targets -- -D warnings` + the feature-gated `-p pf-encode --features nvenc,vulkan-encode,pyrowave` + build + test, all rc=0; on the Intel box .47 all four windows-host.yml clippy invocations, all rc=0. The arm64 job lints pf-client-core and punktfunk-client-linux, both covered here.	2026-07-28 22:32:30 +02:00
enricobuehlerandClaude Opus 5	808eba7292	feat(client/linux): bind a host to a profile, or connect with one just this once ... The other half of P1 on GTK (design/client-settings-profiles.md §5.2): until now a profile could be created and edited but only *used* through `--profile` or a URL. Host cards get two menus, and they are separate on purpose — the predictability rule is that connecting with a profile must never change what the card does next time. - **Connect with ▸** is a one-off. It rides `ConnectRequest.profile` into the session's `--profile` flag and touches no stored state. "Default settings" in that menu is `Some("")`, not `None`: on a bound host, asking for the defaults is a real choice and has to survive as a value rather than degrade into "use the binding". - **Default profile ▸** is the explicit rebinding act. It writes straight onto the host record — the binding IS a field there, so there is no map to keep in step — matched by fingerprint, else by address, like every other per-host lookup in this client. - The card carries a **chip** naming its bound profile, so what a plain click will do is visible without opening a menu. A binding whose profile was deleted shows nothing and connects with the defaults, which is exactly what the resolver does. A URL's `profile=` now takes the same one-off route, since it is the same kind of thing. Verified on .21: `punktfunk://connect/Bound%20Box?profile=Work` against a host bound to "Game" spawned a session that logged `profile=Work id=bbbbbbbbbbbb` — the one-off won, and the binding on disk was untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 22:24:56 +02:00
enricobuehlerandClaude Opus 5	cf419d8b6f	feat(client/linux): the settings dialog edits profiles, not just the defaults ... P1's core on GTK (design/client-settings-profiles.md §5.1). The same surface now edits either layer: a scope switcher at the top of General swaps between "Default settings" and one profile's overrides. Deliberately not a second editor — a parallel one would drift from this one field by field, which is exactly what the "one settings UI" principle is there to prevent. Three decisions carry the design's semantics into this file: - Rows always show the EFFECTIVE value — the global underneath with the profile's overrides applied — so a row the profile doesn't touch reads as the live global. That is what "inherit by default" has to look like. - Overrides are recorded ON TOUCH, never by diffing values at save time. A profile may therefore pin a value that happens to equal today's global and keep it when the global later moves. The handlers that record this are installed after the seed pass, or opening a profile would override every row in it. - Only profileable rows render in profile scope. Auto-wake, the library toggle, the decoder and GPU pickers, the audio endpoints, the forwarded-pad picker and the detected pad list are facts about this device or this network, not about "Game vs Work" (§3's tier G/H), so they simply aren't there. Switching scope closes the dialog — which commits the layer being edited — and asks the app to re-open in the new one, so there is a single code path that builds the rows and no ambiguity about commit ordering. Both scopes read the controls through one shared closure; the tri-state resolution row is the obvious trap if they ever diverged. Create / Rename / Duplicate / Delete live in the switcher's group. Names are unique case-insensitively and the prompt refuses duplicates in place rather than after the dialog is gone. Delete counts what actually breaks — hosts that fall back to the defaults, pinned cards that disappear — and leaves bindings dangling on purpose: they resolve as "no profile" everywhere, and rewriting every host record here would be a second, racier source of truth. `PUNKTFUNK_SHOT_SETTINGS_SCOPE` puts the screenshot scene into profile scope, so both halves of the surface are capturable. Verified on .21 under Xvfb: the switcher, the per-profile actions and the tier filtering render, and the Statistics row seeds to the Game profile's "Detailed" rather than the global's value. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 22:05:29 +02:00
enricobuehlerandClaude Opus 5	6cf5d4ab87	feat(client/linux): punktfunk:// links open the GTK client ... D1's activation half (design/client-deep-links.md §4.1). The client already had a `--connect` CLI, but nothing claimed the scheme, so nothing outside a terminal could start a stream: no browser prompt, no xdg-open, no double-clickable shortcut. The `.desktop` entries gain `MimeType=x-scheme-handler/punktfunk;` and `Exec=… %u`, and the rpm scriptlet joins deb and arch in running `update-desktop-database` — an entry nothing indexes claims nothing. (nix substitutes the Exec line by prefix, so `%u` survives; flatpak's exported entry is renamed to the app id by the standard mechanism.) In the app, `HANDLES_OPEN` plus a positional-URL argv is the whole mechanism, and the second half is the interesting one: argv stays withheld from GApplication as before EXCEPT when it carries a URL, and then GIO's own single-instance forwarding delivers it to the running window over D-Bus. Clicking a link with Punktfunk already open reuses that window instead of racing a second instance, and we wrote no IPC to get it. A URL that lands during a cold start (before the model exists) is parked rather than dropped — silently losing a link is the one outcome that would make the feature untrustworthy. Routing is four lines of translation, because the decisions are the brain's: parse, resolve the host, resolve the profile, refuse. A link that resolves becomes exactly the message a card click raises — the same wake, trust gate, and error surfaces — so there is no second connect path to keep in sync. A link to a host we don't know, or know but never pinned, opens the ordinary PIN ceremony seeded with what the link claimed, which is how "a URL may never pair or trust on its own" stays true while still being useful. Never preempting a live session is checked here, since only this layer knows one is running. Verified on .21 under Xvfb against hand-authored stores: `connect/Bound%20Box?launch=` resolved the host by name, carried the launch id through the trust gate, and spawned the session; `punktfunk://pair/1234` and an unknown `profile=` both refused before any dial. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 21:37:10 +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	37edb1cc1a	refactor(clients): both shells wake through the shared state machine ... The last of C0's duplication: GTK's `wake_and_connect` and the WinUI shell's ran their own copies of the same 90 s / 6 s / 1 s loop, and the Windows one's comment said it "mirrors the Apple HostWaker" — now it literally does, because both drive `WakeWait`. What is left in each shell is the part that genuinely differs: its dialog or screen, its advert drain, its re-key, and its route back into the trust gate. Behavioural review, since a sleeping host to test against wasn't available: - GTK polled every 500 ms and resent on a wall-clock timer; it now ticks once a second like every other implementation. Up to half a second slower to notice a host coming back, and exactly the reference cadence in exchange. - GTK took the FIRST matching advert in a drain and returned mid-loop; it now drains fully and takes the last, i.e. the freshest address. Same connect, fresher re-key. - Windows sent one packet before the loop AND one on its first pass; the machine owns the packets now, so that duplicate is gone. Resends still land at 6 s, 12 s, … and the budget still expires at 90 s. - Both keep their own cancel path, their own re-key, and their own error surface. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 21:01:47 +02:00
enricobuehlerandClaude Opus 5	983ff8e78d	fix(session/console): a profile must not advertise a cursor channel the presenter isn't drawing ... Found reviewing the P0 wiring. The console builds its window and input models ONCE, from the global defaults, and they live across every launch — but each launch now re-resolves the host's profile. So a profile that sets `mouse_mode: desktop` on a host, while the global stays `capture`, made the session advertise `CLIENT_CAP_CURSOR` ("this client draws the host cursor itself") to a presenter latched in capture mode, which draws no cursor: the host stops compositing the pointer and the stream has no visible cursor at all — the exact failure the capability's own doc comment warns about. The advertisement now follows the LATCHED mouse model, which is the one that is actually true of the presenter. Everything the host is told about the stream itself — mode, bitrate, codec, audio, pad — keeps honoring the binding, and the comment says which fields are latched and why, so the console's presentation-tier gap is documented rather than rediscovered. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 20:46:29 +02:00
enricobuehlerandClaude Opus 5	eab4829630	feat(client): the brain layer — one connect plan, one wake machine, one spawn ... C0 of design/client-architecture-split.md. Wake-then-connect exists three times today — GTK's `WakeConnect`/`wake_fallback`, the WinUI shell's `wake_and_connect` (whose comment says it "mirrors the Apple HostWaker"), and Apple's `HostWaker` itself — and the deep-link and profile work was about to make it five. `pf-client-core` already held the ingredients (wol, discovery, trust, library, session); what was missing was the layer that composes them, so every front-end composed them itself. `ConnectPlan` is a resolved intent: which host, which pin, which launch id, which profile, the effective settings, whether to wake. One constructor per door — a card click, a CLI verb, a URL — one type out. `ConnectPlan::resolve` is pure (stores in, plan out), which is what lets the URL router be tested without a config directory; `for_host` is the convenience that loads them. `plan_from_link` is where the deep-link security rules actually live, rather than in each shell: a contradicted fingerprint refuses and says which host it was about, an ambiguous name refuses instead of picking the first, a profile the catalog can't honor refuses BEFORE anything is dialled, and an unknown — or known-but-never-pinned — host becomes a confirmation sheet carrying the claimed name and expected pin, so the first connect is verified rather than blind TOFU. Preempting a live session stays with the caller: only the front-end knows one is running. `WakeWait` is Apple's `HostWaker` cadence as a pure step function — packet at 0 s and every 6 s, presence polled every second, 90 s budget, and a PARK (not an error) at the end, because "it didn't wake in 90 s" is usually "give it 10 more". As a step function each front-end drives it from its own loop and they still agree, and the whole cadence is testable without waiting 90 seconds. Session spawn, its argv and its stdout contract move here too, and the GTK shell now spawns through them — so "which flags does a stream get" and "what does ready mean" have one answer for the shells, the console and the coming CLI. `--profile` deliberately does NOT ride a plain card click: the session resolves the host's binding through the same helper, and passing it would be a second source of truth for one decision. Not yet adopted: the two shells' wake paths. That swap changes the most-used path in the product and the handoff wants it verified on glass with a genuinely sleeping host, which this session couldn't do — so the state machine lands, the duplication stays until it can be verified away. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 20:45:07 +02:00
enricobuehlerandClaude Opus 5	3350d3cfbf	feat(client): the punktfunk:// grammar — one parser, one emitter, one vector file ... D0 of design/client-deep-links.md. Apple has shipped `punktfunk://connect/<uuid>` for a while; this is the same grammar, generalised and given a Rust implementation the GTK and WinUI shells, the session and the coming CLI all share: punktfunk://connect/<host-ref>[?fp=…][&host=addr[:port]][&launch=…][&profile=…][&name=…] The rule the grammar exists to keep is that a URL may only ever do what a click on an existing card could do, minus trust decisions. So it carries REFERENCES to things that already exist on this device — never values: no resolution, no bitrate, no codec, so a web page cannot shape a session beyond picking among the user's own configurations. And `pair` is not a route: it parses, and refuses, so a link can never start a trust ceremony. Everything hostile is rejected here, once, for every front-end — 2 KB total cap, per-parameter caps, strict percent-decoding (a half-escape or invalid UTF-8 is an error, not a shrug), control characters refused after decoding, launch ids held to the charset the host and Decky already agree on, and `fp=` that must actually be 64 hex. Resolution follows the same order everywhere: stable record id → unique host name → `addr[:port]`, with `host=`+`fp=` as the reinstall recovery path, which is why self-emitted links carry all three. An ambiguous name refuses rather than guessing; a stale id with no recovery address refuses rather than dialling "11111111-…" as if it were a hostname; an unknown-but-plausible address becomes the confirmation sheet, never an auto-connect. `pf://` parses as an input alias and is never emitted or registered — claiming a two-letter scheme on MSIX/Apple is unconditional squatting, and a link that resolves on one platform only is a trap. The 44-case `clients/shared/deeplink-vectors.json` is the cross-language contract: this module's tests run every case, and the Swift and Kotlin ports will run the same file, so three parsers cannot drift into three different security postures. Refusal codes are part of that contract, not just the happy path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 20:32:32 +02:00
enricobuehlerandClaude Opus 5	a2be3f4de9	feat(client): settings profiles — the override catalog, the one resolver, and the session flag ... A client setting is global today: pick 4K@120 HDR and the retro box gets it too. The one escape hatch (per-host `clipboard_sync`) proves the shape works but covers a single field. This is P0 of design/client-settings-profiles.md — the headless core the shells, Apple, Android and the deep-link grammar all build against. No UI yet. A profile is a NAMED BUNDLE OF OVERRIDES, not a snapshot: `SettingsOverlay` is sparse `Option`s, so a field the user never touched keeps following the global value live, and fixing a global once fixes it everywhere. `Some(x)` equal to today's global is still meaningful — it pins x against a later global change — which is why the UI will write `Some` on touch and `None` on an explicit reset, never by diffing. The catalog is its own `client-profiles.json`, deliberately not part of the settings file: that file has five whole-file load-modify-save writers with no merge, so a profile written by one would be dropped by the next. Which host uses which profile is a field on the host record instead of a map keyed by host — that is what dissolves the client's long-standing "what identifies a host record" question for this feature. Resolution has exactly one implementation, `trust::effective_settings()`: effective = overlay(profile).apply(global) profile = one-off pick ?? host binding ?? none Both session construction sites go through it (`main.rs` AND `console.rs` — touching one and not the other is a Windows-only build break), so the console, and therefore Decky, honor host bindings with no work of their own. Nothing here can fail a connect: a deleted binding resolves as "no profile", and a one-off that can't be honored falls back to the DEFAULTS rather than to the host's own profile — "connect with Work" must never quietly stream "Game". `--profile <id|name>` is the one-off door for the shells' coming "Connect with ▸" and for `punktfunk://…&profile=`; `--profile ""` forces the defaults on a bound host. The active profile's name closes the stats overlay's first line, so "which profile am I on?" is answerable without leaving the stream. Also here, because this effort touches every one of these anyway: - `KnownHost` gains `profile_id`, `pinned_profiles` and a lazily minted stable `id`. The id is groundwork (design §4.5) — no lookup is re-keyed, `fp_hex`/`addr:port` stay. - `upsert` now preserves the state the USER set on a record — the profile binding, its pins, the clipboard decision, the id — against refreshes that carry none of it. `clipboard_sync` survived that only because the function happened not to mention it. - `KnownHost::default()` exists so construction sites read `..Default::default()`; five hand-written literals were exactly how a new field gets silently dropped on re-pair. - All three client stores now write temp+rename. A torn settings file loads as `Default` — i.e. silently resets every setting the user has. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 20:22:33 +02:00
enricobuehlerandClaude Opus 5	a4aa89be31	fix(decky): drive a native client install, not only the flatpak ... Every headless call went through `flatpak run io.unom.Punktfunk`, and the launch wrapper exec'd the same. On a Deck whose client came from a sysext, a .deb/rpm, an AUR build or a nix profile there is no such app: discovery worked (it is mDNS), and everything that needed the client — pairing, the library fetch, the host store, the stream launch itself — failed. Resolve the client once. The flatpak still wins when it is actually installed, so an existing Deck is byte-for-byte unchanged, and a native `punktfunk-client` is the fallback; `PF_DECKY_CLIENT` forces one on a machine with both. Both kinds share ~/.config/punktfunk — the flatpak's sandbox HOME is the real home — so identity, known-hosts and settings need no divergence. The wrapper takes the resolved binary as PF_CLIENT_BIN and execs it in place of `flatpak run`; kill_stream sends a name-matched SIGTERM where there is no flatpak instance to kill; and the client-update check, which reads the flatpak's tracked remote, simply reports nothing for a native install, whose updates belong to whatever installed it. Installed-ness is now decided by the app's exported directory rather than by the presence of the `flatpak` binary, so a machine that has flatpak but not this app no longer resolves to a client that cannot run. Closes #11 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:13:19 +02:00
enricobuehlerandClaude Opus 5	198b1d5e80	fix(apple): iPad mouse buttons, held-key repeat, and the scroll direction ... Three separate things an iPad's keyboard and mouse got wrong. Every mouse button past the first two clicked LEFT on the host. UIKit's button mask is 1-based over the HID order, and only `.secondary` was read — middle, back and forward all fell into the `else` and became button 1. Map 3/4/5 through `.button(_:)`; only middle and right swap places, because the wire numbers them the other way round. Holding a key deleted exactly one character. GameController reports a key once on press and once on release — it has no repeat channel — and the host injects exactly what it is told, so nothing downstream ever turned a held key into a stream of presses. Generate the repeat client-side at the usual delay-then-rate, newest key only, with modifiers and lock keys excluded. macOS was never affected: NSEvent hands it the window server's own repeats. Scrolling ignored the system's Natural Scrolling switch. UIKit has already applied that preference by the time it hands over a pan translation — it is what makes every UIScrollView on the device turn the right way — so negating y pinned the stream to traditional scrolling and inverted the setting for everyone on the default. Pass the sign through, exactly as the macOS path passes `NSEvent.scrollingDeltaY` through, and let that one recognizer own scroll under pointer lock too: it is the only way trackpad two-finger scrolling ever arrives, so gating it on the lock had been dropping it entirely there, and the raw GameController axis it deferred to carries no such preference. iOS installs no GCMouse scroll handler now, so nothing double-sends; tvOS, which has no scroll pan, keeps it. Closes #7, closes #15 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:13:19 +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	94f0207cbd	feat(windows/client): logs persist — %LOCALAPPDATA%\punktfunk\logs\client.log ... The shell is a windows_subsystem binary and spawns punktfunk-session with CREATE_NO_WINDOW + inherited stderr: a normal GUI/MSIX launch has no console, so every log line — the shell's and the session's whole receive/decode/present forensic trail — evaporated exactly when a user hit something worth reporting. The 2026-07 PyroWave latency-sawtooth report had to be triaged from host logs alone; the deciding evidence (clock re-sync vs backlog-flush lines) lives client-side. - New logfile module: %LOCALAPPDATA%\punktfunk\logs\client.log, the host's rotation convention (10 MB cap -> .old at next start, one generation), best-effort (no dir -> plain stderr, never a startup failure). - The tracing subscriber tees to stderr AND the file (ANSI off — the file is what users send); startup logs the path. - The spawned session's stderr is piped through the same tee, line-buffered — dev-terminal runs keep their interleaved output, GUI runs finally keep anything at all. - The --console path and the punktfunk-console.exe MSIX shim forward the same way (a couch launch has no console either). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 12:51:11 +02:00
enricobuehlerandClaude Opus 5	1ee06defa6	feat(library): descriptive metadata on every entry — platform, year, genres, and friends ... Emulation-and-beyond libraries need more than a title and a poster. Every library shape (GameEntry, CustomEntry, CustomInput, ProviderEntryInput) now carries a shared, flattened GameMeta: platform, description, developer, publisher, release_year, genres, tags, region, players. All fields are optional and flat on the wire, so existing library.json files, provider plugins, and clients keep working unchanged. - Installed-store scanners (Steam, Lutris, Heroic, Epic, GOG, Xbox) stamp platform=PC; custom/provider entries carry whatever was authored. - GET /library grows a ?platform= filter (case-insensitive) beside ?provider=. - Console: the add/edit form gets a Details section (round-tripping every field, since update replaces the entry), the poster tile a platform badge (non-PC only — the store badge already implies PC) and the year. - plugin-kit: ProviderEntry accepts the same fields (new GameMeta schema, spread flat); SDK + OpenAPI spec regenerated. - pf-client-core decodes platform for future client badges. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 19:00:30 +02:00
enricobuehlerandClaude Opus 5	0d9d78398c	fix(drivers/windows): name each virtual pad for what it is — one shared description read as "the setting did nothing" ... `pf_dualsense.inx` gave all four hardware ids a single %DeviceDesc%, so Device Manager labelled an emulated DualShock 4, DualSense Edge and Steam Deck pad "punktfunk Virtual DualSense". The HID layer was always per-type — device_type picks the PID (09CC for DS4), the report descriptor and the product string — but the one place a user goes to check said DualSense for every choice, which reads exactly like the controller-type setting being ignored. Split into four model lines over the same install section, one description each. No binding, service or descriptor change; stampinf's 9.9.MMdd.HHmm DriverVer increments on every build, so pnputil takes the update. InfVerif on the WDK runner: INF is VALID. Also correct the Slot.pref comment from the previous commit: emulating a DualShock 4 gives up adaptive triggers by construction. HidOutput::Trigger is emitted only by dualsense_proto, and a DS4 has no trigger-effect reports — the host never generates any to send. Rumble and the lightbar remain. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 16:56:44 +02:00
enricobuehlerandClaude Opus 5	6edd700910	fix(client/gamepad): honor an explicit controller type — the per-pad arrival was re-declaring the physical pad ... The "Controller type" setting reached the Hello and stopped there. Every pad then opened with a GamepadArrival carrying its DETECTED kind, and the host builds each virtual device from that arrival — the session default is only the fallback for a pad that never declares one. So "emulate my DualSense as a DualShock 4" put a DualSense on the host the instant the controller connected, and no amount of reconnecting helped. Apple and the native clients both; Android already applied the setting per pad. The setting now rides the declaration too: explicit wins for every slot, Automatic keeps per-pad detection so a mixed session stays honest. The physical kind still drives the LOCAL feedback paths — a DualSense emulated as a DualShock 4 keeps its lightbar and adaptive triggers, and a Deck keeps its rumble keep-alive. Regressed in 97c67b26 / 76be4c3e (multi-controller support); ships in 0.19.x. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 16:56:44 +02:00
enricobuehlerandClaude Opus 5	36e566052f	fix(apple/cursor): a pointer whose bitmap has not landed must not vanish ... `resetCursorRects` wore the host shape only when `hostCursors[st.serial]` hit, and fell through to `invisibleCursor` on a miss. But a miss is the ROUTINE case, not a degenerate one, and it is not a reason to hide the pointer: * State (0xD0) is a per-frame datagram and announces the new serial the moment the host QUEUES the bitmap on the reliable control stream, so on every single shape change the client knows a serial before it holds the pixels. * The shape ring drops the NEWEST under burst (CURSOR_SHAPE_QUEUE = 8) and the host never re-sends it — it only sends on a serial CHANGE — so a dropped serial stays un-backed until the pointer next changes shape. Crossing a toolbar flips arrow/I-beam/hand/resize several times a second, and each flip mints a fresh serial and a fresh bitmap, so bursts are ordinary. Either way the pointer BLINKED OUT rather than lagging, and in the dropped case it stayed gone for as long as the pointer held that shape — reported on glass as "the I-beam never appears over text fields, every other cursor is fine". Hold the last worn shape across the gap: only `st.visible == false` (the host says the pointer is hidden) may hide it now, never a missing bitmap. Worst case is a briefly stale pointer. This also makes two comments that already claimed this behaviour true — the shape-rejected warning's "keeping the previous cursor" and CURSOR_SHAPE_QUEUE's healing claim, both of which were fiction. Host side is exonerated: on .221 the poller sees the I-beam handle (0x10005, CURSOR_SHOWING set), and the monochrome AND-over-XOR conversion renders a correct glyph — black beam, white outline — so the bitmap that goes on the wire is good. swift build PunktfunkKit + cargo check punktfunk-core green; on-glass owed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 14:13:08 +02:00
enricobuehlerandClaude Opus 5	915fc3ef9e	feat(session): headless --pair, so a box with only SSH can enrol ... `punktfunk-session --pair <PIN> --connect host[:port]` runs the SPAKE2 ceremony with no window and no toolkit, prints the same `paired <addr>:<port> fp=<hex>` line as `punktfunk-client --pair`, and exits. Until now the PIN ceremony lived only in the GTK shell or the Skia console, so enrolling an embedded/kiosk client meant installing a desktop on it — or copying the identity store by hand. Dispatches above every graphics call (the machine may have no display) and is in the `--no-default-features` build: enrolling must never be the reason a minimal image pulls in Skia. `--name` defaults to the hostname instead of the desktop path's hardcoded "Steam Deck". `forget_placeholder` and `device_name` move into pf_client_core::trust so the two binaries share one implementation rather than the session re-deriving them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 14:32:45 +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 Opus 4.8	bc5f6a3881	fix(apple/session): keep the display awake for the length of a session ... A stream is not user activity to the OS, and controller input does not feed the HID idle timer on any Apple platform — so a gamepad-only session reliably idles the panel out from under the user mid-play. A keyboard/mouse capture session masks the bug because those events are real local HID. The Android client has held FLAG_KEEP_SCREEN_ON while streaming all along; the Apple clients held nothing. DisplaySleepGuard is acquired in beginStreaming and released at the top of disconnect, so it is scoped to the session — every teardown path (user quit, sessionEnded, the backgrounded keep-alive timeout) funnels through disconnect. iOS/iPadOS/tvOS: UIApplication.isIdleTimerDisabled. App-wide and ignored while backgrounded, which is what the audio-only keep-alive wants. macOS: ProcessInfo.beginActivity(.userInitiated, .idleDisplaySleepDisabled), the Foundation wrapper over IOKit power assertions. That defers display sleep but NOT the screen saver, which runs off the HID idle timer independently — so a 30 s IOPMAssertionDeclareUserActivity heartbeat runs alongside it. Intended side effect: an idle-lock that follows the screen saver is deferred for the session too. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 00:00:55 +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	c8aa3ed48b	feat(apple/ios): pen P4 — Apple Pencil (Pro) capture onto the stylus plane ... The flagship leg of design/pen-tablet-input.md §7: against a HOST_CAP_PEN host the Pencil splits out of the finger path (independent of touch-input mode) into PencilStream — state-full samples with force→pressure, altitude→polar tilt, azimuth (+90° to the wire's north-clockwise convention), Pencil Pro rollAngle→ barrel roll (17.5+), coalesced touches batched ≤8/send for full 240Hz fidelity, and Pencil hover (zOffset>0 distinguishes it from trackpad hover) as in-range samples with distance. Squeeze holds barrel 1, double-tap clicks barrel 2 (the Pencil has no hardware buttons/eraser — these are how host apps get those affordances). Implements the ≤100ms heartbeat wire contract (80ms timer) so a stationary held stroke survives the host's 200ms dead-client failsafe. Toward a pen-less host nothing changes (Pencil stays a finger). Also fixes hostSupportsCursor testing the STALE 0x04 bit — HOST_CAP_CURSOR moved to 0x08 when TEXT_INPUT claimed 0x04; the old test would mistake a text-input host (e.g. Windows) for a cursor grant and double-render the pointer. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 16:48:57 +02:00
enricobuehlerandClaude Opus 4.8	35c2c1450e	fix(apple/cursor): scale the forwarded pointer to the video fit ... The Mac client drew the host-forwarded cursor bitmap at its native pixel size (pixel-as-points), so the on-screen pointer tracked the HOST's display scaling: a 4K/high-DPI virtual display renders a 96 px pointer, which then appeared huge on the client — and on retina every pointer was already 2x-inflated and upscaled-blurry, since the backing scale was ignored. Cache the shape raw and rebuild the NSCursor at the live video-fit factor (fit.width / mode.width — the same AVMakeRect fit the input mapping uses) on each apply, re-fitting on resize / retina moves. The pointer now renders at its true size relative to the streamed desktop at any host scaling: crisp and 1:1 with the video at 100%, and proportional (not ballooning) when the host sits at 200-300% — including a deliberately raised scale. iOS/tvOS (UIPointerInteraction) and Android (no forwarded-bitmap path) render the pointer differently and need no change; the SDL/Linux client has the same native-size issue and will follow. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 14:14:41 +02:00
enricobuehlerandClaude Opus 4.8	8c9baf3214	fix(decky): recreate the library shortcut when its cached appId is stale ... The visible "Punktfunk" shortcut's Steam appId is cached in SteamUI localStorage, which lives in Steam's CEF profile — so it survives a plugin uninstall/reinstall. Deleting the shortcut left the key dangling; on the next mount ensure*Shortcut recalled the dead appId, took the reuse branch, and ran SetShortcut* against a non-existent id (silent no-ops). AddShortcut was never reached, so the entry never came back. The same stale-reuse also made the hidden stream shortcut RunGame a dead gameid. Verify the remembered appId still maps to a live shortcut via appStore.GetAppOverviewByAppID before reusing it; a confident miss falls through to AddShortcut. When appStore is unavailable, assume it exists so a false negative can't spawn a duplicate library entry. Also add a "Recreate library shortcut" recovery button to the QAM About section (recreateShortcuts): drops any dead cached keys and re-ensures. Covers deleting the shortcut without reinstalling, where no mount fires the self-heal. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 00:41:32 +02:00
enricobuehlerandClaude Opus 4.8	d86073dc6a	feat(apple/cursor): send the mid-stream cursor-render flip — ABI v12 ... PunktfunkConnection.setCursorRender(clientDraws:) over the new punktfunk_connection_set_cursor_render export, driven by one edge-detected reconciler in StreamView (clientDraws = captured && desktopMouse) called from every transition — the ⌃⌥⇧M chord, engage/release, and session start. Capture model and released now get the host-composited pointer back in the video (full fidelity); the desktop model keeps the local NSCursor path. xcframework rebuilt v12. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	0420be9fa5	fix(apple/cursor): reset per-session cursor-channel state in stop() ... cursorChannelActive/hostCursors/cursorState stayed latched across sessions — a next session against a host WITHOUT the cursor cap would wear the previous session's stale shapes via resetCursorRects. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Fable 5	2bbcbc81c6	fix(apple/cursor): disable M3 visibility-based auto-flip — it broke desktop drags ... On-glass (Mac ↔ Windows M2c host): the host cursor's VISIBILITY is not a usable 'a game grabbed the mouse' signal — Windows hides the pointer for ordinary desktop activity (clicking, typing). The per-frame forwarder turned those transients into relative_hint=true, so the client flipped desktop→capture→desktop, which (a) warped the cursor to view-centre and (b) flushed held buttons via releaseAll — a spurious mouse-up ~200 ms into every press that broke window dragging/resizing. Disable the auto-flip; the mouse model stays user-driven (⌃⌥⇧M). The hint still rides the wire, unused, for a future M3 that keys off a REAL pointer-lock signal (host-side ClipCursor/raw-input detection) instead of visibility. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Fable 5	ec8ca9a535	feat(apple): cursor channel on the Mac client — ABI v11 + NSCursor rendering ... The Mac client now exercises the full cursor channel against capable hosts: desktop-mode sessions advertise CLIENT_CAP_CURSOR, the host stops compositing the pointer, and StreamView draws the forwarded shapes as the real NSCursor — plus the M3 host-driven model flip. - ABI v11: punktfunk_connect_ex9 (adds client_caps; ex7/ex8 pass 0 — Android untouched), PunktfunkCursorShape/State + the two next_cursor_* poll fns (audio-style borrow contract), and PUNKTFUNK_CLIENT_CAP_CURSOR. Fixed in passing: the first insertion split next_host_timing's cfg/no_mangle attributes off the fn, which silently dropped the symbol from the header AND dylib — caught by the Swift build, reattached with its docs. - PunktfunkConnection: clientCaps connect param, hostSupportsCursor, CursorShapeEvent/CursorStateEvent + nextCursorShape/nextCursorState (one cursor thread drains both planes; cursorLock joins the close() ladder). - SessionModel: desktop-mode sessions (DefaultsKey.mouseMode) connect with the cursor cap on macOS. - StreamView: shape cache (serial → NSCursor, straight-alpha RGBA via CGImage), resetCursorRects wears the HOST shape while the desktop model is engaged (hidden host pointer ⇒ invisible), latest-wins state pump, and the M3 auto-flip — edge-triggered on relative_hint, ⌃⌥⇧M sets an override latch cleared by the next host edge, leaving relative warps the pointer to the host position via the inverse letterbox mapping (CGWarpMouseCursorPosition, CursorCapture's coordinate convention). Verified: swift build + full test suites green (xcframework rebuilt at ABI v11, signed); core 218 tests + clippy -D warnings on Linux (.21). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:43:23 +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	97d20e1f0a	feat(apple/input): desktop (absolute) mouse mode on macOS — remote-desktop sweep M1 ... Folds the parked client-side-cursor machinery (cursorMode auto/always/ never, hidden while disabled) into the cross-client mouse model: MouseInputMode capture|desktop under DefaultsKey.mouseMode, picked in Settings ▸ Keyboard & mouse (macOS), resolved at session start and gated off on gamescope hosts (relative-only EIS). Desktop model = the un-neutered absolute path with the SDL cursor policy: pointer never disassociated (enters/leaves the stream freely), monitor forwards letterboxed absolute positions, and the local cursor hides only while over the view via an invisible-cursor rect (the host's composited cursor is the one you see; AppKit manages the rect, so no hide/unhide balancing). ⌘⇧C becomes ⌃⌥⇧M — the same chord as the SDL clients — flipping the model live with an atomic release/re-engage. Verified: swift build + full test suites green (macOS arm64). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:37:32 +02:00
enricobuehlerandClaude Fable 5	df04880273	feat(client/input): desktop (absolute) mouse mode — remote-desktop sweep M1 ... New physical-mouse model beside capture: Desktop leaves the pointer uncaptured and sends absolute positions through the letterbox (MouseMoveAbs — every host injector already consumes it). Capture stays the default and the game model. - pf-client-core: MouseMode (capture|desktop) persisted in Settings, default capture so existing stores are unchanged. - pf-presenter: Capture grows a desktop model — latest-wins pending abs position coalesced per loop iteration (same 1000 Hz discipline as relative), flushed before clicks/keys/wheel so they land where the cursor is; Ctrl+Alt+Shift+M flips the model live; local cursor stays hidden over the window (the host's composited cursor is the one you see until the M2 cursor channel); Windows keyboard grab only engages for capture (a desktop stream is something you Alt-Tab away from). - gamescope gating: its EIS is relative-only, so desktop mode is pinned off there (resolved_compositor), with a log note. - Settings surfaces: GTK row (dynamic caption), WinUI combo, console-UI row + step test, capture-hint line. Verified: fmt + clippy -D warnings + tests (33/40/19) on Linux .21; clippy -D warnings for all five crates incl. punktfunk-client-windows native on .173. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:37:32 +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