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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
- 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>
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>
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>
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>
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>
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>
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>
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>
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>
- 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
The libei backend forwarded mouse wheel only via scroll_discrete (120-per-detent).
Mutter floors a sub-detent delta — a trackpad, a precise/high-res wheel, or a
fractional smooth-scroll event — to zero whole clicks, so small scrolls never land and
you have to spin the wheel a lot before anything moves. Emit the continuous `scroll`
axis (logical px, ~15 px/detent) alongside the discrete steps, matching the wlroots
backend's 15-px/notch behaviour, so every delta moves proportionally while full
detents still drive line/page scrolling.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
After a session ends, the Mutter backend (with PUNKTFUNK_MUTTER_VIRTUAL_PRIMARY=1)
re-asserted the physical monitor layout with an explicit ApplyMonitorsConfig. On
Mutter 50 + NVIDIA that monitor reconfig — issued while the just-removed high-refresh
virtual output is still tearing down — SIGSEGVs gnome-shell. Observed live on
home-worker-3: the teardown ApplyMonitorsConfig returns "recipient disconnected from
message bus" (the shell died mid-call), GDM's crash-loop guard then drops to the
greeter and STAYS there, so org.gnome.Mutter.RemoteDesktop/DisplayConfig vanish and
every subsequent reconnect fails with RemoteDesktop.CreateSession ServiceUnknown —
i.e. "after a disconnect I can't reconnect anymore."
make_virtual_primary applies an APPLY_TEMPORARY config, which Mutter reverts on its
own once the virtual output disappears and our DisplayConfig connection closes. So the
explicit restore was both redundant and the crash trigger: drop it, drop the dc_pre
connection at teardown, and let Mutter revert the temporary config itself. Setup is
unchanged (the virtual output is still made primary so the desktop lands on the
streamed surface). Removes the now-unused to_apply_logicals/apply_config helpers.
Verified live on home-worker-3 (5120x1440@240, VIRTUAL_PRIMARY=1): 6/6 back-to-back
connect/disconnect cycles streamed cleanly with gnome-shell holding the same PID
throughout (previously it crashed within the first few disconnects).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Saved host cards now show a presence dot — green when the host is advertising on
the LAN right now, grey when not seen. Cross-references each StoredHost against the
live mDNS discovery set (HostDiscovery). No host changes: the host already
advertises _punktfunk._udp with a stable id + cert fingerprint, which the client
already browses.
- StoredHost.matches(DiscoveredHost): fingerprint-first (survives a DHCP address
change), address:port fallback. The discovered-section dedup now uses the same
match, so a saved host whose IP changed no longer also shows up as a stranger.
- HostCardView gains an isOnline presence dot (accessibility-labelled).
- HomeView.isOnline recomputes on every @Published discovery change, so the dot
tracks hosts joining/leaving the network live.
Online detection is LAN-scoped by design: a remote/cross-subnet host that doesn't
advertise here shows grey ("not seen"), not a false "offline". Swift-only.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Live confirmation on worker-3: the flash was Mutter's CORRUPTED, size-0
cursor-update buffers (chunk_flags=CORRUPTED) carrying recycled old frames —
drained=1 always, so latest-frame-only draining wasn't the lever, the CORRUPTED
skip was (OBS issue 8630). Demote the verbose drain diagnostic to a rate-limited
debug line and document the root cause inline. Validated: zero-copy back on GNOME
(dmabuf->CUDA, 5120x1440) AND flash-free with FORCE_SHM off.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Deep research (OBS Studio's linux-pipewire, Mutter bug tracker) found the GNOME
stale-frame flash is a buffer-RECYCLING race, not damage (Mutter sends whole
frames, no SPA_META_VideoDamage) and not buffer count. OBS's proven fix is
latest-frame-only dequeue: each process callback, drain ALL queued PipeWire
buffers, requeue the older ones, and consume only the NEWEST — plus skip
CORRUPTED buffers. Our code dequeued one buffer per callback (oldest-first) and
the bounded channel dropped the NEWEST when full, so during Mutter's bursty
delivery the encoder got stale frames → the flash.
Switch the process callback to raw dequeue_raw_buffer + drain-to-newest (requeue
older), extract the consume logic into consume_frame(spa_buf) sourcing datas via
the transparent Data cast, skip SPA_META_HEADER_FLAG_CORRUPTED / CORRUPTED-chunk
buffers (size-0 skip kept SHM-only so dmabuf isn't regressed), and remove the
earlier content-hash drop heuristic (it couldn't tell stale re-deliveries from
legit repeating content). Diagnostic logs drain depth + chunk/header flags.
Reverts none of the FORCE_SHM / dmabuf_fence work.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Instrumented worker-3: even on the ordered FORCE_SHM download path, Mutter
re-delivers COMPLETE OLD pool buffers — 655 frames in a 15 s session whose content
exactly matched an earlier frame (not damage-incremental; full old frames, in
runs, ~45% during motion). NVIDIA gives no fence to prevent it, so the producer
delivery can't be made clean from our side.
Detect it and drop it: hash a spatial sample of each captured frame; a frame whose
content equals an EARLIER distinct frame (vs the current one, whose duplicates pass
through) is a stale re-delivery — skip it so the encoder never emits the flash
(try_latest re-sends the last good frame; brief hold instead of a backward jump).
Runs on the CPU/SHM path (where Mutter+NVIDIA capture lives); never triggers on
static content or non-Mutter compositors (no reverts). PUNKTFUNK_KEEP_STALE=1
disables it for A/B.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
scripts/punktfunk-host.service is dev-oriented — its ExecStart references the
source tree (%h/punktfunk/target/release/punktfunk-host). When the deb/rpm ship
it to /usr/lib/systemd/user, a fresh install with no hand-rolled unit would try
to run a binary that isn't there. Rewrite the ExecStart to the installed
/usr/bin/punktfunk-host during packaging (sed in build-deb.sh + the spec); the
source unit stays as-is for from-source dev. Hosts with a custom ~/.config unit
(which shadows the packaged one) are unaffected.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
cbindgen swept transport/udp.rs's `recvmsg_x` foreign import and its `MsghdrX`
#[repr(C)] struct into the generated C header — they're internal Apple-only FFI,
not part of the public C ABI, and reference socklen_t/ssize_t/iovec which the C
ABI harness doesn't include, so c_abi_harness_round_trips failed to compile.
Add them to cbindgen.toml export.exclude and regenerate the header.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Empirically, Mutter+NVIDIA dmabuf capture has NO working GPU sync — confirmed on
worker-3: explicit sync fails buffer alloc (EINVAL, no cogl sync_fd), and the
dmabuf carries no implicit fence (EXPORT_SYNC_FILE waited=false). So any dmabuf
read — zero-copy import OR mmap — races Mutter's render and flashes the buffer's
previous frame. The prior "CPU fallback" still listed DmaBuf in its buffer types,
so Mutter kept handing dmabufs and it never fixed anything (got worse).
PUNKTFUNK_FORCE_SHM=1 offers MemPtr+MemFd ONLY (no DmaBuf), forcing Mutter to
glReadPixels-download into mappable memory — which orders against its render, so
the frame is complete + current by construction (race-free). Costs the download
(~3 ms) + zero-copy; correct at 1080p/4K60. KWin/gamescope are unaffected (they
blit into the buffer, no read-before-render race) and keep zero-copy.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The previous attempt (97ee75d) dropped zero-copy on Mutter+NVIDIA for a sticky
CPU/SHM fallback that (a) still listed SPA_DATA_DmaBuf in its buffer types, so
Mutter kept handing dmabufs that got mmap-read UNsynced — making the flashing
worse, not better — and (b) hinged on producer explicit sync, which Mutter+NVIDIA
cannot do (`error alloc buffers` / no cogl sync_fd, confirmed in worker-3 logs).
Revert the capture restructure to the original zero-copy dmabuf path, and fix the
NVIDIA stale-frame race the RIGHT way for a producer that can't do explicit sync:
the consumer snapshots the dmabuf's implicit fence (DMA_BUF_IOCTL_EXPORT_SYNC_FILE)
and waits the producer's render before sampling (new dmabuf_fence module, ioctl
number unit-tested). Covers the GPU import and the CPU mmap read. Logs once whether
a render was actually in flight (waited=true → the driver fences and the race is
closed; false → no implicit fence, so we learn zero-copy still needs SHM here).
drm_sync (the explicit-sync primitive) is kept and verified but marked unused —
no targeted compositor produces a usable sync_fd today; ready to wire in when one
does. The Bug-2 input fix (held-key release on disconnect) from 97ee75d is kept.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
enricobuehler