1717 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	16fa43da40	ci(encode): lint and test the feature-gated encode backends ... pf-encode's GPU backends are off by default, so almost none of them were under `-D warnings`: - ci.yml lints/tests with default features, which do cover VAAPI, libav-NVENC and — via punktfunk-host's `default = ["pyrowave"]` — the PyroWave backends, but not `nvenc` or `vulkan-encode`. - deb.yml builds those two, but with `cargo build`, where warnings are not errors. That left enc/linux/nvenc_cuda.rs, enc/linux/vulkan_video.rs and the vendored vk_av1_encode / vk_valve_rgb bindings — ~8,150 lines carrying ~70 `unsafe` blocks — never linted anywhere, so the crate's own `#![deny(clippy::undocumented_unsafe_blocks)]`, its stated unsafe-proof gate, was never actually enforced on them. Linux gains a clippy+test leg at the SHIPPED feature set: deb.yml builds `punktfunk-host/nvenc,punktfunk-host/vulkan-encode` WITHOUT `--no-default-features`, so the .deb carries pyrowave too and that combination is what deserves the lint. GPU-free — the hardware tests are `#[ignore]`d and NVENC/CUDA dlopen their entry points, so the test binary links with no driver. Windows gains a separate `-p pf-encode --all-targets` lint. The existing lint is `-p punktfunk-host`, which never builds pf-encode's test targets — the blind spot that let the Linux twin's tests rot. It must be clippy rather than `cargo test`: on MSVC nvidia-video-codec-sdk link-imports NvEncodeAPICreateInstance / NvEncodeAPIGetMaxSupportedVersion, so a test binary cannot link without the driver's import lib. clippy type-checks without linking; ci.yml runs the tests. `--all-targets` is load-bearing, not decoration: without it the feature-gated `#[cfg(test)]` modules are never compiled at all. Also widens windows-host.yml's paths filter, which listed `crates/pf-encode/**` but none of the crates it compiles against (pf-frame, pf-gpu, pf-zerocopy, pf-host-config, pf-capture, ...), so a change reaching the Windows host through one of those triggered no Windows build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 5	07348c0175	refactor(encode): drop the crate-wide allow(dead_code) ... Inherited from the pre-extraction host crate root as scaffolding for backend paths defined ahead of the build that used them. A census across every feature combination on both platforms (flip it to `warn`, rebuild) found it was hiding exactly two items — so it bought nothing while blinding the crate to future rot: - `vaapi::fourcc` — superseded by `pf_frame::drm_fourcc`; no call sites left. - `vulkan_video::open_opts` — test-only (the smoke tests use it to pass the RGB-direct request explicitly rather than through the env), now `#[cfg(test)]`. Removing it surfaced a real latent defect the Linux census could not see: `amf.rs`'s `percentile` / `drive_and_measure` helpers are used only by the `#[cfg(feature = "amf-qsv")]` latency A/B benchmark, so a `--features nvenc,qsv` build compiled the helpers with their caller gated out. They now carry the same gate as their caller. Verified `--all-targets -D warnings` on Linux (no features; shipped nvenc+vulkan-encode+pyrowave) and Windows (no features; pyrowave; qsv; nvenc,qsv). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 5	e30551b1e2	fix(encode/nvenc-linux): unrot the direct-NVENC test module ... All ten `NvencCudaEncoder::open` call sites in the `#[cfg(test)]` module passed 9 arguments to a 10-parameter function: `cursor_blend` was added to `open` and the tests were never updated. The module has been uncompilable ever since — `cargo clippy -p pf-encode --features nvenc --all-targets` fails with 10x E0061. Nothing in CI noticed because no job compiles this crate's feature-gated test targets: ci.yml lints/tests with default features (which do not include `nvenc`), and windows-host.yml lints `-p punktfunk-host`, which builds pf-encode as a dependency and so never builds its test targets. The CI commit below closes that gap; this has to land first or that leg starts red. `false` is what these tests exercised before `cursor_blend` existed: every frame they build sets `cursor: None`, and there is no cursor-blend test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Fable 5	8d5a9f66c9	fix(gamescope): ship a packaged privilege path for the DM-stop takeover ... Field report (Nobara, 0.19.2): entering Game Mode mid-stream left the monitor on and the stream mirroring at the desktop's resolution. Root cause: the DM-flavor takeover needs privilege to stop plasmalogin, the polkit rule is a docs-only manual step nobody installs, so every managed entry silently degraded to ATTACH — and with a physical display connected the attach path mirrors the box's own session at its own mode. Ship the privilege with the packages instead: a root helper (libexec/punktfunk/pf-dm-helper, verbs stop|restore) behind its own polkit action (io.unom.punktfunk.dm-helper, allow_any — the same mechanism Nobara's os-session-select uses, and the helper derives the DM unit from the display-manager.service symlink itself so callers never name a unit across the privilege boundary). The host tries the plain system-bus verbs first (root / operator rule still take precedence), then pkexec's the helper; the restore paths (idle restore + in-stream desktop-switch honor) use the same ladder so a takeover that needed the helper can always be undone by it. Packaged in rpm/deb/arch (Arch under /usr/lib/punktfunk with the policy's exec.path annotation rewritten; the host probes both layouts). Nix is left out deliberately: store paths can't match the probe, NixOS keeps the manual rule. Docs updated — the rule snippet stays as the scoped alternative. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 23:41:29 +02:00
enricobuehlerandClaude Opus 5	5c7a9407ff	fix(windows/web): start the console once its inputs exist, and verify it started ... A fresh install left PunktfunkWeb registered but not running: `web setup` waited only for the mgmt token before firing `schtasks /run`, while `web-run.cmd` also requires the host identity cert — and the host writes the token during argument parsing but `cert.pem` only after the pure-Rust RSA-2048 keygen inside `serve`. The launcher lost that race, exited 1, and since the task carried no trigger but boot (Task Scheduler does not reliably restart on a non-zero exit code) the console stayed down until the next reboot, with the installer still reporting "web console set up + started". - `web setup` gates on cert.pem (written last) as well as the token, 90 s budget. - After `schtasks /run`, poll for the :47992 listener and retry before giving up; warn honestly instead of claiming a start that did not happen. - `web-run.cmd` (installed + dev) waits in-process for the token + cert (~5 min) rather than exiting 1 and hoping restart-on-failure retries. - Register the task with a logon trigger alongside boot, falling back to the boot-only XML if a Task Scheduler build rejects it. - Linux had the same defect: punktfunk-web.service's Restart=on-failure gave up permanently after systemd's default 5-starts-in-10 s limit. StartLimitIntervalSec=0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-24 23:22:09 +02:00
enricobuehler	7781d09e26	feat(linux): log if unsupported / too low gamescope version discovered	2026-07-24 20:57:44 +02:00
enricobuehlerandClaude Opus 4.8	f4fe4d0792	chore(release): bump workspace version to 0.19.2 ... An all-fixes patch on top of 0.19.1, all host-side: - KDE Plasma display takeover moved off kscreen-doctor to in-process kde_output_management_v2 (86d5d666), with the >60 Hz custom-mode install ported too (64511af4) — a KWin host whose kscreen-doctor wedges now disables its physicals and hands over the streamed output in ~2.4 ms instead of hanging ~26 s and never taking over. - The gamescope managed takeover is display-manager-flavor-aware (e35dad52) so switching a non-SDDM Linux desktop (Nobara / plasmalogin) into Game Mode no longer start-limits the display manager into a permanent black screen, and in-stream 'Switch to Desktop' is honored under it (a3e21d92). - Windows display isolation anchors the kept sources at the desktop origin (9b241d9d) so an origin-less desktop no longer fails 0x57, with restore guaranteed never to leave the desktop all-dark. - Windows pen/touch/absolute-mouse map over the streamed output's rect rather than the whole virtual desktop (087e7d04), so absolute input lands correctly when a physical monitor is kept on beside the streamed display. Nothing moved on the wire (protocol 2) or at the C ABI (13), so no embedder rebuild and 0.18/0.19 peers keep mixing freely. The Windows virtual-display driver protocol is unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> v0.19.2	2026-07-24 17:56:08 +02:00
enricobuehlerandClaude Fable 5	087e7d0405	fix(inject/windows): map absolute input over the streamed output's rect, not the whole desktop ... Pen, touch, and absolute mouse arrive normalized to the STREAMED display's frame, but pointer_windows::to_screen and sendinput's MouseMoveAbs mapped them over the whole virtual desktop — correct only when the virtual display is the sole active display (Exclusive topology). In Extend — a physical monitor kept on beside the virtual output, or an Exclusive isolate degraded to the 0x57 keep-physicals fallback — the streamed output sits at a non-zero origin, so every sample landed shifted and mis-scaled. The pen exposed it first (field report 2026-07-24): a stylus is strictly absolute, with no closed-loop correction onto the target like a cursor. New pf-inject::stream_target (Windows): the host publishes the streamed output's CCD target id at capture bring-up (one central site — capture_virtual_output covers the native and GameStream planes); mapping sites resolve its current desktop rect through pf-win-display's source_desktop_rect — the same resolver the cursor-readback poller uses, so inject and readback always agree — TTL-cached (250 ms) because a group-layout re-arrange moves a live output's origin mid-session. No target set / never resolved falls back to the whole virtual desktop (the historical mapping, still right for Exclusive topology and devtest). One change in to_screen covers pen + touch; MouseMoveAbs converts the same desktop pixel into the 0..65535 MOUSEEVENTF_VIRTUALDESK coordinate, closing the identical latent absolute-mouse bug (apollo-comparison open item #14/#30). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 17:38:36 +02:00
enricobuehlerandClaude Opus 4.8	64511af4d3	fix(kwin): install >60Hz custom modes in-process too — KWin path is now kscreen-free ... Follow-up to the previous commit: the only KWin topology op still shelling out to kscreen-doctor was the >60 Hz custom-mode INSTALL (`set_custom_refresh`). Port it to `kde_output_management_v2` so the whole KWin path is kscreen-free on modern KWin. `kwin_output_mgmt::set_custom_mode` builds a one-entry `kde_mode_list_v2` (set_resolution / set_refresh_rate / set_reduced_blanking=full / add_mode), applies it via `kde_output_configuration_v2.set_custom_modes` (since 18), waits for KWin to generate the mode (its CVT generator may align the width down — matched with the same height-exact / width-within-8 / refresh-within-1Hz gate as before), then selects it — which changes the output size and drives the sacrificial-birth stream renegotiation. `kwin::create`'s want_high branch tries this first and only resolves a kscreen id + calls `set_custom_refresh` if it returns None (pre-6.6 KWin without set_custom_modes, or the compositor not answering) — so a >60 Hz session on a box where kscreen-doctor wedges no longer eats a 5 s resolve timeout either. Bonus: `set_custom_modes` REPLACES the custom list, so reconnects are idempotent — no more one-custom-mode-per-connect growth of the user's display list. Verified: cargo test -p pf-vdisplay (73 pass), clippy -D warnings clean, fmt clean. The set_custom_modes round-trip is proven live on KWin 6.6.4: apply=applied, and a 1648x928@75 request generates 1648x928@74.901 (CVT fractional refresh, caught by the 1 Hz tolerance). The mode SELECT + full >60 Hz stream is still owed on-glass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 12:47:34 +02:00
enricobuehlerandClaude Opus 4.8	86d5d66660	fix(kwin): drive display topology over kde_output_management_v2, not kscreen-doctor ... A KDE host on Nobara stopped disabling its physical screens and creating the virtual output the moment it updated: streaming still came up, but bring-up took ~26 s and the streamed output never became the desktop (`also_disabled=[]`). Root cause is not our topology logic — it's that every `kscreen-doctor` call on the reporter's session wedges. kscreen-doctor drives libkscreen, which (per setup) waits on the kscreen KDED module over D-Bus; when that layer is stuck it blocks in its own connect and never returns, so all five topology queries hit their 5 s budget and got killed (host log). Reproduced live on a Nobara / KWin 6.6.4 box: `kscreen-doctor -j` there times out at 8 s, every time. But the compositor's OWN Wayland is fully responsive on that same session — the host just created a virtual output over it via zkde_screencast. So drive the topology (resolve our output, take primary, disable the physical/bootstrap outputs, capture their modes, re-enable on teardown, position) directly over `kde_output_management_v2` + `kde_output_device_v2` instead of shelling out. On that same Nobara box the in-process path binds management (v19) and enumerates the outputs in 2.4 ms — ~3400x faster than the 8 s hang, and immune to whatever wedges the standalone tool. - vendor kde-output-management-v2 / kde-output-device-v2 (KWin advertises mgmt v19, device v20); generate client bindings inline (the interdependent-protocol module split from the wayland-protocols crate; needs the `bitflags` dep for the device protocol's bitfield enums). - new `kwin_output_mgmt`: bounded enumerate-then-apply over one Wayland connection; every wait is time-bounded so a genuinely wedged compositor degrades to `handled = false` and the old kscreen-doctor path still runs. - `kwin::create` topology + `apply_position` prefer the in-process path (address our output by its stable device UUID, supersede-robust) with kscreen-doctor as the fallback. The 60 Hz path now makes ZERO kscreen-doctor calls; only the >60 Hz custom-mode install still shells out (its in-process port is a follow-up). Verified on Linux: cargo test -p pf-vdisplay (73 pass), clippy --all-targets -D warnings clean, fmt clean, punktfunk-host checks clean. In-process enumeration proven live against KWin 6.6.4 (the reporter's env); the disable/apply path is not yet on-glass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 12:47:33 +02:00
enricobuehlerandClaude Fable 5	a3e21d9227	feat(vdisplay/gamescope): honor in-stream 'Switch to Desktop' under the managed DM takeover ... First on-glass test of the DM-flavor takeover confirmed the black-screen fix, but exposed that the managed model could not switch back: Steam's in-stream session-select is a silent no-op while the display manager is stopped (every config-write branch in os-session-select requires the DM to be running), so the capture loss it causes just relaunched game mode. The user pass of the switch script does leave one durable trace — the ~/.config/steamos-session-select sentinel, written before any DM check. The managed launch now baselines its mtime; a capture loss with the sentinel advanced reads as the switch request and is honored by replaying the switch with the DM up: restore the display manager, run the distro's own os-session-select (its internal pkexec is authorized allow_any by the distro policy, so it works from the host's sessionless context), then stop the autologin game-mode unit so Relogin lands in the newly selected desktop. The capture-loss re-detection then follows KWin as it comes up; a 120 s post-honor grace stops the rebuild loop from racing the booting desktop back into game mode (superseded early if the box's own game-mode unit reappears — the desktop→game leg stays fast). The baseline is re-recorded on crash-restore so a pre-existing sentinel never reads as a fresh request. Every verb in the sequence was live-validated on the Nobara repro VM. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 11:49:24 +02:00
enricobuehlerandClaude Fable 5	e35dad529b	fix(vdisplay/gamescope): DM-flavor-aware session takeover — stop masking Nobara's plasmalogin to death ... Field report (Nobara 43 HTPC): switching the host to Steam Game Mode mid-stream permanently black-screened the box. Live-proven root cause on a Nobara repro VM: our takeover masks the box's gamescope-session-plus unit, plasmalogin's Relogin=true then fails its session Exec repeatedly and trips systemd's start limit within ~1 s — the display manager dies, and our restore verb (unmask + user start) cannot bring a seatless gamescope back. Only 'reset-failed + restart' of the DM recovers. The takeover is now display-manager-flavor-aware: - SDDM (Bazzite/SteamOS) keeps the proven mask+SIGKILL path unchanged. - plasmalogin/unknown DMs never mask: with privilege (root or an operator polkit rule scoped to the DM unit — documented) the host stops the DM for the stream and restores it with reset-failed + restart (PUNKTFUNK_RECOVER_SESSION_CMD as fallback), recorded in the persisted takeover state so a host crash still restores; without privilege the managed takeover degrades to ATTACH and mirrors the box's live Game Mode instead of destabilizing the seat. Both legs of the privileged cycle live-verified on the repro VM (headless managed session works with zero login sessions; render nodes are 0666). A loaded-but-inactive leftover instance never triggers the DM stop. Companion fixes from the same triage: - ensure_box_gamescope_mode gains the attach-only rebuild-probe guard both managed paths already had (stale post-capture-loss detection restarted the box's unit), and no longer re-modes a box that drives a physical display — attach mirrors on-glass; re-mode is the headless-box model. - Capture-loss rebuilds targeting gamescope get a 100 s budget: the 40 s budget expired inside the first 45 s Steam-cold-start launch attempt, a guaranteed single-shot failure. - A PUNKTFUNK_COMPOSITOR pin now WARNs once per capture loss when the live session no longer matches it (the pin disables session-following — the reporter's original stream-death trigger). - A managed session that took nothing over (client gamescope pin beside a live desktop) is stopped on disconnect instead of being orphaned forever. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 11:49:24 +02:00
enricobuehlerandClaude Fable 5	9b241d9d7b	fix(pf-win-display): anchor the kept sources at the desktop origin when isolating ... Round 3 of the field-reported exclusive-topology 0x57, with the reporter's retest logs finally separating the variable: the SAME isolate call converged rc=0 whenever a kept member already sat at (0,0), and failed 0x57 on every shape — doomed-path-carried AND keep-only escalation — whenever the doomed physical held the origin. A committable config must still contain a primary (a source pinned exactly at (0,0)); deactivating the display that held it while the kept virtual stays at its EXTEND offset supplies an origin-less desktop, which Windows rejects wholesale. Translate the kept sources rigidly so the top-left-most lands on the origin; sets already covering (0,0) are untouched so plain re-commits stay byte-identical. Also from the same logs: - restore_displays_ccd now guarantees the desk is never left all-dark: the saved snapshot can be unappliable (0x64a — it pinned a virtual target incarnation removed before teardown) or apply cleanly yet re-light nothing (snapshotted while an earlier failed teardown had the physicals off). If no external physical is active after the apply while one is connected, fall back to the database EXTEND preset. Internal panels don't count — a closed lid must not be forced back on. - the final isolate failure now names the surviving targets instead of asserting 'a non-virtual display stayed active' — the logs showed a sibling VIRTUAL display as the survivor (linger-expiry shrink), and the wording sent triage the wrong way. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 10:21:47 +02:00
enricobuehlerandClaude Opus 4.8	ebddffa4c8	chore(release): bump workspace version to 0.19.1 ... An all-fixes patch on top of 0.19.0. The headline is session teardown — the native stop flag made enforceable and bounded (ac3dc432) and GameStream ending on the control peer's ENet disconnect (41fa25c4), so a session can no longer outlive the client that started it on either plane. Also: the Windows input-desktop pair (display writes b5fa878b + pen/touch injection 24a24734 both surviving a UAC prompt), the Apple display-sleep guard (bc5f6a38), the gamescope corner-parked cursor (4b2d2d1e), the KWin custom-mode selection (3a33a694), the tvOS glob warnings (cc8cccbe), and the Linux starter/env docs revamp (66172753). Nothing moved on the wire (protocol 2) or at the C ABI (13), so no embedder rebuild and 0.18/0.19 peers keep mixing freely. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> v0.19.1	2026-07-24 02:15:40 +02:00
enricobuehlerandClaude Fable 5	cc8cccbee6	fix(core/client): drop two redundant glob imports that warned on tvOS ... `punktfunk-core` emitted `unused import: super::super::*` for client/pump/handshake.rs and client/pump/input_task.rs — but only when built for a tvOS target, where the cfg set leaves the glob contributing nothing. Nobody saw them because CI never builds tvOS: that needs BUILD_TVOS=1 and the Tier-3 build-std nightly path, and the Apple workflow only runs swift build/test (macOS). Both files also `use super::*`, i.e. the parent `pump` module, which itself globs `super::*` (`client`) unconditionally — so every name stays reachable by that path and the inner glob was pure duplication. Their sibling datagram_task.rs already imports only `use super::*`, so this also makes the module consistent. control_task.rs and data.rs keep theirs: those genuinely resolve names through it and never warned. Verified warning-free AND compiling on every slice the xcframework ships — aarch64/x86_64-apple-darwin, aarch64-apple-ios, aarch64-apple-ios-sim, aarch64-apple-tvos, aarch64-apple-tvos-sim, x86_64-apple-tvos — plus Linux with and without the `quic` feature. A full xcframework rebuild now reports 0 warnings (was 6: two per tvOS slice), and swift build, swift test (170 tests), and xcodebuild for the macOS, iOS and tvOS schemes all pass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 02:11:49 +02:00
enricobuehlerandClaude Fable 5	ac3dc4323f	fix(native/session): make the stop flag enforceable so a session can't outlive its client ... Native sessions could survive long after the client was gone, in two independent ways. HOST: `stop` was only advisory. The one thing that ends a session is the stream thread returning — every teardown (conn.close, the joins, and the RAII drops of the session permit, admission entry and stream marker) sits after that await, and nothing forced the issue. The encode loop checks `stop` between iterations, so any unbounded call INSIDE one never reaches the check, and one stuck syscall became a permanent zombie: it held its semaphore slot (four of those and the host stops accepting QUIC entirely), its admission entry (a later client gets "host busy" forever), and not even the console's Stop button could clear it — that button sets this same flag. * Bound the wait: once the session has been told to stop, the thread gets STREAM_STOP_GRACE (90 s, well past the 40 s capture-rebuild budget) to return, then teardown runs anyway. The thread is detached, not killed — Rust can't cancel a blocking thread — so it keeps its capturer/encoder until the stuck call returns, but the session's slot and admission entry come back and the host keeps serving. It logs at ERROR as the host wedge it is. * Bound the audio/input joins too — the last unbounded await in teardown. * Take the session permit AFTER the QUIC handshake instead of before `accept()`, so a host at its concurrency cap still accepts and the waiting client sees a live path instead of a silent dial timeout. * Bound the compositor helpers that caused the wedge in the first place: new pf-vdisplay `proc::{status_within, output_within}` kill a child that outlives its budget. `kscreen-doctor` is a Wayland client of the very compositor it configures, so against a wedged KWin it never returned; same for systemctl/dbus against a stuck session bus. CLIENTS: the connection was never closed, so the host was right to keep the session — it still had a live, keep-alive-answering peer. * Android: backgrounding did no teardown at all, and Android doesn't suspend the process, so the worker kept answering keep-alives until the OS reclaimed it (on a TV box, never). End the session on ON_STOP, via the existing onDispose path; a plain close, not a quit, so the host lingers the display for a fast return. * Apple: the .background arm was iOS-only AND gated on an opt-in that defaults off, so backgrounding did nothing — while the `audio` background mode kept the app (and its connection) alive indefinitely. Act unconditionally, and cover tvOS. * Core: `conn.close()` only queues the frame, and run_pump is the body of a block_on whose runtime is dropped the instant it returns, so the driver could never put it on the wire — a deliberate quit reached the host as silence (8 s idle timeout, no quit code, and the linger meant for an unwanted disconnect). Carry the endpoint out of the handshake and flush with wait_idle(), the same discipline the pairing and probe paths already use. Linux check/clippy/tests green: 262 host, 71 pf-vdisplay (incl. new bounded-process tests), 231 core. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 02:11:49 +02:00
enricobuehlerandClaude Fable 5	41fa25c440	fix(gamestream/session): end the session when the client disconnects or vanishes ... GameStream sessions outlived their client: the only complete teardowns were the explicit ones (RTSP TEARDOWN, nvhttp /cancel, mgmt DELETE /session), and the only automatic detector was a media-UDP send error — which needs an ICMP port-unreachable, so a true vanish (Wi-Fi drop, sleep, power off, crash) left video+audio encoding into the void forever, and even a plain Moonlight quit (which sends neither TEARDOWN nor /cancel) leaked the session. The stale state then cascaded: a lingering launch 503-blocked a different client under mode_conflict=reject, and streaming=true made a reconnect's PLAY take its "stream already running" branch — no new threads, old threads still aimed at the dead endpoint, the reconnect got no media. ENet already detects all of this — the control peer's reliable-ping timeout (or clean disconnect) fires Event::Disconnect within ~5-30 s — but the handler only reset input state. Wire the real teardown into it: * AppState::end_session — THE compat-plane session teardown: stops both media threads (their flags), clears launch + negotiated stream config; idempotent. /cancel and mgmt stop_session now share it. * control.rs Disconnect → end_session. Gated on the TRACKED session peer, and Connect only tracks a peer from the /launch owner's IP (the same source-IP bind the RTSP/media plane uses), so an unauthenticated LAN peer connect+disconnect can't end a live session, and a fast reconnect's stale-peer timeout can't kill its successor. * Client-unreachable UDP send errors now end the whole session via an OnSessionLost callback (built at PLAY) instead of stopping only the plane that noticed — audio no longer keeps streaming after video detects the dead client, and vice versa. Linux check/clippy/tests green (53 gamestream tests incl. the new end_session regression test). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 02:10:23 +02:00
enricobuehlerandClaude Opus 4.8	3a33a69401	fix(kwin): select the custom mode KWin actually built, not the one we asked for ... A KDE host streaming to a phone-shaped client fell back to 60 Hz even though the 120 Hz mode was sitting right there in KDE's display list, one manual click away. KWin generates every custom mode's timing with libxcvt, whose first step is `hdisplay_rnd = hdisplay - (hdisplay % 8)`. A 2868x1320@120 request (iPhone 16 Pro Max) therefore becomes 2864x1320@119.92 — 4 px narrower, fractional refresh. We then asked kscreen-doctor for `mode.2868x1320@120`; its `findMode` matches a mode's id or its own `WxH@qRound(Hz)` name, so that string matched nothing, the select silently no-op'd, the output stayed on its sacrificial birth mode, and `size_applied` came back false → "KWin rejected the custom mode" → 60 Hz. Widths like 1920/2560/3840 are all multiples of 8, which is why only clients with phone-shaped panels ever hit this. Resolve the mode out of the output's OWN list instead and address it by kscreen mode id: exact height, width at most one cell narrower than asked, refresh within 1 Hz (which excludes the native 60 Hz entry). `set_custom_refresh` now returns the whole achieved mode, and `create` reports that as the output's `preferred_mode` — so the capturer's renegotiation gate waits for the size KWin will actually deliver and the encoder opens against it, rather than starving on the requested one. Also skip `addCustomMode` when a usable mode is already installed: kscreen-doctor APPENDS to the list and KWin persists it per output name, so the old code grew the user's display list by one entry per connect. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 00:55:36 +02:00
enricobuehlerandClaude Opus 4.8	24a24734eb	fix(inject/windows): follow the input desktop for pen + touch injection ... Same field report as the display-write fix, other half of the symptom: with a UAC consent prompt up — one the user could SEE in the stream, because capture already renders the secure desktop (326d6e17) — pen and touch did nothing, while mouse and keyboard kept working. The split was exactly which paths knew the input desktop can move. sendinput.rs reattaches, so mouse/keyboard reached the prompt. pointer_windows.rs had no desktop handling at all, so every InjectSyntheticPointerInput came back ERROR_ACCESS_DENIED: 22:20:31 virtual pen created (PT_PEN) 22:20:31 pen inject failed error=Zugriff verweigert (0x80070005) 22:20:42 touch inject failed error=Zugriff verweigert (0x80070005) contacts=1 Measured on glass before fixing, to find out what it actually takes: device on Default, thread on Default -> 0x80070005 (the field failure) device on Default, thread on INPUT -> OK device on INPUT, thread on INPUT -> OK The middle row is load-bearing: the synthetic pointer device is NOT desktop-affine, so rebinding the thread suffices and the device is never destroyed and recreated across a desktop switch — which would have dropped in-flight contacts and the pen's in-range state mid-stroke. Injection now retries once bound to the input desktop. The binding is scoped, not persistent like sendinput's: inject_pen/inject_touch_frame run on TWO threads (the caller's apply_batch and the refresh threads), and the batch caller is a shared task thread that must not be left parked on a Winlogon desktop that disappears when the prompt is dismissed. The first-failure WARN now carries the rejected sample (flags, pen flags/mask, pressure, rotation, tilt, position). A 0x80070057 INVALID_PARAMETER was seen once BEFORE any prompt existed and is still unexplained; the ranges all look sound on inspection (coordinates clamped to the virtual screen, roll/azimuth u16 so the modulo cannot go negative, tilt bounded 0..=90), so catching the actual offending sample is the way to find it. Verified on glass: with a consent prompt up, pen and touch now reach it — zero inject failures where every prior session failed immediately. A UAC prompt can now be dismissed from an iPad with the Pencil. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 00:36:51 +02:00
enricobuehlerandClaude Opus 4.8	b5fa878bc6	fix(pf-win-display): follow the input desktop so a UAC prompt can't refuse display writes ... Field-reported 2026-07-23: a consent prompt left up on an unattended host made the box unreachable. Every connect black-screened and failed after ~60 s, and the host had to be reached over SSH to clear the prompt. Windows refuses ChangeDisplaySettingsEx/SetDisplayConfig issued from a thread that is not on the desktop currently receiving input. While UAC (or the lock / logon screen) is up that desktop is Winlogon, and the host — which the service launches explicitly onto WinSta0\Default — got DISP_CHANGE_FAILED / ERROR_ACCESS_DENIED for every write. A session starting in that window could never set its virtual display's mode, so the capturer sized its ring to a stale mode, every composed frame was dropped for a size mismatch, and bring-up burned 8 retries before giving up. Measured on glass (RTX box, SYSTEM host in console session 2, real consent prompt up, virtual display active): INPUT desktop = Winlogon UNBOUND CDS_TEST -> -1 (DISP_CHANGE_FAILED) UNBOUND SDC_VALIDATE -> 0x5 (ERROR_ACCESS_DENIED) BOUND CDS_TEST -> 0 (DISP_CHANGE_SUCCESSFUL) BOUND SDC_VALIDATE -> 0x0 (ERROR_SUCCESS) New input_desktop.rs mirrors pf-inject's sendinput.rs retry model: issue the write, and only when it fails the way a wrong-desktop write fails, rebind this thread to the current input desktop and retry once. A working write is never touched, so the normal path is unchanged. The retry predicate stays narrow (ERROR_ACCESS_DENIED only) so the unrelated 0x57 exclusive-mode topology bug is not re-issued and mis-attributed. Unlike sendinput's dedicated injector thread, the binding here is SCOPED — a shared display-write thread left on a Winlogon desktop that is later destroyed would fail every subsequent write, which is the wedge this removes. Applied to all eight SetDisplayConfig sites and both ChangeDisplaySettingsExW calls in set_active_mode. The isolate site now decides its supplied config once, outside the write, so a retry re-issues the identical config rather than logging its escalation twice. A save is logged, because a silent one is indistinguishable in a field log from a write that never needed saving — which made the first on-glass verification of this change inconclusive. Both ACCESS_DENIED diagnostics now ask which cause applies instead of naming only the disconnected-RDP one: that phrasing sent this investigation chasing a phantom RDP session on a host that was already service-launched in the console session, while a consent prompt was the actual cause. Verified on glass: connect with a consent prompt up now reaches first frame in 3.0 s (was a black screen then "Connection failed" after ~60 s), with six "retried bound to it and it applied desktop=Winlogon" lines and rc=0x0 throughout. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 00:36:51 +02:00
enricobuehler	4b2d2d1e14	fix(gamescope/cursor): follow gamescope's own cursor verdict — the corner-parked pointer ... gamescope hides its pointer by WARPING the X pointer to the root's bottom-right corner pixel; it does not swap in a transparent X cursor, so XFixesGetCursorImage keeps handing back the last opaque arrow. The XFixes source picked its display by "whichever pointer moved", and a parked pointer never moves again — so it froze on the parked Xwayland and composited that arrow at (w-1, h-1): a sliver of cursor welded to the corner of the stream for the rest of the session while the real pointer went undrawn. Reported on-glass in every game (a game grabs the pointer, so the hide is permanent): "part of cursor shows up on bottom right ... isn't where it really is". Follow GAMESCOPE_CURSOR_VISIBLE_FEEDBACK instead — gamescope publishes it on every nested Xwayland root: 1 on the server whose pointer it is drawing, 0 on the others and 0 on all of them once the pointer is hidden. It answers both questions correctly for a STATIC pointer, which motion cannot: which Xwayland owns it, and whether to draw it at all. Read at connect, re-read on its root PropertyNotify (event drain now discriminates CursorNotify vs PropertyNotify) with a 250 ms resync as the self-heal. A pointer gamescope draws nowhere is published visible:false, not dropped — the encode loop overwrites the frame's overlay from this slot and strips invisible ones, so a None would leave the last visible overlay standing on repeat frames. Honouring the atom also gives the stream gamescope's own idle auto-hide, which this source never had. The pointer-motion heuristic stays as the fallback for a gamescope that publishes no verdict (logged at session start via cursor_feedback=false), so nothing regresses to a cursorless stream. Measured on a live 1920x1080 Steam Gaming Mode session (RTX 5070 Ti, gamescope c31743d+, --xwayland-count 2 --hide-cursor-delay 3000): idle 3 s => pointer (1919,1079) + feedback 0; real evdev motion => pointer live + feedback 1. End-to-end against that session the source now publishes visible=false while parked and tracks the live pointer within one 250 ms sample of motion. cargo clippy -p pf-capture --lib -D warnings and the 5 new pick_active tests are green at cargo 1.96.1 (CI parity); cargo fmt --all --check clean.	2026-07-24 00:31:55 +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	6617275387	docs(env): stop teaching the compositor pin + uid-1000 anchors in starters ... Field triage (Nobara, Discord): the kde.md starter host.env told desktop users to set PUNKTFUNK_COMPOSITOR=kwin, which PINS the backend — detect() short-circuits and the capture-loss rebuild never re-detects — so a mid-stream switch to Game Mode killed the stream instead of following it. A follow-up hardcoded XDG_RUNTIME_DIR=/run/user/1000 anchor broke PipeWire for any non-1000 uid (pw audio connect: Creation failed). Revamp across every starter/example/reference: - Desktop starters (kde/gnome/hyprland/sway) shrink to PUNKTFUNK_VIDEO_SOURCE=virtual + an explicit warning that pinning disables session-following; forcing a backend is CI/appliance-only. - host.env.example: rewritten around auto-detection; anchors demoted to a commented ssh/cron-only block with the uid trap spelled out; the gamescope ATTACH/MANAGED knobs documented (previously missing); case-sensitivity called out. - packaging/bazzite/host.env + README: drop the uid-1000 anchors (a systemctl --user service inherits/derives them); README's stale PUNKTFUNK_COMPOSITOR=gamescope-era template synced to the real one. - packaging/kde/host.env: loud APPLIANCE-ONLY header (it pins on purpose). - configuration.md: session-anchors section inverted to "leave unset", compositor row states the pin consequence, case-sensitivity note. - troubleshooting.md: new "session fails right after editing host.env" section (case, wrong-uid anchors, stale pin, restart-to-apply). - gamescope.md/bazzite.md: attach/managed descriptions match current behavior (managed is the infra-detected default; attach re-modes a box-owned session to the client's resolution). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 22:42:59 +02:00
enricobuehlerandClaude Opus 4.8	bda015b101	docs(release): rewrite v0.19.0 notes for end users + set end-user notes voice ... Release notes were written for the people who build Punktfunk, not the people who use it — dense with protocol/ABI/type names that confused even technical readers. Rewrite v0.19.0 in a benefit-first, plain-language voice (New/Improved/Fixed) with all internal terms removed from the body and every protocol/ABI/embedder detail moved to a single bottom "Under the hood" section. docs/releases/README.md now codifies this voice as the format spec for all future notes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 20:15:08 +02:00
enricobuehlerandClaude Opus 4.8	ec219763a6	fix(ci/release): make _release_notes_path POSIX-sh safe (deb/decky attach runs under dash) ... The v0.19.0 deb + decky release-attach steps source gitea-release.sh under `sh` (dash) and died with "Bad substitution" at _release_notes_path's `${BASH_SOURCE[0]:-$0}` — a bash array subscript dash rejects. So those legs never attached their assets to the release (the bash legs — apple, android, rpm — were fine, which is why the body still seeded and the DMG/.ipa attached). CI always sources this from the repo root, so resolve the notes as docs/releases/<tag>.md relative to CWD and drop $BASH_SOURCE entirely. Verified under dash. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> v0.19.0	2026-07-23 19:03:01 +02:00
enricobuehlerandClaude Opus 4.8	0dce1cd116	chore(release): bump workspace version to 0.19.0 ... Headline: the whole pen/tablet input stack (P0–P5) — a pressure-sensitive stylus plane across core wire, Linux, GameStream/Moonlight, Windows, iPad Pencil and Android. Plus touch-injection fixes, cursor-DPI scaling, three Windows-host display/cursor fixes, a gamepad same-PID conflict fix, and the Android mouse/keyboard (TV) regressions. Release notes authored in-repo at docs/releases/v0.19.0.md (first release on the new flow; CI seeds the release body from it). cargo update --workspace syncs the lock (versions only). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 18:26:49 +02:00
enricobuehlerandClaude Opus 4.8	c3c0115a82	fix(core/abi): bump ABI_VERSION to 13 for punktfunk_connection_send_pen ... The pen P0 work added a new embeddable C entry point (punktfunk_connection_send_pen) but left ABI_VERSION at 12 — the value 0.18.0 shipped. Per the project's convention (0.18.0 bumped to 12 for the additive cursor channel), additive C-surface growth bumps the ABI so embedders can gate on the new symbol. Regenerated include/punktfunk_core.h via cbindgen (cargo build -p punktfunk-core); WIRE_VERSION is unchanged (pen is capability-gated on HOST_CAP_PEN). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 18:23:38 +02:00
enricobuehlerandClaude Opus 4.8	00c8c12a0f	feat(ci/apple): export the iOS .ipa to the release + run artifacts ... The iOS leg archives with development signing and re-signs for App Store distribution at export time, but the existing export uses destination=upload (straight to TestFlight) and leaves no .ipa on disk. Add an export step that re-exports the SAME archive with destination=export to produce an App Store distribution-signed .ipa, then: * attach it as the `punktfunk-ios-ipa` run artifact on every build (upload-artifact@v3, since Gitea's backend rejects @v4), and * attach it to the unified Gitea release on vX.Y.Z tags (alongside the DMG), via the shared ensure_release/upsert_asset helpers. Same gate as the archive; warn+skip (never fails the best-effort iOS leg) if the archive is absent. Note: an App Store-signed .ipa installs only via TestFlight/App Store, not by direct sideload — it is a release/archival artifact. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 18:18:45 +02:00
enricobuehlerandClaude Fable 5	988b5742ec	fix(gamestream): tolerate NaN pressureOrDistance — VoidLink's finger touches were dropped whole ... The hex dumps from the on-glass session show textbook SS_TOUCH packets with pressureOrDistance = 0x7fc00000 (NaN): VoidLink encodes 'unknown finger pressure' as NaN (iPad fingers have no force sensor), and the anti-forgery finiteness gate rejected the entire packet — silently disabling the touch plane while pen (real Pencil force, always finite) worked. Coordinates keep the strict gate (they feed injector scaling); pressureOrDistance now sanitizes non-finite to 0.0, the spec's own 'unknown', which the pen path already maps to full-scale ink on contact. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 17:48:17 +02:00
enricobuehlerandClaude Fable 5	f938174d86	debug(gamestream): hex-dump the first few undecodable pointer packets ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 17:48:17 +02:00
enricobuehlerandClaude Fable 5	40611cd54d	debug(gamestream): surface the pointer plane's silent failure modes ... An on-glass 'touch does nothing' currently leaves NO trace: log the first SS_TOUCH per session at info (proves the client sends + we decode), and warn when a packet carrying a pointer magic fails the body parse (layout mismatch) instead of vanishing into the unknown-magic drop. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 17:48:17 +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	51792536d1	fix(pf-win-display): escalate CCD isolate to a keep-only supplied config on 0x57 ... Field bug (Steam Deck client, exclusive topology): every isolate retry failed SetDisplayConfig 0x57 with the physical panel left lit, while iPhone sessions worked — their virtual monitor's connected-set already had a sole-display topology persisted, so Windows deactivated the physical on hotplug and the isolate was a no-op re-commit (deactivated 0). The Deck's monitor identity had no such entry, forcing the live-deactivate path: supplying the doomed path (inactive, modes unpinned) plus its orphaned mode entries is rejected 0x57 by some driver/OS validation combos, so the retry loop could never converge — the prior mode-index unpin (5e088af7) was necessary but not sufficient on this box. Attempt 1 keeps the shipped shape; once a survivor is seen, later attempts supply ONLY the keep paths with the mode table rebuilt to just their referenced entries (indexes remapped, clone-shared entries deduped). The same host applies exactly this keep-only shape rc=0 whenever the DB has pre-isolated the virtual display, so the escalated shape is field-validated on the failing machine. The final attempt also drops SDC_FORCE_MODE_ENUMERATION — a real path removal drives COMMIT_MODES on its own. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 16:50:44 +02:00
enricobuehlerandClaude Fable 5	bf2c4456bb	fix(inject/windows): compact wire touch ids into slots — Moonlight native touch injected nothing ... On-glass report (iPad Moonlight vs the Windows host): pen inked, native touch did nothing. Cause: POINTER_INFO.pointerId was the client's raw wire id — Moonlight sends arbitrary large pointerIds, and synthetic-pointer injection rejects them (Apollo compacts ids into dense slots for exactly this reason); the failure was logged at trace, i.e. invisibly. Wire ids now map to the lowest free slot for the contact's lifetime, and the FIRST injection failure of a device logs at WARN (pen too) so an inert input plane is never silent again. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 16:48:57 +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	15d09a8c10	feat(ci/release): author release notes in-repo + announce stable releases to Discord ... Release notes now live in the repo at docs/releases/vX.Y.Z.md, authored during the version bump (before the tag). ensure_release (gitea-release.sh + .ps1 twin) seeds the Gitea release body from that file in the create POST, so the release is born WITH its notes instead of being created empty and PATCHed afterward. canary/rc have no file -> empty body, unchanged. New manual `announce` workflow (workflow_dispatch, tag input) re-syncs the notes file over the live release and posts a violet embed (title, notes lead-in, release-page link) to the Discord #releases channel via the DISCORD_RELEASE_WEBHOOK secret. Stable-only: a -rc tag is refused unless allow_prerelease=true. Pressing "go" is the quality gate, so a half-built or failed release is never announced. docs/releases/README.md documents the ritual; TEMPLATE.md is the skeleton. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 16:43:18 +02:00
enricobuehlerandClaude Opus 4.8	6cbc3eec8b	fix(sdl/cursor): scale the forwarded pointer to the video fit ... Parity with the Apple client (35c2c145): the SDL/Linux presenter built the host-forwarded cursor as an OS cursor at its native bitmap size, so the on-screen pointer tracked the HOST's display scaling — a 4K/high-DPI virtual display forwards a 96 px bitmap that then rendered huge on the client. SDL cursors are fixed-size from their surface (no draw-time scaling), so cache the shapes RAW and resample each by the live video-fit factor (min(window_px / mode) — the same aspect-fit `finger_to_content` uses) at install time, rebuilding when the serial OR the fit changes (a resize). The resample area-averages on premultiplied alpha so a transparent pixel's colour can't bleed into the fringe. The pointer now stays sized to the streamed desktop at any host scaling. Not yet eyeballed on a Deck/Linux box — SDL's HiDPI cursor sizing is version-dependent; validate on glass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 16:28:34 +02:00
enricobuehlerandClaude Fable 5	45c9799aa6	feat(inject/windows): pen P3 — PT_PEN + PT_TOUCH synthetic pointer injection ... The Windows leg of design/pen-tablet-input.md §6, following Apollo's recipe: a per-session PT_PEN device (pressure rescaled 0..1024, polar tilt→tiltX/Y, barrel roll on rotation — Windows Ink renders Pencil Pro roll natively, barrel button, eraser via INVERTED/ERASER flags, hover) with a 40ms refresh thread against the ~100ms synthetic-pointer staleness auto-lift, plus a PT_TOUCH device closing the historical SendInput wire-touch no-op (full active-contact frames, per-id DOWN/UP edges, self-healing lost-DOWN synthesis). pen_supported now probes PT_PEN creation on Windows (1809+), which lights up HOST_CAP_PEN and the GameStream featureFlags there — Moonlight iPad + Pencil can ink on a Windows host. Frame grouping mirrors the Linux uinput backend. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 16:18:31 +02:00
enricobuehlerandClaude Fable 5	b192825869	feat(gamestream): pen P2 — SS_PEN/SS_TOUCH ingest, featureFlags advertised on capable hosts ... The Moonlight leg of design/pen-tablet-input.md §4: DESCRIBE now advertises SS_FF_PEN_TOUCH_EVENTS wherever pen injection exists (Linux+uinput, same gate as HOST_CAP_PEN — elsewhere the flag stays 0 and Moonlight keeps client-side mouse emulation exactly as today). SS_PEN packets merge over last-known state into state-full PenSamples (BUTTON_ONLY per spec carries no position; unknown contact pressure 0.0 inks at full scale; UP keeps proximity only for clients that demonstrated hover) and drive the same PenTracker→VirtualPen chain as the native plane — Moonlight iOS + Apple Pencil now exercises the full injection path end to end. SS_TOUCH forwards as wire touch on a synthetic 65535² surface with CANCEL_ALL replayed per tracked contact. No stroke timeout on this plane: ENet is ordered/reliable and Moonlight doesn't heartbeat a stationary pen. Packet layouts pinned against moonlight-common-c Input.h/Limelight.h upstream. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 16:18:31 +02:00
enricobuehlerandClaude Fable 5	aca5aa9993	feat(host+inject): pen P1 — per-session uinput virtual tablet, HOST_CAP_PEN live ... The Linux injection leg of design/pen-tablet-input.md: 0xCC/0x05 pen batches now route through the per-session PenTracker into a lazily-created 'Punktfunk Pen' uinput tablet (BTN_TOOL_PEN/RUBBER, pressure, tilt-from-polar, ABS_Z barrel roll, hover distance, INPUT_PROP_DIRECT) — compositors pick it up via libinput and hand apps zwp_tablet_v2 with full fidelity. The host now advertises HOST_CAP_PEN when /dev/uinput is accessible (PUNKTFUNK_PEN=0 kill-switch); transitions group into SYN frames so proximity-enter carries its position. Stroke failsafe: clients heartbeat ≤100ms while in range (documented wire contract — capture APIs are silent for a stationary pen); 200ms of silence force-releases. 'punktfunk-host pen-test' draws a pressure-ramped sine stroke through the real tracker→uinput chain, no client needed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 16:18:31 +02:00
enricobuehlerandClaude Fable 5	248e1cbf08	fix(pf-vdisplay/driver): report cursor_excluded adapter-wide — the declare's exclusion is not per-target ... Field report (iPad via GameStream, 2026-07-23): cursor missing from the stream. The session's fresh target 257 reported cursor_excluded=false (DECLARED_TARGETS is keyed per target and only 259 had declared), so the host skipped forced-composite — but DWM's pointer exclusion after an IddCx hardware-cursor declare reaches EVERY later monitor of the adapter, not just the declaring target (proven on-glass: declare on 259 under WUDFHost 2192, then 257's frames streamed pointer-free with CURSOR_SHOWING set and SM_MOUSEPRESENT true). GameStream/Moonlight clients cannot draw a forwarded cursor, so those sessions were silently cursor-less. ADD replies now report any-declare-this-WUDFHost-life (the state's real scope — it dies with the adapter reset, same as before); per-target ids stay only as the dbglog audit trail. Channel-less sessions on a declared adapter then hit the existing forced-composite gate (GDI poller + blend) and carry the pointer in-video. Host code unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 15:58:54 +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 Fable 5	326d6e17c8	fix(windows/capture): stand the IddCx hardware cursor down while the secure desktop is up ... 0.18.0 regression: UAC consent and Winlogon (lock/logon) stopped appearing in streams. The cursor channel's IddCx hardware-cursor declare — re-issued by the driver on every swap-chain assign — keeps the path out of the OS's software-cursor mode, which is the only mode the secure desktop renders through; DWM then never presents UAC/Winlogon into our swap-chain and the stream repeats the last normal-desktop frame for the whole interaction. The GDI cursor poller now classifies the input desktop on its reattach cadence (UOI_NAME != Default = secure, 250 ms cadence instead of 2 s), and the capturer edge-triggers the existing-but-unused proto-v6 IOCTL_SET_CURSOR_FORWARD flip: OFF at secure entry (the driver stops its per-assign re-declare; the host facade forces the same-mode re-commit that actualises the software-cursor default, under the vdisplay manager lock via the new force_recommit()), back ON at dismissal for channel sessions. Channel-session open resets the driver's persisted desired state to ON so a session that died mid-secure-desktop can't leave the next one adopting UNdeclared (the §8.6 cross-session composite trap); orderly teardown does the same. The flip closure is built for every Windows session — a channel-less session can reuse a driver monitor whose earlier-session cursor worker still re-declares, and NOT_FOUND from never-declared targets is ignored. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 14:13:15 +02:00
enricobuehlerandClaude Opus 4.8	588a7077e8	fix(host/gamepad): only degrade a virtual Steam pad on a same-PID conflict ... The Steam-conflict gate matched any physical Valve `28DE` HID device, so a Steam Machine with a physical Steam Controller 2 (`28DE:1302`) plugged in degraded a client's requested virtual Steam Deck (`28DE:1205`) to a DualSense — the reporter's controller passthrough came up as the wrong pad. Steam Input drives *distinct* Steam controllers side by side; only two *identical* `28DE` devices confuse it (the Deck-as-host case: built-in `28DE:1205` + a second virtual Deck, observed live on Bazzite). Narrow the gate to key on the exact VID+PID instead of the `28DE` vendor alone: - `steam_backend_product()` maps each virtual Steam backend to the PID it enumerates as (Deck 1205, classic SC 1102, SC2 1302, SC2 Puck 1304). - `physical_steam_controller_present()` -> `physical_steam_product_present(pid)` matches `:28DE:{PID}`, keeping the FVPF-serial / `vhci_hcd` / `/virtual/` exclusions so our own virtual pads never count. - `degrade_steam_on_conflict` degrades only on a same-PID duplicate and logs the conflicting identity. `PUNKTFUNK_STEAM_FORCE=1` override unchanged. A physical SC2 no longer blocks a virtual Deck (and vice versa); a genuine same-identity duplicate (physical Deck + virtual Deck, or physical SC2 + SC2 passthrough) still degrades. Adds a unit test for the PID mapping. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 14:11:44 +02:00
enricobuehlerandClaude Fable 5	4714235fe6	feat(core): stylus wire P0 — state-full RICH_PEN batches, PenTracker, HOST_CAP_PEN ... The pen plane from design/pen-tablet-input.md, protocol side only (the P1 uinput tablet injector will consume it): 0xCC kind 0x05 carries batches of state-full PenSamples (pressure, polar tilt + azimuth, barrel roll, hover distance, eraser tool, barrel buttons); PenTracker diffs samples into injector transitions so a lost datagram self-heals; HOST_CAP_PEN (0x10) gates sending and stays unadvertised until a real backend exists. C ABI: PunktfunkPenSample + punktfunk_connection_send_pen, documented in docs/embedding-the-c-abi.md §8. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 12:58:31 +02:00
enricobuehlerandClaude Opus 4.8	1a6deeb781	feat(host/library): scan the user's non-Steam shortcuts into the game library ... Steam's "Add a Non-Steam Game to My Library" entries carry no `appmanifest`, so `scan_manifests` can't see them and they never appear in the streamed library. Read each Steam account's binary `userdata/<id>/config/shortcuts.vdf` directly (a binary KeyValues parse) to surface the user's own custom entries, plus their grid artwork from `userdata/<id>/config/grid`. Best-effort: an unreadable or absent shortcuts.vdf contributes nothing, and hidden shortcuts / duplicate appids are dropped. Verified: clippy -D warnings + compile green on Linux. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> v0.18.0	2026-07-23 00:45:25 +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 Fable 5	d83eeedde4	ci(flatpak): drop the use-vc TCP-DNS hack — the runner-side cache made it the failure ... Every flatpak Tooling failure on 2026-07-22 (4 runs, incl. two AFTER the runner fleet got its local dnsmasq cache) died in flatpak remote-add with an instant 'Could not resolve hostname' ×10 while dnf in the SAME container resolved fine. The one thing only this leg does is force glibc onto TCP DNS (use-vc) — a 2026-07-11 mitigation for the embedded resolver dropping UDP under fleet load. With job containers now resolving against the on-box dnsmasq cache (daemon.json dns → docker0), UDP is reliable again and the TCP path through the same chain is the flaky one under concurrency. Remove the hack; keep the nss-resolve drop and retry.sh as the backstop. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 00:27:52 +02:00
enricobuehlerandClaude Fable 5	786f6ad28f	fix(pf-driver-proto): catch the layout tests up with the cursor-channel proto bump ... The cursor-channel sweep grew AddReply by the cursor_excluded u32 tail (24 bytes, legacy prefix 20) and bumped PROTOCOL_VERSION to 6, but left two lib tests behind: the AddReply byte-layout roundtrip still built the legacy initializer (a compile error that turned the rust CI leg red on main), and the version-coherence assertion still pinned v5 (hidden behind that compile error). Cover the new tail bytes + the legacy-size constant, and widen the compat-window note to v4–v6 (floor stays 3). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 00:22:34 +02:00