471 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehler	6136ba4c72	feat(web/library): game library page — grid + custom-entry CRUD ... Consumes the new library API (6351d51) via the orval-generated hooks. A poster grid over GET /api/v1/library (all stores merged), plus create/edit/delete for custom entries — the admin-UI half of "create custom entries via the web console". - GameCard: portrait (600×900) art with an onError fallback chain portrait → header → text placeholder (many Steam titles lack a 600×900 capsule). A store badge marks Steam vs Custom; only custom cards expose edit/delete. - Inline add/edit form (title + portrait/hero/header URLs + optional launch command, mapped to LaunchSpec{kind:"command"}) wired to useCreateCustomGame / useUpdateCustomGame / useDeleteCustomGame; the CRUD id strips the `custom:` prefix; every mutation invalidates the library query. QueryState handles load/empty/error. - Nav entry (LibraryBig) + en/de i18n strings. `bun run lint` (tsc) and `bun run build` both green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 13:48:00 +00:00
enricobuehler	6351d516e0	feat(host/library): game library API — Steam adapter + custom store ... A new `library` module + four mgmt endpoints surface the host's games to clients (plan: "surface the user's games"). An adapter layer (`LibraryProvider`) so future stores (Heroic/Epic, GOG, Lutris) slot in behind one uniform `GameEntry`. - SteamProvider: reads the LOCAL Steam install — no Steam Web API key, no network. Installed titles from steamapps/appmanifest_<appid>.acf; extra library folders (incl. paths with spaces) from libraryfolders.vdf; candidate roots cover classic, Flatpak and Deck layouts, canonicalized + deduped (the .steam/{steam,root} symlinks all fold to one). Runtimes/redistributables (Proton, Steam Linux Runtime, Steamworks Common, SteamVR) filtered out. Artwork = the public Steam CDN by appid (portrait/hero/logo/header), fetched directly by the client. - Custom store: ~/.config/punktfunk/library.json, write-then-rename persisted, CRUD'd via the API — the "create custom entries via the admin web UI" requirement. - API (under /api/v1, OpenAPI-documented + checked in): GET /library (all stores merged, sorted), POST /library/custom, PUT/DELETE /library/custom/{id}. - `punktfunk-host library` subcommand dumps the resolved library as JSON (diagnostic, mirrors `openapi`). Validated live against the real Steam library on the Bazzite box: 89 appmanifests → 78 games (11 tools filtered), correct titles/sort, and the CDN art URLs return 200. 5 unit tests for the VDF/ACF parsing, tool filter, art URLs, custom mapping. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 13:43:03 +00:00
enricobuehler	ee7984beb0	feat(packaging/arch): split package — add punktfunk-client for the Deck ... The Decky plugin (b3f98a5) launches `punktfunk-client`, but the Arch package only shipped the host, so the Deck had nothing to launch. Convert the PKGBUILD to a split package (pkgbase=punktfunk → punktfunk-host + punktfunk-client), mirroring the rpm subpackages and the two deb build scripts: - punktfunk-host: unchanged artifact set + NVENC/compositor optdepends. - punktfunk-client: the GTK4 binary + io.unom.Punktfunk.desktop + the hidraw udev rule + the 32MB recv-buffer sysctl; depends gtk4/libadwaita/sdl3/ffmpeg/pipewire/ opus; optdepends libva-mesa-driver (VAAPI decode on the Deck's AMD APU, software fallback otherwise). New punktfunk-client.install scriptlet. - build-sysext.sh now derives the package name from the file, so it wraps either the host OR the client into a systemd-sysext .raw — on a Deck you wrap the client. - README: split-package usage + a "Steam Deck (the client)" section tying the sysext to the Decky plugin (client is on PATH → plugin launches `punktfunk-client --connect host:port`). Clarified the VAAPI gap is host-ENCODE only; the client DECODES via VAAPI on the Deck today, so streaming to a Deck works now. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 13:09:10 +00:00
enricobuehler	b3f98a5d7d	feat(clients/decky): SteamOS Gaming-Mode launcher plugin (spike) ... A Decky Loader plugin so a Steam Deck / SteamOS box can launch the punktfunk client from Gaming Mode using REAL Steam UI components (it runs inside Steam's CEF, so the panel is built from @decky/ui — the literal Big Picture primitives, not a replica). - Frontend (src/index.tsx, @decky/api + @decky/ui): a Quick Access Menu panel — Refresh → discover hosts, a native list (name, ip:port, pairing flag), tap to connect with a status toast, Disconnect. - Backend (main.py): discover() shells `avahi-browse -rpt _punktfunk._udp` and parses the host's advertised TXT keys (proto/fp/pair/id from discovery.rs), dedup by id preferring IPv4; connect() resolves + spawns `punktfunk-client --connect host:port` (gamescope composites its video like a game), tracking the child; disconnect() terminates it. - Mirrors the current official Decky template (the API moved to @decky/ui + @decky/api). Frontend builds clean (pnpm build → dist/index.js); main.py py_compiles. dist/ + node_modules gitignored — build on the Deck per README. Spike scope: launcher only, runtime untested (no Deck here). Next on this track: the in-stream Quick-Access overlay (volume/disconnect/stats over the running stream) and a fuller real-components UI. Client decode on the AMD Deck is the existing VAAPI path; the host-encode VAAPI gap is separate (NVIDIA host = NVENC). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 12:50:57 +00:00
enricobuehler	c64816c70a	feat(apple): client-side cursor for gamescope sessions (toggle + shortcut) ... gamescope's PipeWire capture carries no cursor (verified upstream — it never composites the cursor or adds SPA_META_Cursor), so the cursor must be drawn on the client. New macOS "cursor-visible" capture mode: instead of disassociating+hiding the system cursor and sending relative deltas (the game path, unchanged), it keeps the system cursor visible over the stream and sends ABSOLUTE positions (MouseMoveAbs), mapped through the video's aspect-fit (AVMakeRect) to host pixels with the letterbox bars dropped. The visible system cursor IS the client cursor — zero added latency, no double cursor (gamescope draws none), accurate (the client drives the host's absolute mouse). - Default: on iff the session's resolved compositor is gamescope (via the new punktfunk_connection_compositor getter, fc30307). - Settings: "Cursor in stream" → Auto (gamescope) / Always / Never. - Shortcut: ⌘⇧C toggles it live mid-session (re-engages capture so disassociation + abs/rel forwarding swap atomically); shown in the HUD. macOS-only (the visible-cursor mode lives in the macOS StreamView). Verified to compile + link via xcodebuild Release on the Mac; runtime behavior (cursor landing, hover forwarding) to be confirmed live. Rust ABI side committed separately. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 12:07:15 +00:00
enricobuehler	fc30307a87	feat(abi): expose the host-resolved compositor to clients ... Add punktfunk_connection_compositor() (mirrors punktfunk_connection_gamepad): a client getter for the compositor the host actually resolved for the session, read from Welcome.compositor and threaded through NativeClient.resolved_compositor. The Apple/Linux clients use it to enable the client-side cursor by default on gamescope sessions, whose PipeWire capture carries no cursor (verified upstream). Header regenerated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 11:58:37 +00:00
enricobuehler	c548155dd9	feat(packaging/arch): Arch + SteamOS install target (PKGBUILD + sysext) ... Add packaging/arch: a PKGBUILD mirroring the rpm/deb artifact set (binary, udev rule, 32MB sysctl, systemd USER units with ExecStart rewritten, headless helpers, env templates, openapi), a pacman .install scriptlet, a systemd-sysext builder for immutable SteamOS, and a README. Builds the working tree via PF_SRCDIR (CI/dev) or a git tag (AUR). Arch's stock ffmpeg already ships NVENC, so deps collapse to ~10 packages with nvidia-utils/compositors as optdepends (never hard-depend on the driver, same invariant as rpm/deb). SteamOS delivery is a **systemd-sysext** (overlays /usr read-only from writable /var/lib/extensions/, survives A/B OS updates, no steamos-readonly disable) — pacman/distrobox/flatpak are all unsuitable for a host that needs uinput/uhid, the host PipeWire socket, the GPU node, and to spawn a compositor. KNOWN GAP, documented prominently: encode is NVENC-only (src/encode/linux.rs has no VAAPI backend), so this works on Arch+NVIDIA (and bazzite-deck-nvidia) but an AMD Steam Deck installs yet cannot encode until a hevc_vaapi backend is written — a code change, not packaging. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 11:43:48 +00:00
enricobuehler	abc057fbfe	fix(ci/apple): scope iOS/tvOS archive signing to the device SDK ... A global PROVISIONING_PROFILE_SPECIFIER on the xcodebuild command line is applied to every target in the graph, including the shared SwiftPM compiler- plugin macros (OnceMacro/SwizzlingMacro/AssociationMacro). Those build for the macOS host and reject a provisioning profile, so the iOS/tvOS device archives failed at build-description time with "<macro> does not support provisioning profiles". (The macOS archive is immune: its host-SDK macros carry CODE_SIGNING_ALLOWED=NO, so the global specifier is silently ignored there.) Move the signing settings into a generated -xcconfig and condition the profile + identity on the device SDK ([sdk=iphoneos*] / [sdk=appletvos*]). xcconfig conditionals are honored and a command-line -xcconfig outranks target settings, whereas a CLI "SETTING[sdk=..]=val" is mis-parsed — both verified via xcodebuild -showBuildSettings against the real project. The profile now lands on the app/framework slices only; the macosx-host macros get nothing. macOS App Store archive is unchanged (already green; installer cert now present on the runner). tvOS upload may still need tvOS on the App Store Connect record, but that step is continue-on-error. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 12:58:23 +02:00
enricobuehler	8425cd0826	fix(encode): probe each GPU's real max bitrate instead of failing (or blind-capping) ... Root cause of the Mac "session ended" at 880 Mbps / 1.3 Gbps: the host requests a bitrate NVENC can't express at any codec level and `avcodec_open2` returns EINVAL ("Invalid argument"), so the pipeline build fails after 4 identical retries and the session dies at encoder init — before a single video packet (which is why the client's UDP counters never moved). The ceiling is GPU/driver-specific: an RTX 4090 caps HEVC at ~800 Mbps (Level 6.2 High tier) and rejects above it, while an RTX 5070 Ti accepts 1.3 Gbps. Rather than hard-cap every build to a conservative guess (which would needlessly throttle capable cards), open_video now PROBES: open at the requested bitrate, and step down (codec spec ceiling, then 0.75x to a 50 Mbps floor) ONLY when this GPU returns EINVAL. Each GPU runs at its own real maximum — the 5070 Ti keeps 1.3 Gbps, the 4090 lands at 800 Mbps and streams instead of dying. Non-EINVAL failures (no GPU, bad mode, OOM) still surface immediately rather than being masked by retries. Codec::max_bitrate_bps is now just the first step-down candidate, not a clamp. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 09:58:42 +00:00
enricobuehler	9f92dc505b	fix(client/pkg): ship 32MB UDP recv-buffer sysctl with the Linux client ... The client asks the kernel for a 32 MB SO_RCVBUF, but the kernel silently clamps it to net.core.rmem_max — whose default is far too small. A too-small recv buffer is the dominant client-side wall above ~1 Gbps. Measured live (Fedora host -> two clients, real 2.5G LAN, GSO off): a client capped at 4 MB rmem_max dropped 31.6% of a 2 Gbps stream at the receiver, while a 32 MB client delivered the same 2 Gbps at 0.0% loss. The host already shipped this tuning; the client packages didn't (the RPM's %post even referenced the host-only file), so a client-only install streamed lossy at high bitrate. Add scripts/99-punktfunk-client-net.conf (rmem/wmem = 32 MB, distinct filename so host+client can coexist) and ship+apply it from both the .deb (build-client-deb.sh) and the RPM client subpackage (install, %files client, %post client). For reference the full ladder (punktfunk speed-test): 0% loss to 1.5 Gbps on a 4 MB client; 31.6% at 2 Gbps on 4 MB vs 0% at 2 Gbps on 32 MB. iperf3 put the raw link at ~2.35 Gbps TCP / ~2.4 Gbps UDP, so the stack now tracks the wire given a big enough recv buffer. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 08:45:19 +00:00
enricobuehler	4d26f61e40	fix(net/gso): fall back to sendmmsg on EMSGSIZE instead of tearing down ... Enabling PUNKTFUNK_GSO on a host whose egress MTU is below our UDP segment size made every GSO send return EMSGSIZE (code 90, "Message too long") — the kernel validates each GSO segment against the device MTU at send time, which plain sendmmsg does not. EMSGSIZE wasn't in gso_unsupported() (nor is_transient_io), so it propagated as a fatal "send failed — stopping stream" and instantly killed every session the moment GSO was on (observed live: connection fails instantly / speed-test 0 Mbps). Add EMSGSIZE to gso_unsupported() so it latches GSO off for the process and finishes via sendmmsg — the standard "GSO not usable on this path" fallback. Measured after: the same host+path does 1 Gbps at 0.0% loss over the real LAN via sendmmsg (and the host send path sustains a 2 Gbps probe with send_dropped=0), so GSO is a >2 Gbps optimization, not required for 1 Gbps. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 01:06:41 +00:00
enricobuehler	16ccc7c876	fix(net): don't tear the stream down on a connected-UDP ICMP blip (ECONNREFUSED) ... Root cause of the Mac "session ended" at higher bitrates. The video data plane is a *connected* UDP socket; with data-plane hole-punching the path can blip and the kernel surfaces an asynchronous ICMP port-unreachable/reset as ECONNREFUSED / ECONNRESET on a later send or recv. Both the host send loop and the client poll_frame treated that as fatal and tore the session down: ERROR punktfunk_host::m3: send failed — stopping stream error=send_sealed: Io(ConnectionRefused, code 111) <-- observed live That also cascades: a transient ICMP makes the client's poll_frame bail and close its data socket, which makes the host's next send get a *real* ECONNREFUSED, which tears the host side down too — exactly the "broke at 500 Mbps+" report. Fix: classify ECONNREFUSED/ECONNRESET alongside WouldBlock as transient (a lossy drop / "no data this poll"), never a teardown, at every data-path send/recv site (send, send_batch, send_gso, recv, recv_batch x2, recv_batch_x). FEC + the next frame/RFI recover; if the peer is genuinely gone the QUIC control plane's conn.closed() ends the session cleanly (no infinite "stream into the void"). This is the standard connected-UDP rule that ICMP errors are advisory — doubly true with hole-punching. Adds is_transient_io() + a unit test. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 00:54:10 +00:00
enricobuehler	b140cd6837	feat(apple/macos): App Sandbox + entitlements, wire Mac App Store TestFlight ... The Mac App Store requires App Sandbox, which the macOS app didn't declare. App Sandbox is macOS-only (invalid on iOS/tvOS, fails upload validation), so the macOS target now uses a dedicated Config/Punktfunk-macOS.entitlements while iOS/tvOS keep the shared Config/Punktfunk.entitlements (unchanged). The single macOS app is sandboxed for BOTH channels — the Developer ID DMG is codesigned with the same file — so the local build equals what App Store users get. Entitlement set (verified against the code + Apple docs): - app-sandbox, network.client. - network.server: NOT optional despite the client being outbound-only — the sandbox gates the bind() syscall as network-bind, and quinn (quic.rs) + the raw-UDP plane (transport/udp.rs) both bind explicitly, so host->client datagrams never arrive without it (the classic QUIC-under-sandbox trap). - device.audio-input (mic uplink), device.bluetooth + device.usb (Xbox/DualSense controllers over BT/USB via GameController), keychain-access-groups (existing). Omitted: device.hid (undocumented), files.user-selected.* (no pickers), networking.multicast (Bonjour browse is exempt; requesting it breaks signing). CI (release.yml): add a macOS App Store archive+upload-to-TestFlight step mirroring the iOS lane (manual Apple Distribution signing + the 'Punktfunk macOS App Store Distribution' profile, app-store-connect/upload, installer-signed pkg), continue-on-error until the portal prereqs exist; point the Developer ID DMG codesign at the sandboxed entitlements. Docs (ci.md) + clients/apple README updated; the runner additionally needs the macOS platform on the App Store Connect record + the '3rd Party Mac Developer Installer' cert. Verified: signed Debug build embeds exactly the intended entitlements (codesign -d --entitlements), swift build green against the rebuilt xcframework. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 02:39:06 +02:00
enricobuehler	c2ae40ef9e	feat(net/mac): default-on recvmsg_x batched Mac recv + GSO host + longer probe ... The Mac/iOS client's wall around ~380 Mbps on a 2.5 G path is the receive drain, not the transport: a loopback speed-test pushes 380/600/1000 Mbps at 0.0% loss, but Darwin has no recvmmsg(2), so the macOS client was doing one recv() syscall per packet — ~40-90k syscalls/s on one core. When the recv loop can't drain fast enough the kernel socket buffer backs up and drops, which the client sees as a sustained stream stalling/freezing in the 300-400 Mbps range (and an immediate "session ended" when a 500 Mbps+ first keyframe bursts in). - core/transport: flip recvmsg_x (the batched Darwin recv, ~30x fewer syscalls) from opt-in to default ON, opt-out via PUNKTFUNK_RECVMSG_X=0. Keeps the auto-fallback to the scalar loop on any unexpected syscall error. The Apple CI swift-test loopback now exercises this path by default. - packaging/kde host.env: enable PUNKTFUNK_GSO=1 — UDP segmentation offload on the host send path (one sendmsg per ~64 packets), the dominant lever above ~1 Gbps. Already wired (send_sealed -> send_gso) with sendmmsg auto-fallback. - apple SpeedTestSheet: lengthen the bandwidth probe 2 s -> 5 s so the measured number stops swinging wildly (50 vs 900 Mbps on the same link) — long enough for steady-state send + recv drain to settle. Matches host MAX_PROBE_MS. - host capture: PUNKTFUNK_SYNTH_NOISE synthetic high-entropy source for reproducible throughput testing of the encode->FEC->send->recv path. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 00:35:26 +00:00
enricobuehler	c7c08b2855	fix(ci/release): skip Swift macro/plugin validation in archives ... tvOS archive failed 'Macro AssociationMacro/SwizzlingMacro/OnceMacro must be enabled before it can be used' — Xcode 15+ requires interactive trust for SPM Swift macros (objc-runtime-tools, swift-once-macro via swiftui-navigation- transitions), which a headless build can't grant. Add -skipMacroValidation -skipPackagePluginValidation to all three archive commands so CI never hits the trust prompt. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 23:36:36 +00:00
enricobuehler	5bc257f1ae	fix(headless/kde): virtual Punktfunk speaker + restart host with the session ... Audio: a headless host has no speakers, and on a LAN with AirPlay devices PipeWire picks a random HomePod as default — so desktop audio (which the host captures from the default sink's monitor) went to a HomePod over AirPlay instead of to the client, and there was no "Punktfunk" output to select. Ship a `punktfunk-sink.conf` (a `support.null-audio-sink` adapter — NOT the non-existent module-null-sink, which makes pipewire refuse to start) with high priority.session so it's the default; run-headless-kde.sh installs it and restarts pipewire once on first install. The host then captures its monitor and streams it. (Disable AirPlay sinks out of band: `dnf remove pipewire-config-raop`.) Input: the host's libei portal D-Bus connection goes stale when the compositor session restarts the portal under it, and the in-process reopen loop can't recover it (EIS setup keeps timing out) — only a full restart does. Add PartOf=punktfunk-kde-session.service so the host restarts with the session. Both verified live on the Fedora 44 KDE box. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 23:30:36 +00:00
enricobuehler	9c23ad5303	feat(ci/release): add tvOS TestFlight build + use renamed iOS profile ... tvOS is scaffolded (Punktfunk-tvOS target/scheme + build-xcframework BUILD_TVOS). Wire it: install nightly + rust-src (tier-3 -Zbuild-std), build the xcframework with BUILD_TVOS=1, and add a tvOS archive+export+upload step mirroring iOS (manual signing with the 'Punktfunk tvOS App Store Distribution' profile, since the App-Manager ASC key can't cloud-sign). Also point iOS at the renamed 'Punktfunk iOS App Store Distribution' profile. macOS App Store/TestFlight still pending (needs App Sandbox entitlements). Needs tvOS on the App Store Connect app record + the tvOS platform installed on the runner. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 23:23:01 +00:00
enricobuehler	d78bbdffe2	fix(headless/kde): start Xwayland + detect its display so X11 apps work ... X11/Electron apps (Discord — "Missing X Server or $DISPLAY", Steam, many launchers) failed in the headless KWin session: `kwin_wayland --virtual` starts NO X server unless asked, and even with one KWin reserves the X11 display + starts Xwayland *on demand* (no Xwayland process or "Using public X11 display" log line until the first client connects) — so the old detection (pgrep the Xwayland process) found nothing and never exported DISPLAY. Two fixes: pass `--xwayland`, and detect the display from the reserved /tmp/.X11-unix/X<N> socket (with the log + process checks as fallbacks). Verified live on the Fedora 44 KDE box: DISPLAY=:0 lands in plasmashell + the activation env and xdpyinfo responds, so menu-launched X11 apps open a display. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 23:17:56 +00:00
enricobuehler	5c1aa453c1	fix(ci/release): quit Xcode before iOS build so it can't prune the profile ... A running Xcode.app manages ~/Library/Developer/Xcode/UserData/Provisioning Profiles/ and deletes manually-installed (unrecognized) distribution profiles — which is why the App Store profile vanishes. Quit Xcode at the start of the iOS step so the manually-installed 'Punktfunk App Store Distribution' profile survives for manual signing; headless xcodebuild doesn't need the GUI app. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 22:02:44 +00:00
enricobuehler	53e3f1e4e6	fix(ci/release): iOS manual App Store signing (App-Manager key can't cloud-sign) ... macOS Developer ID + notarize + DMG now works with the clean login-keychain workflow. iOS export failed with 'Cloud signing permission error' — with -allowProvisioningUpdates Xcode forces cloud-managed signing, which the App-Manager-role ASC key can't authorize. Switch iOS to MANUAL signing with the local (valid) Apple Distribution identity + the 'Punktfunk App Store Distribution' provisioning profile; ASC key stays only for the upload. Profile must be installed via Xcode -> Accounts -> Download Manual Profiles. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 21:52:50 +00:00
enricobuehler	31b04a2ab8	refactor(ci/release): xcodebuild-native signing via login keychain ... The runner now runs as a user LaunchAgent in the logged-in Aqua session, so it uses the login keychain directly, where Developer ID Application + Apple Distribution are installed and VALID (the missing WWDR intermediate — the real root cause of the whole iOS saga — is now present). Delete all the throwaway- keychain / secret-cert-import / raw-keychain-plumbing / Xcode-quit / diagnostic machinery: macOS = archive-unsigned + a single Developer ID codesign + notarize/ DMG; iOS = standard xcodebuild archive + export with -allowProvisioningUpdates (automatic signing manages the App Store cert + profile). Only ASC_API_KEY_* secrets remain; DEVID_CERT_*/IOS_DIST_CERT_*/IOS_PROFILE_B64 no longer needed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 21:42:47 +00:00
enricobuehler	e4b10f057a	fix(headless/kde): make libei input work headlessly — portal + pre-seeded RemoteDesktop grant ... On a headless KDE appliance, libei input injection silently failed: the EIS socket comes from the xdg RemoteDesktop portal, which never came up, and even up it would pop an unanswerable "Allow remote control?" dialog. Three fixes in run-headless-kde.sh, all idempotent + safe on the dev box: - Reach graphical-session.target: xdg-desktop-portal is ordered behind it and its start job fails without it, but a headless linger session never gets there and Fedora's target has RefuseManualStart=yes — drop that in once, then start the target. - Start the portal with `start` (the old `try-restart` is a no-op when inactive — the first-boot case), so it actually comes up. - Pre-seed the RemoteDesktop grant: vendor the `kde-authorized` permission-store GVariant DB and copy it to ~/.local/share/flatpak/db/ (never clobbering an existing one), so the portal grants RemoteDesktop without a dialog. Shipped by the RPM + .deb. Diagnosed + fixed live on the Fedora 44 KDE box: libei devices RESUME and emit (MouseMove/keys). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 21:22:20 +00:00
enricobuehler	fb1443650b	style: rustfmt the kwin virtual-primary helpers ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 21:05:01 +00:00
enricobuehler	a3a3dfc85b	fix(vdisplay/kwin): make the streamed output the sole desktop (PUNKTFUNK_KWIN_VIRTUAL_PRIMARY) ... On a headless KDE appliance the session has two outputs — run-headless-kde.sh's `kwin --virtual` bootstrap (where plasmashell draws by default) and our per-session streamed output — so the client saw only the wallpaper of an empty extended output (the KWin analogue of the GNOME/Mutter VIRTUAL_PRIMARY issue). New opt-in PUNKTFUNK_KWIN_VIRTUAL_PRIMARY: after creating the virtual output, set it primary via kscreen-doctor (KWin then re-homes the desktop onto it and disables the bootstrap), then belt-and-suspenders disable anything still enabled. The keepalive re-enables the bootstrap on teardown — though KWin also auto-re-enables it when our output is reclaimed, so there's never a zero-output window. Set in packaging/kde/host.env. Verified live on the Fedora 44 KDE box: mid-session the streamed output is the sole desktop at 0,0; post-session the bootstrap is back. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 21:04:29 +00:00
enricobuehler	822988029c	diag(ci/release): sign iOS by identity hash + max-verbose codesign ... The throwaway-keychain codesign still fails 'unable to build chain to self-signed root / errSecInternalComponent' despite cert/chain/key all verifying. Sign by the Apple Distribution identity's SHA-1 hash (eliminates name-matching ambiguity, a known cause) and run codesign --verbose=4 + print valid/matching identities at sign time, to surface the exact failure on the next run. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 20:29:45 +00:00
enricobuehler	596c92f785	fix(ci/release): re-set key partition list + stage full chain before iOS codesign ... iOS codesign still failed with 'unable to build chain to self-signed root / errSecInternalComponent' after the keychain re-assert. verify-cert proves the chain is trusted, so this is the private-key ACL (errSecInternalComponent is classically that) and/or codesign not finding the chain certs in the identity's keychain. Right before the iOS codesign: re-run set-key-partition-list (re-grant codesign access to the key) and import the WWDR G3 intermediate + Apple Root CA into the throwaway keychain so the full leaf->WWDR->root chain is present there. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 20:22:27 +00:00
enricobuehler	ecfef43040	fix(ci/release): re-assert keychain before the iOS codesign ... The iOS archive SUCCEEDS now (raw-codesign path), but codesign failed with 'unable to build chain to self-signed root / errSecInternalComponent'. Cause: xcodebuild archive (run in the same step, just before codesign) resets the user keychain search list, so codesign can no longer find the WWDR intermediate that lives only in the throwaway keychain. The macOS sign avoids this by running in a separate step after its re-assert. Re-assert the search list + default keychain (and unlock, via KEYCHAIN_PASS now exported to GITHUB_ENV, masked) immediately before the iOS codesign. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 20:08:56 +00:00
enricobuehler	9338a8797d	style: rustfmt the connect_via_punch match guard ... cargo fmt --all --check failed CI on the long match-arm guard in UdpTransport::connect_via_punch; apply the formatter's wrapping. No behavior change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 19:56:25 +00:00
enricobuehler	97d4300d50	feat(ci/release): iOS — raw codesign + altool upload (bypass xcodebuild) ... xcodebuild's signing-identity selection enforces an online revocation/OCSP check that excludes the freshly-minted Apple Distribution cert (find-identity -v drops it) even though verify-cert confirms it's valid and codesign signs with it fine. So sign iOS the same way as the macOS DMG: archive CODE_SIGNING_ALLOWED=NO, embed the profile, raw 'codesign --keychain' with the profile's entitlements (extracted via plutil), package the .ipa, and upload with 'xcrun altool --upload-app'. Drops the xcodebuild manual-signing path entirely — no profile-dir install, no Xcode-quit, no provisioning-profile discovery. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 19:53:14 +00:00
enricobuehler	b547b9d92f	fix(ci/release): quit Xcode.app so it stops pruning the iOS profile ... Root cause of 'No profile matching Punktfunk App Store Distribution': the GUI Xcode.app was running on the runner and actively manages ~/Library/Developer/Xcode/UserData/Provisioning Profiles, pruning our manually-installed App Store profile from the exact dir xcodebuild reads, right before signing (the legacy ~/Library/MobileDevice copy survives but Xcode 26's xcodebuild doesn't read it). Quit Xcode.app at the top of the iOS signing block; xcodebuild runs independently and headless CI doesn't need the GUI app. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 19:25:33 +00:00
enricobuehler	ec617f9c6b	bench(ci): report-only regression harness — Tier-1/2 in CI + Tier-3 GPU runner ... - scripts/bench/compare.py: diff criterion medians (target/criterion/**/estimates.json) vs a committed baseline, print a markdown table to the job summary, flag >threshold regressions, always exit 0 (shared CI hardware is too noisy to gate on). --update rewrites the baseline. - ci.yml `bench` job: runs Tier-1 (criterion) + Tier-2 (loss-harness FEC recovery) GPU-free in the rust-ci container, then compare.py — report-only visibility per push/PR. - scripts/bench/gpu-stream.sh + bench-gpu.yml: Tier-3 real pipeline (virtual output → zero-copy → NVENC → punktfunk/1 → reassemble) on a self-hosted GPU runner; captures encode_us/tx_mbps/ send_dropped + client capture→reassembled latency, compares to gpu-baseline.json (20% threshold). Needs the dev box registered as a `[self-hosted, gpu]` act_runner (one-time, see the workflow header) — the dedicated hardware makes its absolute baseline meaningful, unlike shared CI. - baseline.json: dev-box Tier-1 numbers. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 19:24:52 +00:00
enricobuehler	2976daf2e3	diag(ci/release): dump provisioning-profile dirs around the iOS archive ... iOS manual signing fails 'No profile matching Punktfunk App Store Distribution' despite the profile being installed (content verified: right name/team/iOS/app-id). The profile is in ~/Library/MobileDevice but Xcode 26 reads ~/Library/Developer/Xcode/UserData/Provisioning Profiles, which is empty. Print both dirs before the archive and again at failure to confirm whether Xcode regenerates/prunes the UserData copy during the build. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 19:23:16 +00:00
enricobuehler	71f26083a6	bench(core): Tier-1 criterion microbenchmarks for the punktfunk/1 hot path ... GPU-free, so they run in normal CI. Two layers: crypto/{seal,seal_in_place,open} on one MTU shard, and pipeline/{gf8,gf16}/{64KB,1MB} — a whole frame through the real per-frame path end to end over the loopback transport (FEC encode → AES-GCM seal → packetize → reassemble → FEC decode → open). Baselines on the dev box (RTX 5070 Ti VM): AES-GCM ~1.57 GiB/s/shard; gf16 ~418 MiB/s at 1 MB vs gf8 ~23 MiB/s (the GF(2^8) O(n^2) ceiling the GF(2^16) Leopard wall-breaker removes — exactly the kind of regression this should catch). The GPU capture/NVENC path is out of scope here (Tier 3). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 19:18:40 +00:00
enricobuehler	46572b4a25	fix(ci/release): robust iOS provisioning-profile extraction + diagnostics ... The profile-name/UUID read used 'security cms -D ... || true' which masked a failed decode, then PlistBuddy printed 'Error Reading File' to stdout and that got captured as the UUID, producing a garbage cp path. Now: check the extracted plist is non-empty, fall back to 'openssl smime' if 'security cms' fails, validate the UUID is actually hex+dashes, and print the decoded byte count + decoder stderr + first bytes so a bad IOS_PROFILE_B64 is obvious in-log. Still non-fatal (skips iOS, never blocks the macOS release). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 19:05:35 +00:00
enricobuehler	7ec91aec2d	feat(punktfunk/1): cross-VLAN/NAT video via data-plane hole-punching ... The video data plane is a raw UDP socket separate from the QUIC control connection. On a flat LAN the host can send straight to the client, but across NAT or a stateful inter-VLAN firewall the unsolicited host→client video is rejected (ICMP port-unreachable → the session dies immediately, while control/audio/input keep working since they ride the client-initiated QUIC). Observed live: a client on 192.168.6.2 streaming from a host on 192.168.1.48. Fix: client-initiated hole-punching. The client sends PUNCH_MAGIC datagrams from its data socket to the host's advertised data port (Welcome.udp_port); that opens the firewall/NAT return path and lets the host learn the client's OBSERVED source (the NAT-translated address, not the client's reported private one). The host (UdpTransport::connect_via_punch) waits ≤2.5s for the first punch and streams there, falling back to the client-reported address for clients that don't punch (flat-LAN behaviour unchanged). The client keeps a low-rate keepalive so a stateful firewall's idle timeout can't close the path during a static, low-bitrate scene. Wired into client-rs and the NativeClient connector (covers the Linux + Apple clients; the Apple app needs an xcframework rebuild to pick up the new core). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 18:46:15 +00:00
enricobuehler	268733f968	fix(headless/kde): find the probe binary on PATH for packaged installs ... run-headless-kde.sh gated KWin readiness on `$ROOT/target/release/punktfunk-host probe-compositor`, else `cargo run`. On an RPM/.deb install ROOT resolves to /usr/share (no target/ tree) and there's no Cargo.toml either, so the probe could never succeed: the session unit hit its 30s readiness timeout, exited, and systemd restart-looped it forever — KWin never reached the plasmashell step, so the streamed virtual output was an empty black desktop. Add a `command -v punktfunk-host` branch (the packaged /usr/bin binary) between the source-tree and cargo-run fallbacks. Verified live on the Fedora 44 KDE host: session goes stable (NRestarts 0), plasmashell comes up, and a client streams the real desktop. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 18:21:31 +00:00
enricobuehler	0fc3012954	feat(ci/release): iOS App Store manual distribution signing + profile ... Automatic signing during the iOS archive resolved to App *Development* (wanted an Apple Development cert + tried to revoke the account's orphaned one, and no dev profile) — wrong for App Store. Switch to MANUAL distribution signing: import an App Store provisioning profile from IOS_PROFILE_B64, read its Name/UUID, install it, and archive with CODE_SIGN_STYLE=Manual + Apple Distribution + that profile; export with manual signingStyle + provisioningProfiles map. Step self-skips until IOS_PROFILE_B64 is set. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 17:09:46 +00:00
enricobuehler	6aa57ffd7b	fix(ci/release): gate iOS signing on matching identity, not find-identity -v ... The Apple Distribution identity has its key + intermediate + valid dates (it's in 'Matching identities') but stayed out of 'Valid identities only' — a trust strictness (most likely a pending online revocation check on an hour-old cert) that codesign/xcodebuild do NOT enforce. Gate the iOS step on the MATCHING list so the archive actually attempts signing, and print 'security verify-cert -p codeSign' in the import step so the exact trust verdict shows if it still balks. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 16:30:57 +00:00
enricobuehler	eb5d282936	fix(ci/release): retry Apple intermediate fetch + chain/clock diagnostic ... The iOS Apple Distribution identity imported WITH its private key (it's a 'Matching identity') but was dropped from find-identity -v — i.e. an untrusted chain: the WWDR G3 intermediate it chains through didn't land, while Developer ID's DeveloperIDG2CA did. The fetch was a single 'curl || warn' with no retry, so a transient miss silently breaks iOS only. Retry each intermediate 3x, and print the runner UTC date + whether the WWDR intermediate is present, to separate a chain miss from the cert's notBefore being ahead of the runner clock. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 16:22:32 +00:00
enricobuehler	59e91820eb	ci+docs: Fedora 44 RPM channel + reproducible Fedora KDE host guide ... - docker.yml: build the punktfunk-fedora44-rpm builder image (parameterized Dockerfile, FEDORA_VERSION=44) alongside the F43/Bazzite one. - rpm.yml: matrix the build/publish over both channels — fedora-fedora-rpm→bazzite (F43, libavcodec.so.61) and fedora44-rpm→fedora-44 (F44, libavcodec.so.62). fail-fast:false so one channel's break doesn't sink the other. (Bootstrap: the F44 builder image must be pushed by docker.yml once before rpm.yml's fedora-44 job can pull it — same dance as the other images.) - fedora-kde.md: rewrite as the reproducible RPM-install guide validated live on a Fedora 44 KDE box (RTX 4090): RPM Fusion + akmod-nvidia + the ffmpeg-free→RPM-Fusion swap for NVENC + Secure Boot MOK enroll; the fedora-44 dnf repo + `dnf install punktfunk`; and the headless punktfunk-kde-session.service (kwin --virtual with NO_PERMISSION_CHECKS — an interactive Plasma session won't hand its privileged zkde_screencast protocol to an external client). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 16:20:40 +00:00
enricobuehler	ef13c0fa97	fix(ci/release): self-diagnosing iOS cert import + non-fatal validity gate ... The iOS Apple Distribution cert imported (1 identity imported) but never appeared in find-identity -v, and the iOS step then silently skipped. Make the import step explain itself without exposing secrets or blocking the macOS release: print secret byte-lengths + decoded p12 size + import rc, strip stray whitespace/newlines before base64 -d, and after the partition-list warn (not fail) with the likely cause + an incl-invalid identity list when the iOS secret is set but yields no valid Apple Distribution identity. The shared import step must not hard-fail on an iOS-cert problem — that would also block the proven macOS DMG path. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 16:14:12 +00:00
enricobuehler	38b7507440	packaging(rpm): Fedora 44 build + ship the KDE session unit & host.env ... Three changes to make a reproducible Fedora KDE host install: - ci/fedora-rpm.Dockerfile: parameterize the Fedora base (ARG FEDORA_VERSION, default 43) so the same builder produces the Bazzite (F43, libavcodec.so.61) and Fedora 44 (libavcodec.so.62) RPMs. A binary RPM is soname-coupled to its base, so each target Fedora needs its own build/channel. - spec: install punktfunk-kde-session.service (was in the tree but never packaged) with its ExecStart repointed from the dev source tree to the installed run-headless-kde.sh. This is the headless `kwin --virtual` session (KWIN_WAYLAND_NO_PERMISSION_CHECKS=1) the kwin backend needs — an interactive Plasma session refuses to hand its privileged zkde_screencast protocol to an external client, so a dedicated session is required. Not enabled by default (kwin hosts opt in). - ship packaging/kde/host.env as host.env.kde — the ready KWin appliance config (wayland-kde). Validated live on a Fedora 44 KDE box (RTX 4090): KWin virtual output + zero-copy dmabuf->CUDA->NVENC. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 16:08:10 +00:00
enricobuehler	afed2206ab	feat(ci/release): wire iOS App Store signing via an Apple Distribution secret ... Prepares the iOS/TestFlight path. The runner has the iOS 26.5 SDK but no signing identities, so import an Apple Distribution cert+key from IOS_DIST_CERT_P12_B64 / IOS_DIST_CERT_PASSWORD into the same throwaway keychain (the WWDR intermediates already fetched chain it). The iOS archive uses automatic signing (-allowProvisioningUpdates + the ASC key creates/downloads the App Store profile against the present cert, so no keychain-write that would hit the macOS -61). Re-assert the keychain on the search list like the macOS sign step. Until the secret is set the step self-skips with a warning, so it stays green. Still needs an App Store Connect app record for io.unom.punktfunk to upload. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> v0.1.1	2026-06-13 15:09:56 +00:00
enricobuehler	39a49da567	fix(ci/release): skip iOS archive cleanly when the iOS SDK is absent ... The macOS Developer ID DMG path is green (signed + notarized + stapled). The iOS/TestFlight step (already best-effort + continue-on-error) was failing on this runner with 'iOS 26.5 is not installed' — the iOS platform SDK is a separate Xcode component that isn't installed. Guard the step on `xcodebuild -showsdks | grep iphoneos` and exit 0 with a warning when it's missing, so runs are unambiguously green. Install on the runner with `xcodebuild -downloadPlatform iOS` when iOS goes live. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 14:51:09 +00:00
enricobuehler	e64aefa25c	fix(ci/release): scope codesign to the throwaway keychain (--keychain) ... codesign --sign 'Developer ID Application' reported 'no identity found' even though the import step's find-identity saw it: the bare lookup relies on the default keychain search list, which doesn't reliably carry the throwaway keychain across steps on this runner. Re-assert the search list + default keychain in the signing step and pass --keychain "$KEYCHAIN" so the identity search is scoped to it (it stays unlocked with a codesign-allowed partition list from the import step, so no password is needed). Adds a find-identity diagnostic right before signing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 14:43:33 +00:00
enricobuehler	4d93eb24ff	fix(ci/release): archive unsigned + codesign Developer ID directly ... xcodebuild's archive gate demands a provisioning profile for the app's keychain-access-groups entitlement (the 'Keychain Sharing' capability) under both automatic AND manual signing — even though a Developer ID app honours that team-prefixed entitlement at runtime with no profile. So manual signing just traded the -61 keychain error for 'requires a provisioning profile'. Sidestep the gate: archive with CODE_SIGNING_ALLOWED=NO, then codesign the app bundle directly with the Developer ID identity, hardened runtime and a secure timestamp, applying the entitlements via --entitlements (with $(AppIdentifierPrefix) resolved to the team prefix, which codesign won't expand). Safe because the bundle is a single statically-linked binary — static PunktfunkCore.xcframework, SPM static products, macOS 14 target, no Embed-Frameworks phase — so there is no nested code to sign inside-out. No Apple Developer portal profile or new secret needed. iOS App Store path unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 14:35:16 +00:00
enricobuehler	3c617f655e	fix(ci/release): sign the macOS archive with Developer ID, not auto dev signing ... The cert import now yields a valid 'Developer ID Application' identity, but the macOS `xcodebuild archive` step still inherited the project's automatic 'Apple Development' signing via -allowProvisioningUpdates. That made Xcode try to mint an Apple Development cert (install fails in the CI keychain, DVTSecErrorDomain -61 'Write permissions error') and locate a 'Mac App Development' provisioning profile for io.unom.punktfunk (none exists) — ** ARCHIVE FAILED ** before signing even happened. A Developer ID DMG needs neither: pin CODE_SIGN_STYLE=Manual + the Developer ID identity + no profile, mirroring what the export step already does. The app is non-sandboxed and its only entitlement (keychain-access-groups, team-prefixed) is authorized by the Developer ID team, so no provisioning profile is required. ENABLE_HARDENED_RUNTIME=YES is already set, so notarization stays happy. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 13:46:00 +00:00
enricobuehler	7f18b3dcd0	fix(ci): install ca-certificates in the bun web/docs-site jobs ... The oven/bun:1 image is Debian-slim and ships no CA bundle, so actions/checkout's git-over-HTTPS fetch died with 'Problem with the SSL CA cert (path? access rights?)' — curl error 77 (no CA bundle file), not an untrusted cert; git.unom.io serves a public Let's Encrypt cert. The rust/deb/rpm builder images already install ca-certificates; do the same in the two slim bun jobs. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 13:36:22 +00:00
enricobuehler	8970cfe188	style(vdisplay/mutter): drop trailing blank line (rustfmt --check) ... The stray blank line after build_primary_config tripped cargo fmt --all --check in CI. Formatting only, no code change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 13:36:22 +00:00
enricobuehler	263eab31e3	fix(m3): release held mouse buttons/keys when a session ends (stuck-click after reconnect) ... The pointer/keyboard injector is host-lifetime (one EIS connection for every punktfunk/1 session), so its existing release_all only fires on EIS disconnect — never when a *client* session ends. A button still down at an abrupt client disconnect therefore stayed latched in the compositor: Mutter keeps the destroyed press's implicit pointer grab, so after reconnect a stuck left-button-down turns every motion into a drag (windows move, text selects) while a fresh click's press is swallowed — clicking buttons and text inputs does nothing. Only the one held button is affected; keyboard and the other buttons are fine, exactly as reported. Fix: input_thread now tracks the buttons/keys the client holds and, when the session ends, synthesizes the matching up-events through the host-lifetime injector (whose EIS connection — and the dangling grab — outlive the session). Backend-agnostic (normal inject path), so it covers libei/EIS, wlr and uinput alike. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 13:31:15 +00:00