2902 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehler	1fc184516a	feat(apple): the browse route is real — a Shortcut or a widget jumps straight into a host's library ... The reserved punktfunk://browse/<host-ref> route now routes on Apple: it drives the same libraryTarget every internal surface writes, so the link lands in whichever presentation the current mode owns — the gamepad console's in-place library screen, the touch cover, the macOS sheet, or tvOS's cover. Connect's posture minus the connect: a pin conflict refuses, a live session is never preempted, an unsaved host gets a notice (the library rides the paired mTLS identity, so there is nothing to browse before the host is saved). browse ignores launch=/profile= — nothing streams until a title is picked, and that connect resolves its own profile. On top of the route, the two new front doors: - OpenLibraryIntent ("Open Game Library") beside Connect/Wake/End in Shortcuts/Siri/Spotlight, host-parameterized like the others and round-tripping through the URL — one router, no second path. - A configurable library widget (kind "PunktfunkLibrary", AppIntentConfiguration over HostEntity — the configuration the HostEntity doc comment anticipated): pick a host, tap into its library. Unconfigured it follows the most recent host; a configured host that was removed shows the empty state rather than silently following a different host. Same .never timeline + HostStore push as the hosts widget, now reloading both kinds. DeepLink.browse(host:) is the one emitter both doors share, covered by a round-trip test beside connect's; the parse side was already in the grammar and the vector file. Docs updated (clients, game-library, profiles-and-links).	2026-08-10 14:11:01 +02:00
enricobuehler	35b5ee6a36	Merge pull request 'punktfunk-encode-worker: GPU priority via a capability-carrying worker, with WP3 on-glass complete' (#153) from worktree-worktree-encode-worker into main ... Reviewed-on: #153	2026-08-10 10:45:23 +00:00
enricobuehler	548eb4fa14	Merge pull request 'gamescope aborted on every connect — a PipeWire use-after-free wearing an "unreachable" assert' (#152) from worktree-gamescope-pipewire-buffer-abort into main ... Reviewed-on: #152	2026-08-10 10:45:05 +00:00
enricobuehler	84faeb1bf1	docs(pf-encode): Linux Main10 is live — the 'inert until Phase 5.1' comment outlived the code ... The bit_depth field said '8 on Linux until Phase 5.1 lands a P010 capture path'. The code outran it: the gamescope HDR capture patches offer 10-bit BT.2020/PQ, nvenc_fmt maps X2Rgb10/X2Bgr10 to ARGB10/ABGR10, and is_ten_bit_input flips bit_depth and hdr from the negotiated input. Verified on home-nobara-1: 'resolved session plan ... bit_depth: 10, hdr: true' on the direct backend. A 10-bit frame deliberately takes neither the NV12 nor the YUV444 convert (both compute CSCs write 8-bit planes) and rides packed RGB to the encoder, which does its own BT.2020 CSC — pf-capture/src/linux/pipewire.rs owns that gate. So Main10 needed no P010 path to arrive, and P010 is now a perf follow-up (skip NVENC's internal CSC, as NV12 does for SDR), not the thing that makes 10-bit work.	2026-08-10 12:39:46 +02:00
enricobuehler	ad63994cb9	fix(pf-encode): the 10-bit probe was the last ffmpeg NVENC open on a direct-SDK host ... `can_encode_10bit`'s Linux NVIDIA arm answered "can this GPU encode 10-bit?" by opening an ffmpeg `hevc_nvenc` encoder. On a host that then streams over the direct SDK, that is the LOG-3 field bug: one ffmpeg NVENC open in a direct-SDK process wedges every later open process-wide with `NV_ENC_ERR_INVALID_VERSION` until the host restarts. `can_encode_444` was moved off the ffmpeg probe for exactly this reason on 2026-07-27. The 10-bit one was deliberately left behind, on the reading that "Linux HDR genuinely rides the libav P010 path". `open_video` contradicts that: if cuda && nvenc_direct_enabled() { // no 10-bit exclusion … NvencCudaEncoder::open(…, bit_depth, …) A CUDA capture goes to the direct backend at whatever depth was resolved, and `is_ten_bit_input` already accepts the packed 10-bit RGB (`X2Bgr10`) that a gamescope HDR capture negotiates. So on a default NVIDIA host the probe was loading ffmpeg's NVENC client for a session that never uses it. Observed on home-nobara-1 2026-08-10, gamescope + RTX 5070 Ti, client HDR on: resolved session plan … bit_depth: 10, hdr: true pipewire format negotiated … xBGR_210LE mapped=Some(X2Bgr10) modifier=0 hdr=true encoder submit failed — encoder rebuilt in place … NV_ENC_ERR_INVALID_VERSION encoder did not recover after repeated in-place rebuilds — ending the video session and with `PUNKTFUNK_NVENC_DIRECT=0` (nothing mixes, libav serves everything) the same HDR session streams clean: 0 errors, bit_depth=10, hdr: true. The 10-bit cap now rides `nvenc_cuda::probe_support()`'s existing throwaway session — the same place the 4:4:4 cap already rides, queried per listed GUID with `NV_ENC_CAPS_SUPPORT_10BIT_ENCODE`, which is what the Windows NVENC arm has always done (`enc/windows/nvenc.rs`). Unanswered fails CLOSED: an 8-bit session beats a wedged one. A host that will really serve over libav (`PUNKTFUNK_NVENC_DIRECT=0`, or a build without `--features nvenc`) keeps the ffmpeg probe, where it validates the actual path and ffmpeg's client is loaded anyway. ⚠ NOT YET VALIDATED ON GLASS. Gates are green — clippy `-D warnings` with `--features nvenc,vulkan-encode,pyrowave` on linux/amd64, 67 pf-encode tests, fmt — but the end-to-end HDR run is still owed. This branch is 42 commits behind main and its build cannot complete a punktfunk/1 handshake on home-nobara-1 at all (it stalls between "audio channels resolved" and "encode bit depth" and times out at 10 s, on EVERY attempt). That stall is NOT this change: a control build with only the routing reverted stalls identically, and the released 0.27.0 RPM on the same box handshakes fine and reaches `bit_depth=10`. Rebase onto main before re-testing.	2026-08-10 12:30:24 +02:00
enricobuehler	a23c028492	fix(host): the console reported the resolution the client asked for, not the one it got ... `/api/v1/local/summary` (and the console card behind it) read the live-stats mode slot, which bring-up seeded from the NEGOTIATED mode: let live_mode = Arc::new(AtomicU64::new(pack_mode( mode.width, mode.height, interval_hz(interval)))); The refresh was already corrected there — the comment says so, because KWin caps a virtual output's rate — but the SIZE was still the request. Only a mid-stream resize ever fixed it: the rebuild path below publishes `delivered_mode(frame..)`, and bring-up never did. Attach is what makes this matter rather than being pedantry. On a box with a physical display the gamescope backend logs gamescope: box drives a physical display — attaching at its own mode (no re-mode) client_w=5120 client_h=1440 and streams the panel's size. Measured on home-nobara-1 with a 1080p HDMI panel attached: the capture negotiated 1920x1080 and NVENC opened 1920x1080@240, while the summary reported 5120x1440 — the console confidently naming a resolution nobody was watching, which is exactly the shape of the stale attach-path report noted on .41 in July ("reusing w=5120 h=1440" while the session was really 1080p). Seeding the slot from `delivered_mode(frame.width, frame.height, interval)` uses the same helper the rebuild path already trusts, and changes only the two fields that were wrong — its refresh term IS `interval_hz(interval)`, so that half is bit-for-bit what it was. This publishes the STATS slot only. It deliberately does not send the client a corrective `Reconfigured`: that remains owed exactly where it already was, under `adopted_at_bringup`, because an ordinary connect's mode came from the Welcome rather than from an accept the client has already acted on. Verified on home-nobara-1, attach session against a 1080p panel: summary session: {"width":1920,"height":1080,"fps":240} actually captured: pipewire format negotiated width=1920 height=1080 Before the change the same session reported 5120x1440.	2026-08-10 07:55:18 +02:00
enricobuehler	5b3ea6e8db	fix(pf-encode): one NVENC open failure could kill every session on the box ... `punktfunk-host` died twice on home-nobara-1 with the same stack: __strlen_evex <- av_vbprintf <- format_line <- av_log_default_callback <- ff_cuda_check <- ff_nvenc_encode_init <- avcodec_open2 <- NvencEncoder::open <- NvencEncoder::reset <- virtual_stream once as an outright SIGSEGV mid-session, and once as a thread wedged in that stack so the service never answered SIGTERM and systemd escalated to SIGABRT ("State 'stop-sigterm' timed out. Aborting."). Both times a client's session was rebuilding its encoder. The blast radius is the whole host process — every other client's session goes with it. The fault is in libav, not here. `ff_cuda_check` logs the failing CUDA call as `"%s failed -> %s: %s"` using an `err_name`/`err_string` pair the error lookup does not always fill, and glibc then walks whatever was on the stack. We cannot patch the distro's FFmpeg, so the fix denies it the chance to format: the guard already used by the 4:4:4 probe drops the level to AV_LOG_FATAL across the open, and `av_log_default_callback` returns on the level check before `format_line` — these messages are AV_LOG_ERROR. The failure is not swallowed; it still comes back as `Err(e)` and is reported with our own context, which now says the libav text was deliberately silenced so nobody hunts for a message that will not come. Scoped to the `open_with` call ALONE. The ENOSYS arm immediately below recurses into `Self::open`, and `QuietLibavLog` holds a non-reentrant global mutex — wrapping the whole `match` would have deadlocked the intra-refresh retry. Verified on home-nobara-1 (fc44, libavcodec 62). With CUDA made unavailable so the open fails inside the CUDA layer, the old binary prints [hevc_nvenc @ ..] cuInit(0) failed -> CUDA_ERROR_NO_DEVICE: no CUDA-capable device is detected — that line IS `ff_cuda_check` formatting the two `%s` — and the fixed binary does not; both exit 1 with our error instead. A successful open is unaffected on both the direct-SDK and the libav paths (90/90 frames, identical output size). What this does NOT claim: the uninitialized-pointer condition itself was not reproduced on demand — it depends on the CUDA error lookup failing to fill the strings, and in the forced case above it filled them fine. What is demonstrated is that the formatting call which faulted is no longer reached during the open.	2026-08-10 07:46:47 +02:00
enricobuehler	890b67a863	fix(validation): v5 called jitter a leak — a leak is a trend, not a spread ... v5's verdict was `max - min` over the sampled fd counts with a default tolerance of 0. An encode worker's fd count legitimately moves by one when a dmabuf fd is in flight at the sampling instant, so the spread was permanently 1 and the leg failed on a perfectly healthy box — reported, like every red leg here, as "a shipping blocker, not a flake". Measured on home-nobara-1 (KDE, RTX 5070 Ti), 33 samples over 480 s: 54 54 54 54 54 54 54 54 55 55 54 54 54 55 54 54 55 54 54 54 55 54 …54 It oscillates and ENDS on 54, exactly where it started. Nothing accumulates. The replacement is median-of-thirds: median(last third) - median(first third). That is strictly MORE sensitive to what R2 is actually about — a steady leak moves the trend just as much as it moves the spread, while bounded jitter moves only the spread — so this is not the tolerance being widened to get a green. The spread is still printed, now labelled as jitter when the trend is flat. The warm-up window already covers the one-off first-sight-of-each-buffer cost, so a plateau inside it is by design not a leak; a step that never comes back still trends and still fails. The self-test grows the cases that force this to be a real assertion: the measured oscillation must trend to zero, a synthetic leak must still trend up, a flat series must be flat, and a step that never returns must be caught. Writing them is what caught my own arithmetic — the first draft asserted a leak trend of 12 where the reader correctly says 10. Also records what the v5 log now makes obvious: `--minutes` does NOT set the wall clock. `spike` is frame-count bounded (`seconds * fps`), and a KWin virtual output being driven hard delivers ~197 fps against a `--fps 60` budget, so a "10 minute" run ended after 182 s. Ask for more minutes than you want.	2026-08-10 03:04:05 +02:00
enricobuehler	9cdbfabd4d	fix(validation): v4.e demanded a rung the spike vehicle cannot reach ... v4.e killed the worker mid-session and then required "the encode worker died mid-session" in the spike's log. That line, and the respawn that follows it, are emitted by `RemotePyroWave::reset` — and the only caller of `Encoder::reset` is the real session's `reset_stalled_encoder` loop in native/stream.rs. `spike` is a dev tool with no recovery loop at all: it does encoder.submit(&frame).context("encoder submit")? and exits. So a worker killed under the spike can never reach reset, the line can never appear, and the leg reported FAILED — a red leg here is a shipping blocker, not a flake. for a ladder rung the product implements correctly. A false negative in the one place that must not have one: this kit exists to refuse false PASSes, and a false FAIL spends exactly the same credibility. Verified on glass first, so the rung is not being excused on a reading of the source. home-nobara-1 (KDE, RTX 5070 Ti), real client session, worker pid 44249 killed with -9: `video_streaming` stayed true across the kill, and the host logged pyrowave: respawned the encode worker after a mid-session death worker=/usr/bin/punktfunk-encode-worker priority=Granted(Realtime) encoder submit failed — encoder rebuilt in place, forcing an IDR error=... Broken pipe (os error 32) reset=1 max=5 v4.e now asserts the half the spike can actually observe — the death surfaces as an ATTRIBUTABLE worker-IPC error naming the worker, after real encode windows, and the host process does not die with it. A hang, an unexplained failure, or a dead host still fails. The respawn half is printed as the human follow-up, in the same idiom v1 already uses for its on-glass half, and written into `recipe` with the two commands that close it.	2026-08-10 02:38:55 +02:00
enricobuehler	fdef4c90ce	fix(gamescope): stop the PipeWire use-after-free that aborted a session on every connect ... A managed gamescope session on Nobara 44 (VM 123) died on essentially every client connect. The visible symptom was a black screen; underneath, `punktfunk-gamescope` was SIGABRT crash-looping — 11 coredumps in three minutes — until `gamescope-session-plus` ran out of retries and came up on the *stock* `/usr/bin/gamescope` at its default 1920x1080, which looks like a working game mode and carries none of our capture patches. punktfunk-gamescope: ../src/pipewire.cpp:88: void destroy_buffer( pipewire_buffer*): Assertion `false' failed. #4 __assert_fail #5 destroy_buffer(pipewire_buffer*).cold The abort is a use-after-free wearing an `assert(false); // unreachable`. `pw_buffer->user_data` is associated with its `pipewire_buffer` in exactly one place, at the bottom of `stream_handle_add_buffer` — after all four `goto error` paths, whose label is a bare `delete buffer`. And `stream_handle_remove_buffer` clears `buffer->buffer`, the only route back to the `pw_buffer`, while a still- `copying` buffer is deleted later on the steamcompmgr thread with no way to reach the slot. PipeWire recycles `pw_buffer` slots across renegotiations, so the next remove reads `buffer->type` out of freed memory, falls off the end of the switch and aborts. The host sets the session to the client's mode on connect, and that mode change is what renegotiates the stream — which is why "every connect" was the trigger. Patch 0007 fixes the association rather than the symptom: set `user_data` at allocation so it is valid on every path out of `add_buffer` and clear it on the error path; clear it in `remove_buffer`, the last point both halves are known; null-check the two consumers. The `default:` arm then logs instead of aborting. Offered upstream — nothing about it is punktfunk-specific. Two traps this cost time on, both now written down in the README: * It is NOT HDR-specific. The abort was first seen right after a 10-bit stream negotiated, so `PUNKTFUNK_GAMESCOPE_HDR=0` looked like a workaround. The failing argv carries no `--hdr-enabled` at all. * `gamescope-session-plus` hides it by falling back to stock gamescope, so a session existing proves nothing — read the banner. `.pfhdrN` moves to 5 even though no capability moved: every deployed pfhdr4 binary crash-loops, so an operator needs to be able to tell them apart. All `>=` thresholds in the host's probe are unaffected. Also documents `libstdc++-static` as a build dependency — it is punktfunk's requirement (the script links the C++ runtime statically on purpose), so no `dnf builddep` will ever pull it, and without it meson fails with a message naming neither the flag nor the package. Verified on VM 123 with the patched binary installed: 5 rapid connect/ disconnect cycles plus 3 further sessions, zero new gamescope coredumps (43 before, 43 after), Steam game mode streaming real content at 5120x1440, and `/tmp/chimeraos-short-session-tracker` never created — the short-session latch that used to strand the box in plasma was downstream of this crash.	2026-08-10 02:16:22 +02:00
enricobuehler	8508f8f3c3	Merge pull request 'The gamescope bind is armed on every gamescope box, takes a user namespace that breaks Xwayland, and leaves a drop-in that bricks the next boot' (#151) from worktree-bind-userns into main ... Reviewed-on: #151	2026-08-09 22:41:40 +00:00
enricobuehler	6695300b67	fix(pf-vdisplay): the gamescope bind took a user namespace that broke Xwayland, and left a drop-in that bricked the next boot ... Field-diagnosed on Nobara (fc44, canary g13179011), where Game Mode became unstartable and the box was handed to plasma. #144's bind works — the patched build genuinely reaches a session script that hardcodes /usr/bin/gamescope — but a mount namespace in a systemd USER unit is also a USER namespace, and only this uid is mapped in it. Measured on the box: on disk / in a unit without the bind : drwxrwxrwt 2 0 0 /tmp/.X11-unix in a unit WITH the bind : drwxrwxrwt 2 65534 65534 /tmp/.X11-unix uid_map inside : 1000 1000 1 wlroots checks that /tmp/.X11-unix is "owned by root or us", sees nobody, and refuses: wlserver: [xwayland/sockets.c:100] /tmp/.X11-unix not owned by root or us wlserver: [xwayland/sockets.c:217] No display available in the first 33 -> SIGSEGV in run_pipewire Three ~10 s failures then feed chimeraos' short-session tracker, session-plus stops even trying, and steamos-session-select rewrites the user's session to plasma. So the symptom an operator reports is "thrown onto KDE and I can't get back" — two removes from the cause. Two further bugs found while fixing it, each worse than the one reported: * THE BIND WAS ARMED EVERYWHERE. The condition was only `gamescope_bin() != /usr/bin/gamescope`, so every box with punktfunk-gamescope installed took a namespace it has no use for — Bazzite, SteamOS-likes, the Deck. The blast radius was every gamescope box, not just the hardcoded-path ones the mechanism exists for. Now the host READS the session script and arms only where it never mentions GAMESCOPE_BIN and names /usr/bin/gamescope outright; everything else is bit-for-bit pre-#144, no namespace at all. An unreadable script does not arm. * THE DROP-IN OUTLIVED ITS SOURCES. It was written to ~/.config/systemd/user/ on the TEMPLATE, so it also applied to the box's OWN autologin unit at every boot — while both paths it binds live in tmpfs. After a reboot the drop-in survives and its sources do not, and BindReadOnlyPaths= with a missing source fails the unit outright. THAT is why the field symptom survived a reboot. It now lives in $XDG_RUNTIME_DIR (dies with the login session), removal covers both the runtime and the legacy $HOME path, and restore_takeover_on_startup does that removal unconditionally at host start — which is the upgrade path for every box already running canary g13179011. Without it, updating the host would not un-brick them. * A bind was armed even when gamescope_bin() fell back to the bare name "gamescope". The wrapper execs `gamescope` through PATH inside the unit — onto the path we just bound the wrapper over. Fork bomb. Refused ahead of even the operator's force. Where the bind IS armed it now carries its own compensation: a user-owned $XDG_RUNTIME_DIR/punktfunk-x11 bound read-WRITE over /tmp/.X11-unix (Xwayland creates the socket there), so the ownership check sees "us". Skipped when that directory is already ours or absent — neither is the hazard. Stale sockets are pruned by connect-test so a SIGKILLed session cannot walk the 33 display slots away. And rather than trust that reasoning, the host now ASKS THE BOX before arming: it runs the field reproduction with the real property set — `systemd-run --user --wait --collect --property=<the same args> -- stat -c %u /tmp/.X11-unix` — and arms only if the answer is our uid. Anything else (65534, a rejected property, no user manager, a blown 10 s budget) means no bind, and the session runs stock gamescope: no HDR, no in-node cursor, but it STARTS. A runtime backstop disarms and relaunches if a session launched with the bind armed produces no node in its window, latching one-way per process. The XFixes-cursor concern that argued against relocating the socket does not hold: the only host-side X client is spawned under `plan.gamescope_cursor`, which is `gamescope && !gamescope_composites_cursor()`, and our shipped +pfhdr4 build is patch level 4 — so on the very route where the bind arms, that reader is never constructed.	2026-08-10 00:39:18 +02:00
enricobuehler	73d435b967	Merge pull request 'The driver clippy gate has been red on main since the Xbox pad landed' (#150) from worktree-drivers-clippy into main ... Reviewed-on: #150	2026-08-09 21:55:42 +00:00
enricobuehler	c7df7b45af	fix(drivers/pf-gamepad): the three Xbox identities as a range — the driver clippy gate is red on main ... `cargo clippy --all-targets -- -D warnings` over the shipped drivers (the step that enforces the unsafe-audit gates) fails on main since #149 landed: clippy 1.96's `manual_range_patterns` fires on all five `4 | 5 | 6` device-type arms, and `-D warnings` turns each into an error, so `pf-gamepad` fails to compile as both lib and lib-test and the whole step never reaches the other five crates. Device types 4/5/6 are the Xbox Wireless / One S / Elite Series 2 identities added by #149 — contiguous by construction, so `4..=6` is the same set. Purely a lint fix: no arm gains or loses a device type, and the comments that already record *why* the three share one report shape, one descriptor and one vendor string are untouched.	2026-08-09 23:46:43 +02:00
enricobuehler	5d7091bf87	Merge pull request 'The Windows Xbox pad: make games actually see it' (#149) from worktree-xbox-pad-wgi-visibility into main ... Reviewed-on: #149	2026-08-09 21:36:29 +00:00
enricobuehler	e19f11bb0d	feat(abi/apple): carry the trigger motors to non-Rust clients — ABI 18, next_rumble_cmd2 ... The `0xCA` wire already carries the two Xbox impulse-trigger motors (v3), and the Rust decode path already parses them; `datagram_task.rs` dropped them on the floor with a comment naming exactly this work as what remained. The blocker was the C ABI: every non-Rust client pulls rumble through `punktfunk_connection_next_rumble_cmd`, whose out-params cannot carry two more channels. PunktfunkStatus punktfunk_connection_next_rumble_cmd2( PunktfunkConnection *c, uint16_t *pad, uint16_t *low, uint16_t *high, uint16_t *left_trigger, uint16_t *right_trigger, uint32_t *backstop_ms, uint32_t timeout_ms); ⚠️ ADDED, not widened. `_cmd` keeps its signature and its values bit-identical for handle-only traffic — out-of-tree embedders depend on it and `docs/embedding-the-c-abi.md` documents it, so silently changing an exported symbol would break every consumer at once. `nm` on the staticlib shows all four rumble entry points still exported. `ABI_VERSION` 17 → 18; every other site reads it dynamically, so there are no hardcoded mirrors to drift. ⚠️ ONE HONEST BEHAVIOURAL DELTA, documented in `abi.rs` and pinned by a test: against a trigger-driving host a `_cmd` caller now receives commands with `low == high == 0` where the demux previously dropped the update entirely. They are idempotent handle stops, and the redundant-stop suppression cannot fold them because the command as a whole is not silent. Zero cost today — nothing sources non-zero triggers. The dedupe-jitter proof was RE-DERIVED rather than widened, which is the kind of thing that quietly rots when a tuple grows: the nudge touches only `low` by ±1 LSB and `emit` is only reached with a non-silent level, so the nudged tuple can collide with the four-field stop sentinel only at `(1,0,0,0)`. A test pins both directions — refuse at `(1,0,0,0)`, flip freely at `(1,0,lt,0)`. Apple renders them: `RumbleRenderer` gains `Motor?` slots at `GCHapticsLocality.leftTrigger` / `.rightTrigger` beside the existing handles. A controller without trigger actuators degrades silently — a nil engine yields a nil slot and `reconcile` no-ops — and absent localities are never logged, because on most pads that is the normal case rather than a fault. The macOS DualSense raw-HID branch stays a deliberate no-op: a DualSense has ADAPTIVE triggers, not trigger rumble motors, and inventing a mapping there would buzz the wrong thing. 🛑 BUILT AHEAD OF A PRODUCER, DELIBERATELY, AND NOTHING HERE CLAIMS OTHERWISE. Nothing can currently source trigger rumble on Windows and that is measured, not assumed: `XINPUT_VIBRATION` has two members, and GameInput — the only four-motor API — does not enumerate an xinputhid-promoted Xbox pad at all, verified against a REAL Microsoft Elite which is equally invisible to it while classic XInput reads it live. So this path has never been exercised end to end and the comments say so. VERIFIED * `cargo test -p punktfunk-core --features quic --lib` 378 passed on macOS, 203 on Windows; clippy `-D warnings` clean with and without default features; `cargo fmt --all --check` clean. * The generated header is regenerated and idempotent on re-run (CI diffs it). * SWIFT ACTUALLY COMPILES AND RUNS: `swift build` clean and `swift test` 262 passed / 0 failures in `clients/apple`, against a locally built xcframework. (Editor SourceKit errors about `PunktfunkCore`/`DualSenseHID` are index noise from that gitignored artifact — a real build resolves both, and the `DualSenseHID` references are untouched by this change.) * `cargo build -p punktfunk-host` clean on Windows. NOT VERIFIED * End to end — see above; there is no producer. * Whether a real Xbox pad on Apple actually reports the two trigger localities. The degrade needs no code, but the positive case is untested. * `pf-client-core` (the SDL renderer) does not build on macOS at baseline and is unbuilt here. It only reads `RumbleCommand` fields and never constructs one, so added fields cannot break it, but it still calls `_cmd`; wiring `SDL_RumbleGamepadTriggers` is separate work. ANDROID: NOT DONE, and it should stay that way for now. `pack_rumble` packs pad/backstop/low/high into bits 0..52 of a `jlong` with `-1` reserved as a sentinel — two more `u16` do not fit. The right fix if ever wanted is the direct-`ByteBuffer` shape `nativeNextHidout` already uses in the same file (zero-allocation, caller-owned, the established idiom), not a second `jlong` (racy across two calls) nor `long[]` (an allocation per pull). But no Android device exposes trigger actuators at all, so there is nothing to render. Separately stale and also not fixed: `NativeBridge.kt`'s KDoc still documents the v2 `ttl_ms` layout rather than `backstop_ms`.	2026-08-09 23:30:02 +02:00
enricobuehler	7f1f7ba87c	fix(pads/windows): say WHY a pad index is taken, and stop the devtest lying when it is ... Debugging the on-glass session, a devtest run died with error=create gamepad bootstrap mailbox Global\pfds-boot-0: Zugriff verweigert (0x80070005) (install/repair: punktfunk-host.exe driver install --gamepad) and then — this is the part that cost real time — kept printing "virtual Xbox One S Controller up", streamed frames into nothing, and let the operator measure the INCUMBENT pad on that index. The XInput packet count sat frozen and read as "the pad is dead", which was a wrong conclusion drawn from a harness that had already failed and not said so. WHAT IT ACTUALLY WAS. Pad lifetime is deliberately tied to the SESSION (native/input.rs: "the gamepads are created and torn down with the session"), and a live session's pad legitimately owns `Global\pfds-boot-0`. The mailbox's SDDL is `D:P(A;;GA;;;SY)(A;;GA;;;LS)` — SYSTEM and LocalService only — and the host service runs as LocalSystem while a hand-run devtest runs as an elevated Administrator, which is in neither ACE. `CreateFileMappingW` over an existing name is really an OPEN, access-checked against the incumbent's DACL, so it returned ACCESS_DENIED and bailed at the `?` BEFORE reaching the `ERROR_ALREADY_EXISTS` branch that already had the right sentence. That branch only ever fires when both processes run as the same account. The name is per-index on purpose and stays that way: `Global\pfds-boot-{index}` is the rendezvous the driver polls, and its existence doubles as host-liveness. Making it per-process would let two hosts build two devices on one wire index — the "the game sees two controllers" bug. The collision is correct; only the diagnosis was wrong. * `gamepad_raii.rs` classifies the failure: on ACCESS_DENIED it probes with `OpenFileMappingW`, which separates what the OS collapsed — object-manager lookup precedes the access check, so absent gives FILE_NOT_FOUND and present-but-forbidden gives ACCESS_DENIED. It now says the mailbox belongs to a live session's pad and that nothing is wrong with the drivers. * `pad_slots.rs` carries that as a typed `PadCreateFault` through the anyhow chain, so `ensure` prints the fault's remedy instead of the per-backend reinstall hint, plus the pad index. * `devtest.rs` now BAILS when no pad was actually built, instead of announcing success. This is the fix that matters: every probe an operator runs next will still find a device on that index. * `native.rs` names what a detached input thread still holds, since that is one of the ways a pad can outlive its session. DELIBERATELY NOT CHANGED, with reasons: the session-scoped pad lifetime (intentional and documented); the mailbox naming (load-bearing, above); the retry/backoff (latching would resurrect the `broken` flag `PadGate` exists to kill); the 10 s thread-detach in `serve_session` and the service's `TerminateProcess` shutdown — both are real ways a devnode can outlive its owner, but neither is evidenced in the field case and inventing a fix for an unobserved path is how you get a regression instead of a bugfix. `pf-inject/lib.rs` drops the `cfg(any(linux, windows))` gate on `pad_gate`/`pad_slots`. Neither touches an OS pad API, and the gate meant a classification whose entire subject is a `cfg(windows)` failure could not be tested on a dev machine at all. VERIFIED * ON WINDOWS (.173): `cargo test -p pf-inject --lib` 109/109; `cargo build -p punktfunk-host` clean. Both agents' Windows code was compile-UNVERIFIED before this run. * macOS: 5 new tests, including one that pins the anyhow downcast through the exact three-layer context chain the Windows code builds — the assumption that could not otherwise be checked. * `cargo fmt --all --check` clean. NOT VERIFIED * That a LocalSystem-owned mailbox really answers `OpenFileMappingW` with ACCESS_DENIED rather than FILE_NOT_FOUND from an Administrator token. That is reasoned from the object manager's lookup-then-access-check order, not measured. Repro on .173: hold a session pad on index 0, run the devtest from an elevated console, and check the new sentence appears.	2026-08-09 23:29:30 +02:00
enricobuehler	d39843a858	Merge pull request 'The Game Mode takeover blamed polkit for a group it never named, and prescribed two remedies that cannot work' (#148) from worktree-dm-helper-preflight into main ... Reviewed-on: #148	2026-08-09 21:17:36 +00:00
enricobuehler	fb309e0262	fix(pf-vdisplay): the takeover blamed polkit for a group it never named, and offered two remedies that cannot work ... Field triage on Nobara, 2026-08-09. Every connect degraded to ATTACH — which on that box mirrors a game-mode session the host never configured, and looked like a black screen on every connect. The host said: the packaged pf-dm-helper polkit action is missing or was denied (reinstall the punktfunk package, or install the display-manager polkit rule from the docs) Every clause of that was wrong. The action was installed, `allow_any`, and its exec.path annotation matched the installed helper; pkexec authorized it and RAN the helper. The helper refused, and said exactly why: pf-dm-helper: user 'nobara-user' is not in the 'punktfunk' group — refusing. Grant it with: sudo usermod -aG punktfunk nobara-user (then re-login) That text never reached the log, because `dm_helper` ran the helper with `.status()` — which discards stderr and collapses the exit code to a bool. The one thing that would have ended the investigation in seconds was thrown away at the call site, and the caller then guessed. Neither suggested remedy adds anyone to a group, so a reader who followed both stayed broken and learned the docs were useless. It fails soft, with no error and no failed unit, so nobody finds it on purpose. Now: `.output()`, and four failure modes that stay distinguishable because they need different fixes — helper not installed, pkexec could not run it, polkit denied it (pkexec's own 126/127), and the helper ran and refused, whose stderr rides through VERBATIM rather than being re-described. Null stdin too, so a pkexec that decides to prompt gets EOF instead of parking a stream thread on a tty read. The same gate gates the `linger` verb, so on a sessionless host an unjoined user fails there first — carrying the reason there as well, or the misdiagnosis just moves one message earlier. A new startup preflight says it before a stream is being built rather than during one, gated so it cannot nag a box that would never attempt a takeover: not root, a display-manager alias exists, a managed session launcher exists, a packaged helper exists, and the user is not in the group. It reads membership from the user database rather than this process's groups, deliberately: that is what the helper reads (it runs as root and resolves the caller from the database), so `usermod -aG` satisfies the DM gate immediately and the warning stops. Using `getgroups()` would keep warning on a box where the takeover already works. Packaging said the group was for "the virtual Steam Deck pad (usbip)" — so anyone without a Deck pad correctly skipped it and landed here by following instructions properly. All three scriptlets now lead with Game Mode, name both grants, and record that creating the group is necessary and NOT sufficient. Docs get the same treatment: the group is an admonition above the DM-flavor list in gamescope.md, a black-screen entry in troubleshooting.md that tells the reader to read the quoted reason FIRST, and the per-distro install pages no longer frame it as pad-only.	2026-08-09 23:15:34 +02:00
enricobuehler	94c2f62490	test(tools): a GameInput probe — and it cannot see our promoted Xbox pad ... `win-input-matrix` covered four of the five rows and said so; GameInput was the gap, because it has no binding in the `windows` crate and needs hand-written COM. This adds it: `--gameinput` reports whether GameInput has a reading, and `--gi-rumble l,h,lt,rt [--gi-pid PID]` drives `SetRumbleState`. Every vtable slot is taken from the SDK header, not guessed — a COM vtable is positional, so a wrong slot calls a different method with the wrong signature. WHY RUMBLE AND NOT JUST ENUMERATION. `XINPUT_VIBRATION` has two members, so classic XInput can never exercise an Xbox pad's two IMPULSE-TRIGGER motors. `GameInputRumbleParams` has four (`lowFrequency`, `highFrequency`, `leftTrigger`, `rightTrigger`), which makes GameInput the only API that can settle `design/trigger-rumble-plane.md` §2.1's open question — the `enable`-mask bit assignment for the two trigger actuators, where bits 2/3 (the handles) are measured and bits 0/1 (the triggers) are inferred from field order and nothing else. TWO THINGS MEASURED ON .173, 2026-08-09: 1. ⭐ GameInput's device enumeration is ASYNCHRONOUS, and the first `GetCurrentReading` reliably returns nothing even with pads actively reporting. This is the GameInput analogue of `wake_wgi`: the API looks like a query and is really a cache someone else fills. A bounded poll fixes it. ⚠️ Focus is NOT the cause, and the header rules it out rather than my guessing: `GameInputDefaultFocusPolicy` is 0 and every `GameInputFocusPolicy` flag is a RESTRICTION, so the default already admits background input. Do not "fix" this with `SetFocusPolicy`. 2. 🛑 **GameInput never sees our pad.** Hunting by product id for six seconds with the pad live and sweeping, it enumerated `054C:0CE6` (DualSense) and `3434:D031` (8BitDo) — both plain HID pads — and never `045E:02FD`, ours, while classic XInput was reading ours live in the same moment. ⇒ THE TRIGGER ENABLE BITS REMAIN CONJECTURE, but for a better reason than before: it is not that nobody has tried, it is that on this box NOTHING CAN DELIVER a four-motor rumble to our pad. XInput structurally cannot; GameInput can but does not see it. ⚠️ The obvious suspicion is that `xinputhid` claiming the HID collection exclusively is what hides the pad from GameInput — which would mean promotion costs us the API most Game-Pass-era titles use, a trade we have shipped by default. **That is NOT established here.** The decisive control is cheap and has not been run: power on the REAL Xbox Elite, which Microsoft's own driver promotes the same way, and see whether GameInput enumerates it. If a real promoted Xbox pad is also absent, this is a property of GameInput in a non-interactive session and not our defect — the same shape as the WGI `ts=0` row, which a real Elite reproduced. VERIFIED * `cargo fmt --check` clean; `cargo clippy --target x86_64-pc-windows-msvc --all-targets -- -D warnings` clean (cross-checked from macOS). * Builds and runs on .173; `GameInputCreate` succeeds, readings arrive after the poll, and `SetRumbleState` is accepted. * The runtime is loaded by name, so a box without GameInput reports "unavailable" rather than failing to link or crashing. NOT VERIFIED * That `SetRumbleState` reaches ANY pad's motors — it was accepted for the DualSense but nothing observable was checked on that device, and it never reached ours. * `GameInputDeviceInfo` is read only for `vendorId`/`productId` (offsets 4 and 6). The rest of the struct has variable-size members whose layout would have to be mirrored exactly; nothing here needs them. `supportedRumbleMotors` is in there and would answer "does GameInput think this pad has trigger motors" — worth adding if this line of enquiry continues.	2026-08-09 22:55:17 +02:00
enricobuehler	2b1843ed1c	fix(drivers/pf-gamepad): the right stick is Z/Rz — as declared, it was dead ... Found on glass, first real streaming session: everything worked except the right stick, and Steam correctly showed "Xbox One S Controller". `XBOX_RDESC` declared the right stick as `Rx`/`Ry`. `xinputhid`, which translates our HID collection into XUSB, maps `Z`/`Rz` to the right stick and does not treat `Rx`/`Ry` as one, so those two axes reached nothing. Two usage bytes. Left and right were declared identically here — same collection, same globals, same size and count — so the usages were the entire difference, which is what makes the diagnosis airtight rather than plausible. Note `DUALSENSE_RDESC`, a real capture, also uses `Z`/`Rz` for its right stick and puts the TRIGGERS on `Rx`/`Ry`; that is most likely where the original mistake came from. ⚠️ Byte offsets are unchanged — still 16×2 at bit 5.0 — so `xbox_proto`'s layout tests and the host-side packing are untouched. This is a pure relabelling. 🛑 THE REAL LESSON IS THE HARNESS, AND IT IS FIXED HERE TOO. This survived every bench measurement because `dualsense-windows-test` drove LS-X and the A button and left the other five analogue axes at zero. `XInputGetState` read `RX [0..0]`, which I read as "the devtest doesn't move it" — true, and useless: a harness that exercises one axis cannot tell "this axis is not mapped" from "nothing is driving it", and the two are indistinguishable in every consumer. The devtest now sweeps all six axes on distinct phases and ramps both triggers, so one run shows which axes arrive AND that they are not crosstalking onto each other's bytes. MEASURED ON .173, same run shape before and after, devtest sweeping all six axes: before: LX [-11264..24576] LY [-32768..31744] RX [0..0] RY [-1..-1] LT [0..248] RT [7..255] after: LX [-8192..26624] LY [-32768..31744] RX [-32768..31744] RY [-24576..10240] LT [0..248] RT [7..255] VERIFIED * `cargo test -p pf-inject --lib` 104/104 on Windows; `xbox` subset 11/11 on macOS — the layout tests still pass because nothing moved. * Driver rebuilds and signs; the descriptor is still 223 bytes so the `wReportLength` const assert is undisturbed. * `cargo fmt --all --check` clean. NOT VERIFIED * Not yet re-tested in a real streaming session — that is the next on-glass run. * ⚠️ A leftover finding from the same session, unrelated to this fix and NOT investigated: the session's pad devnode SURVIVES client disconnect and keeps the `Global\pfds-boot-0` bootstrap mailbox, so a devtest run afterwards fails with `Zugriff verweigert (0x80070005)` and silently measures the stale pad instead. Restarting the service releases it. Worth its own look.	2026-08-09 22:19:25 +02:00
enricobuehler	4f9071b980	feat(pads/windows): three Xbox identities — Wireless, One S and Elite Series 2 ... Until now there was one Xbox identity, `device_type = 4` / `045E:0B13`, and Windows folded a client's `XboxOne` request onto it because the only Windows Xbox backend was the XUSB companion, which presents one fixed 360 identity and cannot vary it. The HID backend can, so the fold goes and two identities join it: devtype 4 045E:0B13 pf_xboxwireless Xbox Wireless Controller devtype 5 045E:02FD pf_xboxones Xbox Wireless Controller (One S) devtype 6 045E:0B22 pf_xboxelite Xbox Elite Wireless Controller Series 2 `GamepadPref::XboxElite` takes wire byte 11 — the first unassigned one, and the round-trip test previously asserted `from_u8(11) == Auto` with a comment saying assigning it must update that; the sentinel moved to 12. The C ABI mirror and the generated header moved with it. ⭐ ALL THREE SHARE ONE REPORT DESCRIPTOR, deliberately. In HID terms they are the same pad; the descriptor is the report shape, not the identity. §3 of the handoff records that our single hand-written descriptor already cost three separate bugs, and inventing two more would multiply that debt for no measured gain. They differ in VID/PID, product string, hardware id and Device Manager description only. ⚠️ All three install `pfGamepadXbox`, the section that attaches the `xinputhid` bus filter. That was the open risk: Microsoft's `xinputhid.inf` promotes by an explicit hardware-id allow-list containing `02D1, 02DD, 02E3, 02EA, 0B00, 0B0A, 0B13, 02FF` — and NEITHER `02FD` NOR `0B22` is on it. Measured on .173: promotion does not care, because it comes from our own AddReg rather than from matching Microsoft's ids. All three gain `IG_00`, register an XUSB interface, and are read live by classic XInput. Had this gone the other way the two new identities would have been strictly worse than the one they joined. The XUSB escape hatch needed a runtime degrade to stay honest. `pick_gamepad` is compile-time only, so with `PUNKTFUNK_XBOX_BACKEND=xusb` the host would have resolved and echoed `xboxelite` in its `Welcome` while actually building a 360 pad. `degrade_xbox_identity` folds the identity back at runtime, mirroring `degrade_if_no_uhid`. VERIFIED ON WINDOWS (.173 — none of this compiles on macOS; the driver needs the WDK and the rest is `cfg(windows)`): * `cargo test -p pf-inject --lib` 104/104 — including `hwid_matches_inf`, `hwid_devtype_table_matches_the_driver` and `only_the_xbox_identity_installs_the_xinputhid_section`, all now sweeping the whole identity set and asserting the section split in both directions. * `cargo test -p punktfunk-core --lib gamepad` 7/7; `cargo check -p punktfunk-host` clean. * Driver builds and signs; the descriptor/`wReportLength` const asserts still hold with the descriptor shared three ways. * ON GLASS, per identity, via the new `--xboxones` / `--xboxelite` devtest legs: each gets its own devnode (`PF_XBOX_0` / `PF_XBOX_ONES_0` / `PF_XBOX_ELITE_0`), each HID child gains `IG_00`, each registers an XUSB interface, and XInput reads each live (packets advancing, `buttons=0x1000`). * macOS: `cargo fmt --all --check` clean in both workspaces. NOT VERIFIED / NOT DONE * **Elite paddles are NOT implemented.** `BTN_PADDLE1..4` would need descriptor buttons, and once `xinputhid` promotes the pad it claims the HID collection exclusively — XInput has no paddle fields and the HID consumers that do may be locked out, so the buttons would likely reach nobody. The decisive measurement is cheap and named in the code: hold a paddle bit set and see whether a user-mode HID reader still gets reports. Until then the Edge remains the only virtual pad with native back-button slots and nothing should be advertised otherwise. * **No client picker offers the Elite**, and none can auto-detect it — SDL3's `GamepadType` has no Elite variant. It is reachable today only via `PUNKTFUNK_GAMEPAD=xboxelite` or a hand-edited client setting. All five clients ship the same curated six options by deliberate parity, so adding one is a cross-client UX change, not part of this. * Nothing here has run in a real streaming session; every measurement came from the devtest.	2026-08-09 21:41:53 +02:00
enricobuehler	1317901122	Merge pull request 'Uninstalling the Windows host left every audio device it minted behind forever — and the installer script documented that as a decision' (#145) from worktree-win-audio-uninstall-cleanup into main ... Reviewed-on: #145	2026-08-09 19:30:31 +00:00
enricobuehler	620f017d9a	fix(validation): tell the CAPTURE it is a PyroWave session, or NVIDIA hands it a CUDA buffer ... `--codec pyrowave` selects the ENCODER. The capture pipeline picks its consumer from `ZeroCopyPolicy::pyrowave_session`, which on the spike path is fed only by the global `PUNKTFUNK_ENCODER=pyrowave` lab lever (punktfunk-host/src/capture.rs). Without it, .21 resolved capture pipeline resolved: cuda-import -> nvenc capture_arm="cuda-import" consumer="nvenc" zero-copy: dmabuf imported to CUDA (no CPU copy) nv12=true and the wavelet encoder refused the payload on its first submit: "unsupported FramePayload (need Dmabuf or Cpu RGB)". That is not a worker bug — the arm that failed was the pure in-process one. It reproduces only where the A/B actually lives. An AMD box has no CUDA arm to pick, so .25 resolved straight to dmabuf-passthrough and the kit looked correct there. With the lever set, .21 resolves `dmabuf-passthrough -> pyrowave` and both arms encode 2700/2700 frames. V3b then passes on .21 (RTX 5070 Ti, GRID 2 at ~100% GPU, 5120x1440 — the portal captures the real monitor, --width/--height being synthetic-only): in-process, refused p50 2.85 ms p99 8.39 ms (10 windows) capped worker, granted p50 2.65 ms p99 4.10 ms (11 windows) p99 delta -4.29 ms The worker reports `priority=Granted(Realtime)` with `ext=VK_KHR_global_priority` on the FIRST attempt and logs no fallback line; the refused arm logs "every global queue priority class was refused". So the capability still buys the lever from a SEPARATE process, with the IPC hop in the loop — 8.39 -> 4.10 ms is a 51% p99 cut, against PW1's in-host 6.4 -> 4.4 at 1080p. Different resolution and a harder load, so treat the class as confirmed and the absolute numbers as not comparable to PW1's.	2026-08-09 21:23:57 +02:00
enricobuehler	854b14a52e	fix(validation): a leg that never ran must say so, not blame the arm ... The V3b run on .21 died with `open portal capturer: timed out waiting for the ScreenCast portal` — a GNOME consent dialog nobody answered — and the kit reported "arm A is not the in-process arm". That is false: the arm was constructed correctly (`PUNKTFUNK_ENCODE_WORKER=off` is right there in the captured env header), it simply never reached encoder-open, so the line the assert looks for could not exist. A red that points at the wrong thing costs the same debugging time as a green that hides a real one. `spike_failure_reason` now runs BEFORE any arm-identity assert in v2, v3a and v3b, and names the actual cause: the portal timeout gets its own message saying the dialog appears on the HOST's own screen and cannot be answered from inside a stream — which is precisely the situation that produced this failure, since the operator was watching the box through a game session at the time. Falls back to the first ERROR line, then to "no PUNKTFUNK_PERF window at all", so a spike that dies some other way still reports that rather than a misattribution.	2026-08-09 21:15:46 +02:00
enricobuehler	bd5735b803	feat(pads/windows): make the HID Xbox pad the default, and carry the trigger motors on the wire ... Three changes that only make sense together: the HID backend becomes the default now that it is a superset of the XUSB one, the rumble datagram grows the two Xbox impulse-trigger motors, and the INF-shape tests learn about the Xbox identity's own install section. WP-E — `PUNKTFUNK_XBOX_BACKEND` now defaults to `hid`; `=xusb` is the escape hatch. The knob existed for exactly one reason, recorded in its own doc comment: the HID pad could not reach classic XInput, so defaulting to it would trade a known-working path for an unproven one. That objection is gone — with the `xinputhid` bus filter the INF now attaches, the HID pad is promoted like real hardware and keeps classic XInput while gaining everything XUSB never had (Steam, SDL, RawInput, DirectInput, joy.cpl, WGI) plus rumble, which XUSB could not source at all. The escape hatch stays because promotion leans on Microsoft's inbox `xinputhid.inf`; if a servicing update changes it, one env var restores the old behaviour with no reinstall. An unrecognised value takes the DEFAULT rather than the opt-out, so a typo cannot silently drop a user onto the path with no HID collection. WP-D — the `0xCA` rumble datagram gains a v3 form: v1 7 B: [0xCA][u16 pad][u16 low][u16 high] v2 10 B: … [u8 seq][u16 ttl_ms] v3 14 B: … [u16 lt][u16 rt] v3 is built FROM v2's bytes rather than restating the layout, so the prefix relationship is structural instead of a convention two encoders have to keep agreeing on, and every reader gates with `>=`. The four levels share one seq and one ttl on purpose: they are one statement of the pad's feedback at one instant, and sharing means the whole v2 apparatus — renewal cadence, stop burst, the client's seq gate, the lease clamp — governs the triggers with no new code. The new `RumbleUpdate` fields are plain `u16`, not `Option`: on a level-triggered plane "absent" must mean zero, because "absent → keep the previous value" is the stuck-rumble bug in a new costume. Only one backend can ever source them — the Windows HID Xbox pad, whose output report 0x03 carries them. `XINPUT_VIBRATION` and evdev `FF_RUMBLE` have two members and no third, so every other producer sends `lt = rt = 0`. ⚠️ The two TRIGGER `enable`-mask bits remain CONJECTURE. Bits 2/3 = left/right handle are measured; bit 0/1 = the triggers are inferred from field order and nothing else. `parse_xbox_output` says so inline, and no test asserts them — every test vector uses masks (0xFF, 0x00, 0x0C, 0xF3) whose expectations hold whichever bits turn out to be right. XInput cannot settle this: it has two motors. The INF tests — `hwid_matches_inf` matched the install section by the exact string `=pfGamepad,` and so stopped seeing the Xbox hardware ids the moment that identity moved to its own `pfGamepadXbox` section. It failed loudly, which is the good outcome; it is now prefix-matched and tolerant of further per-identity sections. Added `only_the_xbox_identity_installs_the_xinputhid_section`, which asserts the split in BOTH directions: the Xbox line must not install the shared section, and no other line may install the Xbox one. Merging them back is a one-line edit that looks like tidying and would hand a DualSense to Microsoft's Xbox translator. VERIFIED * ON WINDOWS (.173, the only place this code compiles): `cargo test -p pf-inject --lib` 104/104, including the new trigger tests and both INF tests; `cargo check -p punktfunk-host` clean. * macOS: `cargo fmt --all --check` clean; `cargo test -p punktfunk-core --features quic` rumble suite 22/22, including v3 round-trip and v3<->v2 cross-version parsing. * The pre-existing `c_abi_harness_round_trips` failure on macOS is `ld: library 'opus' not found` and reproduces with these changes stashed. NOT VERIFIED * No trigger rumble has ever been observed end to end — nothing can drive it yet (see the conjecture note above), and no client renders it. * The default flip has NOT been exercised in a real streaming session; every measurement so far came from the devtest harness. That is the on-glass run. * Non-Rust clients do not decode v3. They are blocked on a C ABI entry point first (`punktfunk_connection_next_rumble_cmd` has fixed out-params, ABI_VERSION 17); Apple could render it via GCHapticsLocality.leftTrigger/.rightTrigger, Android structurally cannot (its packed jlong is full) and has no trigger actuators anyway.	2026-08-09 21:10:08 +02:00
enricobuehler	7a9fa4501c	Merge pull request 'Nobara could never use the patched gamescope — and the RPM it was told to install was unsigned' (#144) from worktree-gamescope-pin-bump-nobara into main ... Reviewed-on: #144	2026-08-09 18:53:59 +00:00
enricobuehler	d87a8df28d	fix(windows): uninstall removes the audio devices the host mints ... The field report: uninstalling punktfunk left "Punktfunk Speakers", "Punktfunk Microphone" and the per-pad "Wireless Controller" endpoints sitting in Windows' Sound settings forever. They have no installer payload behind them, which is why nothing in the uninstall touched them. The host mints them at RUNTIME as extra devnodes on Valve's streaming-audio drivers, and both providers deliberately re-resolve their devnode across restarts instead of re-minting it — so they persist by design. Persistent across restarts must not mean permanent: the .iss even documented leaving them behind as a decision. New `driver uninstall --audio` leg (a third Inno [UninstallRun] entry, after the two driver legs and well after `service uninstall`, since a live host re-mints on its next wiring pass): * restores the default playback device first, if a host that died mid-stream left it parked on our loopback sink — otherwise Windows re-picks by its own ranking rather than giving the operator back the device they had; * removes every MEDIA-class devnode carrying one of our three durable owner markers (pad slot, minted role, probe), phantoms included; * deletes each endpoint's MMDevices record, resolved through the devnode link BEFORE the devnode goes. Marker-matched, never name-matched: our instances are name-identical to Steam's own, and Steam's devnodes, its drivers, and a VB-CABLE from the era when we bundled one carry no marker and stay untouched. A ROOT\ enumeration guard means a marker-shaped value on a real sound card can never cost the user their hardware. The registry half is best-effort: those keys are SYSTEM-owned and the uninstaller runs elevated but as a user, so on a stock box the record survives as an inert NOTPRESENT entry that Sound settings only shows behind "Show Disconnected Devices". The device itself is gone either way, and seizing ownership of SYSTEM registry keys from an uninstaller is a worse thing to ship than that scrap.	2026-08-09 20:53:22 +02:00
enricobuehler	46390739d8	fix(pf-vdisplay): the box's OWN session unit needs the gamescope bind too ... `launch_session` spawns a transient unit and can hand `systemd-run` the `BindReadOnlyPaths` directly, but a box that owns an autologin `gamescope-session-plus@<client>.service` is RESTARTED IN PLACE instead — no `systemd-run`, so that path kept running Nobara's hardcoded `/usr/bin/gamescope` and the previous commit fixed only half the problem. Found on the box: after a reboot the host took the `ensure_box_gamescope_mode` path (the autologin unit was live) rather than the managed one. Deliver the same two fixes as a drop-in on that unit — the bind, and the WSI opt-out when the box's layer was built for a different gamescope — plus `PF_HZ`/`PF_HDR_ARGS`, which the wrapper reads and would otherwise default to 60 Hz. `daemon-reload` before the restart or systemd runs the old unit. Best-effort: a failure to write it must not block a restart that would otherwise work, and it is a no-op on a box already resolving to `/usr/bin/gamescope`. ⚠ REMOVED on restore, deliberately. Leaving it would put the patched build — and our HDR and cursor flags — under the user's ORDINARY game mode, which is exactly what `packaging/gamescope/README.md`'s "sits BESIDE the distro package" rule exists to prevent. The bind is ours only for as long as we are driving the session. `ensure_box_gamescope_mode` grows an `hdr` param to build those args; both call sites already had it in scope (`self.hdr`, and `create_managed_session`'s parameter). Gate: `scripts/xcheck.sh linux clippy` clean (0 warning/error lines), `cargo fmt` clean.	2026-08-09 20:28:00 +02:00
enricobuehler	77f0a25d18	feat(drivers/pf-gamepad): ship the xinputhid bus filter, so Windows finally promotes our Xbox pad ... The field report that started this work was an Xbox controller that no game could see on a Windows host for two weeks. Root cause was that our Xbox pad reaches no Windows input API a modern title uses. This is the fix, and it is two registry values. Windows promotes Xbox pads with `xinputhid`, whose INF is an explicit hardware-id ALLOW-LIST — its own comment says "we can not use a Compatability ID for the loading of this driver, and so rely on individual hardware IDs". A software-enumerated devnode can never match those ids, so we write what the matching install sections would have written. `045E:0B13`, the PID this identity already claimed, is on that allow-list twice, so the identity choice turned out to be exactly right. 🛑 THE PAIRING IS THE WHOLE FINDING, AND THE TWO VALUES GO IN DIFFERENT KEYS. `UpperFilters` is a `.HW` AddReg (hardware key); `DevicePropertyFlags` is a DDInstall AddReg (software key). A live A/B on .173: removing `DevicePropertyFlags` alone reverts EVERYTHING — no `IG_00`, no XUSB interface, no XInput, no WGI entry — while `UpperFilters` alone is completely inert. `1` = `BusDevice`, which Microsoft glosses as "a focused bus filter driver for the IG_ problem". It is not a description of the device, it is the switch. An earlier session installed the filter WITHOUT it, measured a device that produced nothing, and recorded "never ship it". The filter was never broken; it had never been switched on. That conclusion is now retracted. ⚠️ The Xbox line gets its OWN DDInstall section, `pfGamepadXbox`. All five identities previously shared `pfGamepad`, so an AddReg there would have handed a DualSense, DualShock 4, Edge and Steam Deck to Microsoft's Xbox translator. The regression check below exists for exactly that. MEASURED ON .173 (Win11 26200), INF-SHIPPED — no hand-written registry values: * `UpperFilters=xinputhid` lands on the hardware key and `DevicePropertyFlags=1` on the software key, applied by the INF at install. * The HID child gains the `IG_00` token: `HID\PUNKTFUNK&IG_00\...`. * An XUSB interface appears: `\\?\hid#punktfunk&ig_00#...#{ec87f1e3-...}`. * classic XInput reads it live — packets ADVANCING, `buttons=0x1000` (the devtest's A), and the stick sweeping. XInput had NEVER seen this backend before. * `XInputSetState` rumble round-trips: `rumble from game: pad=0 low=65535 high=32767`. * REGRESSION CHECK PASSED: with the DualSense identity up, its devnode has an EMPTY `UpperFilters` and no `DevicePropertyFlags`. The PlayStation pads are untouched. WGI `Gamepad` lists the pad but reads `ts=0`. That is NOT ours: a real Xbox Elite Series 2, promoted by Microsoft's own driver on the same box, reads `ts=0` in WGI at the very moment classic XInput is reading live data from it (`buttons=0x1000 LY=-32768`). Our pad is behaviourally indistinguishable from real hardware here; the row is a property of the non-interactive session. NOT VERIFIED * On-glass in a console session. Everything above ran over ssh, which is what makes the WGI row unreadable; the real-Elite control is what settles it, not a clean WGI reading. * GameInput — no binding in the `windows` crate, still unmeasured for this backend. * `PUNKTFUNK_XBOX_BACKEND` still defaults to XUSB. This changes what the HID backend CAN do; it does not change which backend is chosen. That is WP-E and it is a separate decision. * Trigger-actuator enable bits, still conjecture — `XINPUT_VIBRATION` has two members and cannot exercise them.	2026-08-09 20:18:49 +02:00
enricobuehler	3500e95660	fix(pf-vdisplay): make Nobara's session run the patched gamescope, and stop the WSI layer killing every client ... Two independent reasons a Nobara box could never stream from a gamescope session, both found on glass (VM 123, Nobara 44, RTX 5070 Ti). **1. The session ran a stock gamescope, so the host refused it.** Nobara's `gamescope-session-plus` builds its command as GAMESCOPECMD="/usr/bin/gamescope \ and reads `GAMESCOPE_BIN` NOWHERE. All three of our spawn levers miss at once: the env var is ignored, and an absolute path cannot be redirected by a PATH shim. So the session ran stock gamescope, the capability probe rejected it, and every session died with "pipeline build failed (out of retries) … it ignored GAMESCOPE_BIN / the PATH shim". `~/.gamescope-cmd.log` — which the script writes with the exact command it ran — settles that in one line, and is the first thing to read on any such report. Fixed by binding our wrapper over `/usr/bin/gamescope` inside the transient unit's mount namespace (`BindReadOnlyPaths`). Deliberately a bind, not a replacement: punktfunk-gamescope ships under its own name precisely so it sits BESIDE the distro package, and the bind is scoped to the session — nothing outside it sees the redirect and nothing is written to `/usr`. Skipped when the resolved binary already IS `/usr/bin/gamescope`. **2. With the patched gamescope finally running, every Vulkan client died — black screen.** The box's `VkLayer_FROG_gamescope_wsi` ships with the DISTRO's gamescope and speaks its `gamescope_swapchain` protocol. Ours disagrees, so the compositor rejects the client's `swapchain_feedback` ("message too short") and drops it. Steam never paints; there is no other symptom, which is what makes it expensive to find. Measured with `vkcube` under each build, layer on: ours 3.16.25-17 ON -> 1 rejected client ours 3.16.25-17 OFF -> 0 OLD pin 3.16.25-4 ON -> 1 rejected client stock 3.16.23.2 ON -> 0 ⭐ The upstream protocol XML is BYTE-IDENTICAL between the distro's commit (5cdb5b0) and our pin — same interface version, same `uuuuuus` signature — so this is the distro patching gamescope, not a version bump. Hence the gate is "do the upstream triples differ", not a floor, and an unreadable version on either side leaves the layer alone rather than degrading a box that works (Bazzite/SteamOS, where it has always been fine). ⚠⚠ The old pin fails identically, so REVERTING the pin bump fixes nothing here — this is pre-existing, not a regression from 5fb8dce4. Verified against the UNPATCHED distro script, reproducing exactly what this code emits: the session's own log reports `punktfunk-gamescope version 3.16.25-17-ga87390d+pfhdr4`, with 0 swapchain_feedback errors, 0 client-communication errors and 0 aborts. Gate: `scripts/xcheck.sh linux clippy` clean (0 warning/error lines), `cargo fmt` clean. Non-vacuity re-verified per the xcheck note — a planted type error in the new function produced 3 errors, and removing it went back to Finished. Still open, deliberately NOT addressed here: a 10-bit HDR stream aborts gamescope in `destroy_buffer` (upstream `pipewire.cpp:88`), which is a separate defect.	2026-08-09 20:15:52 +02:00
enricobuehler	f9fe496dbc	feat(drivers/pf-gamepad): declare the rumble output report, and the Xbox pad gets rumble at all ... `XBOX_RDESC` declared no OUTPUT item — zero `0x91` bytes. hidclass routes an output report only if the descriptor declares one, so `on_output_report` never fired, `publish_output` never wrote the out-ring, and `parse_xbox_output` in `inject/windows/xbox_windows.rs` was unreachable code. The entire host-side rumble plane was already built, wired and tested, and was simply never fed. The HID Xbox pad therefore had NO rumble whatsoever, not merely no trigger rumble. This appends the PID-page `Set Effect Report` collection, report id `0x03`, 8 payload bytes, sized to exactly the layout `parse_xbox_output` and `design/trigger-rumble-plane.md` §2.1 already specify. It is declared AFTER the final Input item and re-states every global it uses, so the 16-byte input layout `xbox_proto`'s tests pin is untouched. ⚠️ PROVENANCE: hand-written, and it could not be otherwise. The Elite capture taken for WP-A reports `OUTPUT items: 0` — Windows exposes no literal descriptor bytes and the reconstruction carries no output collection for that pad — so there was nothing to copy. The comment says so and asks for a Linux hidraw capture to replace it. Also adds a compile-time assert pairing every descriptor with its HID-descriptor `wReportLength`. Those are two copies of one length, edited in different places, and a mismatch fails SILENTLY: hidclass asks for `wReportLength` bytes, parses whatever it got, and the pad either enumerates truncated or not at all with nothing naming the cause. It now cannot build out of step. This caught nothing today because I updated both by hand, but it is exactly the trap this descriptor has already sprung twice in other forms. MEASURED ON .173 (Win11 26200), with the pad promoted via the WP-B0 xinputhid bus-filter config: * `XInputSetState(0xFFFF, 0x8000)` produced, on the host side, `rumble from game: pad=0 low=65535 high=32767` `rumble from game: pad=0 low=0 high=0` i.e. XInputSetState -> xinputhid -> HID output report 0x03 -> on_output_report -> out-ring -> parse_xbox_output -> PadFeedback. First rumble this backend has ever delivered. * The round-trip values confirm the descriptor's `Logical Maximum (100)` percent domain is right: 0x8000 -> 50% -> 32767. A 0..255 domain would have produced different numbers. * This also answers `trigger-rumble-plane.md`'s WP0 gate — YES, Windows writes output reports to a synthesized 045E:0B13 — which was blocking the whole trigger plane. * classic XInput reads the pad fully: packets advancing, `buttons=0x1000` (the devtest's A), and `LX [-32768..31744]`, the complete sweep. LY/RX/RY frozen is correct; the devtest drives only LS-X and A. VERIFIED * `cargo test -p pf-inject --lib xbox` 11/11 — the input layout is byte-identical, as intended. * `hid-descriptor-dump --rust-source ... --symbol XBOX_RDESC` decodes it clean: input report 0x01 unchanged at 16 bytes and the same offsets, new output report 0x03 at 9 bytes on the wire, feature 0x85 unchanged, `structure: OK`. * Driver builds and signs on .173 with the WDK; the new const asserts compile, so all five descriptor/wReportLength pairs agree. * fmt clean on both tools; .173 fully reverted afterwards. NOT VERIFIED * The enable-mask bit assignments for the two TRIGGER actuators. `XINPUT_VIBRATION` has only two members, so XInput can never drive them and this run could not exercise them. Still open, as trigger-rumble-plane.md WP0 says. * That this equals the real pad's output collection, byte for byte. Needs Linux hidraw. * Nothing about the INF is changed: `pf_gamepad.inx` still has no AddReg, so none of the promotion config ships. The rumble descriptor is inert until something drives it.	2026-08-09 20:07:34 +02:00
enricobuehler	13438b1287	test(tools): ask Windows which input APIs can see the pad, and find what promotes it ... The Xbox-pad-on-Windows programme is a five-row matrix — classic XInput, WGI `Gamepad`, WGI `RawGameController`, GameInput, and the HID/DirectInput/Steam family — and nothing in this tree measured any of it. Every reading in the handoff came from ad-hoc off-tree tools, which is why several could not be reproduced later and why one was a false positive. `win-input-matrix` makes the matrix a command you can run twice and diff. Two traps are baked into it because both have already cost this programme a wrong conclusion. `--watch` samples repeatedly and reports LIVE vs MUTE per device, because an API listing a pad that never reports is the exact failure mode here — worse than not listing it, since a title that binds the first gamepad latches a dead one. And the doc comment insists on a baseline with the virtual pad STOPPED: a real Xbox pad owns XInput slot 0, which is how `rc=0 LX=-885` was once read as success with our pad already killed. ⭐ `wake_wgi()` is not optional and is commented as such. `Gamepad::Gamepads()` and `RawGameController::RawGameControllers()` return a cache filled by WGI's device-watcher, which a GUI app has already started and a console app has not. Without subscribing to the Added events first, BOTH collections come back empty with real controllers attached — measured here: a DualSense sitting in the HID interface class, `RawGameControllers` count=0. A probe missing this reports "WGI cannot see the pad" when WGI could not see anything. WHAT IT FOUND (full record in measurements/2026-08-09-xbox-hid-xinputhid-busfilter.md): with `UpperFilters=xinputhid` on the pad's PARENT devnode AND `DevicePropertyFlags=1` in that parent's SOFTWARE key, the HID Xbox pad is promoted for the first time — the child gains the `IG_00` token, an XUSB interface appears, classic XInput admits it, and WGI `Gamepad` lists it. All four had never happened on this backend. A one-value A/B proves `DevicePropertyFlags` is the decisive half: removing it alone reverts all four. That retro-explains the earlier "the filter installs fine and produces nothing" result — the filter was loading without ever being put in bus-filter mode, which is what `BusDevice = 0x1` means in Microsoft's own comment in `xinputhid.inf`. Not a workspace member, for the same reason as `hid-descriptor-dump`: it is a Windows-only bring-your-own-hardware tool with no business on a CI leg. VERIFIED * `cargo fmt --check` clean; `cargo clippy --target x86_64-pc-windows-msvc --all-targets -- -D warnings` clean (cross-checked from macOS; the target is installed). * Builds and runs on .173 (Win11 26200). * Self-checked against known-good hardware before any conclusion was drawn from it: baseline reads the USB DualSense as LIVE in both WGI collections and the resting 8BitDo as MUTE. * The A/B was run in both directions on the same box in one session. * `cargo metadata` on the root workspace resolves and does NOT list this crate. * .173 fully reverted: registry values removed, devnodes removed, oem100.inf deleted, both certs delstored, 6 pre-existing pf_gamepad packages and the production service untouched. NOT VERIFIED * GameInput — no binding in the `windows` crate, needs hand-written COM vtables. Not covered; the doc comment says so. * That the promotion survives a reboot or a devnode re-create from a shipped INF `AddReg` rather than a hand-written registry value. Nothing is shipped: `pf_gamepad.inx` is UNCHANGED and still contains no AddReg of any kind. * WHY the promoted pad still translates no data. Enumeration is fixed; translation is not. The evidence points at the report descriptor, which is gated on the §3.3 decision.	2026-08-09 19:24:28 +02:00
enricobuehler	ae35e8b4d7	test(tools): capture the real Xbox descriptor, because ours was invented and disagrees with it ... `XBOX_RDESC` is the only report descriptor in `pf-gamepad` that was hand-written rather than captured off hardware, and its own provenance warning has now come true three times. The fix for that class of bug is not another careful reading — it is a tool that goes and asks the device. `tools/hid-descriptor-dump` does that: it dumps a real HID device's report descriptor, decodes it into an annotated item listing plus a bit-offset LAYOUT TABLE, and can decode a blob we already ship through the same decoder (`--rust-source <file> --symbol <NAME>`) so the two are diffable line for line. `--read N` pulls live wire bytes, which is the only ground truth a reconstructed descriptor cannot give you. Deliberately NOT a workspace member — it pulls `hidapi`, a C library wanting libudev on Linux, which has no business in `cargo build --workspace` or on a CI leg with no pad attached. It is a bring-your-own-hardware tool and it is excluded in the root manifest, so CI never sees it. The captured Elite disagrees with our blob in four ways, and the dangerous one is field ORDER: the real pad reports sticks, ONE combined 16-bit Z trigger, then BUTTONS, then the hat, in an UNNUMBERED 15-byte report; ours declares Report ID 1, two Simulation-page trigger axes, then the hat, then 15 buttons. Since we claim a genuine Microsoft VID/PID and SDL/Steam/Windows all apply stock mappings keyed on it, that ordering difference is exactly how every control silently lands on the wrong action. The driver comment now records the diff and the two blockers that stop the capture from simply being pasted in. VERIFIED * `cargo fmt --check` clean, `cargo clippy --all-targets -- -D warnings` clean (macOS). * The tool builds and runs on macOS and on .173 (Windows 11 26200, cargo 1.96, MSVC, no WDK). * TOOL VALIDATED AGAINST A KNOWN-GOOD CONTROL: pointed at the live DualSense on .173, it reproduces the real `DUALSENSE_RDESC` layout exactly (input 0x01, 64 B, X,Y,Z,Rz,Rx,Ry at bytes 1..6, hat 8.0, 15 buttons 8.4, output 0x02, the full feature ladder), and `--read` returned live len=64 reports with sticks centred at 80 80 80 80 and the counter incrementing. * `cargo metadata` on the root workspace still resolves and does NOT list this crate. * The Elite capture is reproducible: `--vid 045E --pid 0B22`. NOT VERIFIED * That the capture equals the pad's NATIVE report map. Windows exposes no API for a device's literal descriptor bytes, so hidapi reconstructs from `HidD_GetPreparsedData` — faithful in structure, item order and bit offsets, not byte-exact (measured: the DualSense's real 273-byte descriptor reconstructs to 467). `xinputhid` also filters that pad, and the captured shape is the legacy DirectInput view. A byte-exact answer needs Linux hidraw. * Why the Elite returned ZERO input reports across two runs (72 s and 90 s) while the DualSense streamed fine on the same code path — untouched pad, or exclusive claim by the XInput translator. Unresolved. * Nothing here was built on Windows as a driver: `XBOX_RDESC` itself is UNCHANGED, so no behaviour changes. The only edit to the driver is its provenance comment.	2026-08-09 19:02:13 +02:00
enricobuehler	f34acf1d73	fix(drivers/pf-gamepad): the Xbox descriptor never declared the channel-proof report, so the pad served neutral forever ... `XBOX_RDESC` declared only Input report 1. The sealed pad channel delivers its DATA section over a vendor Feature report `0x85` (`ProofTransport::HidFeatureReport`), and the proof handler's own comment records the assumption that made this invisible — "0x85 is already declared as a Feature report in all three captured descriptors". True of the captured PlayStation blobs; false of this hand-constructed one. So hidclass rejected the host's `HidD_GetFeature` before the driver ever saw it, the host refused to hand over the section, and the pad answered every read with its neutral report. The HID Xbox pad had never delivered a single input report since it was written. Declaring `0x85` with a 63-byte payload (1 id + 63 = 64 = FeatureReportByteLength) fixes it. Verified on glass on .173: `gamepad driver attached to the shared section proto=3 late=false`, and WGI's RawGameController path then reads the pad live — advancing timestamps, the devtest's left-stick sweep, buttons toggling. Before the fix: 12 consecutive samples, one frozen timestamp, every axis at dead centre. This is the descriptor-provenance warning in this file coming true. It is still CONSTRUCTED rather than captured, and that remains the open risk — `xinputhid` appears to validate the descriptor and refuses ours, and a real Elite is a multi-collection device where ours has one. Codec layout tests still 11/11; fmt clean. Only device_type 4 is affected, which nothing shipping uses yet.	2026-08-09 18:16:24 +02:00
enricobuehler	bc9201d136	fix(packaging/gamescope): bump the pin past upstream's capture-format probe, and sign the RPM ... Three things, one delivery path — a Fedora/Nobara box getting the patched gamescope. **The pin moves 8c676c39 -> 5fb8dce4** (3.16.25-1 -> 3.16.25-11). The commit that matters is ff6b924, `rendervulkan: fall back to XBGR2101010 when XRGB2101010 is unsupported`: it probes `linearTilingFeatures` for STORAGE+SAMPLED and captures as XBGR2101010 where A2R10G10B10 linear storage is unavailable — which is every NVIDIA. That covers the paths that are upstream's rather than ours: the RGB intermediate `paint_pipewire()` acquires when the stream is YCbCr, and AVIF screenshots. #143 fixed our own node host-side; this is the other half, and its commit message asked for exactly this bump. All six patches rebased. Only 0006 conflicted: upstream's f8be7ee added `vulkan_has_drm_modifiers_for_features()` immediately above the `g_device` declaration our patch turns into a reference — both kept. 0003 and 0005 come out byte-identical; 0006 also picks up the `--zero-commit --no-signature` form 0001-0005 already used. **Patch 0001 now offers `xBGR_210LE` BEFORE `xRGB_210LE`**, mirroring the host-side `HDR_FORMAT_ORDER` rationale on the producer end. A consumer takes the first pod it can use, and we were handing third-party consumers (OBS and friends) the one format NVIDIA fills byte-reversed under a correct-looking label. Deliberately NOT done by calling upstream's `vulkan_get_rgb10_capture_format()`, which is what pw_pods.rs proposes: that symbol landed after 3.16.25, so it would break `packaging/nix/gamescope.nix` — which applies these patches to whatever gamescope nixpkgs pins — with an opaque C++ error instead of a patch conflict. The reorder gets the same outcome on any base. Note added there so the next reader does not "fix" it. **And the RPM was never signed.** `Sign RPMs` runs right after `Build RPM`; the gamescope RPM is built ~90 steps later, behind its own ~10-minute cache, so it missed the signing pass entirely — every punktfunk-gamescope RPM ever published went out unsigned. The repo file we tell users to install carries `gpgcheck=1`, so `dnf install punktfunk-gamescope` failed with "The package is not signed" on every Fedora and Nobara box. The package was in the channel the whole time and could not be installed from it, which is worse than absent: the notes and the docs-site both say it is there. `sign-rpms.sh` now takes explicit paths (defaulting to `dist/*.rpm` as before) and a second pass signs this one before publish, fail-closed on a tag like the first. Verified on Nobara 44 (VM 123, RTX 5070 Ti passthrough), canary 0.27.0-0.ci12611.g516a2954: * Builds clean in the fc44 CI image; banner `3.16.25-17-ga87390d+pfhdr4` (11 upstream + our 6), so the marker the host probes still reads 4 — no capability moved, hence pkgrel 3 and `.pfhdrN` staying put. * `pw-cli enum-params` on the live node: BGRx, NV12, **xBGR_210LE (81), xRGB_210LE (80)** — 8-bit consumers still negotiate bit-for-bit, 10-bit now leads with the safe one. * All four patched flags present, `--pipewire-composite-external-overlay` included. * Patch 0006 confirmed working by comparison, which is the only way to see it: the new build exits 0 where both the pre-0006 `+pfhdr2` build and the stock 3.16.23.2 abort with 134. * Signing fix proven with a throwaway key: `Signature: (none)` -> `digests signatures OK`. * Host health on the canary: synthetic spike 300/300 encoded, loopback 300 recovered, 0 mismatches. One unexplained one-off: the very first headless run after install segfaulted at exit (SIGSEGV, after "Primary child shut down!"). Not reproduced in 11 subsequent runs across every flag combination, so it is recorded rather than diagnosed — the binary is stripped and there is no symbolised core.	2026-08-09 18:00:28 +02:00
enricobuehler	003ce8bea7	Merge pull request 'Every NVIDIA gamescope HDR stream had red and blue swapped — and a sysext step added in a release was unreachable forever' (#143) from worktree-hdr-rb-swap-nvidia into main ... Reviewed-on: #143	2026-08-09 15:34:02 +00:00
enricobuehler	235b8e55d4	Merge pull request 'chore(web): console onto @unom/ui 0.9.2' (#142) from worktree-console-unom-092 into main ... Reviewed-on: #142	2026-08-09 15:32:35 +00:00
enricobuehler	d2a2bcc25d	feat(drivers/pf-xusb): answer the async input wait, and put xinputhid on the stack ... The two things this driver's README has always listed as the missing WGI/GameInput work, both user-mode, neither needing a bus driver: `IOCTL_XUSB_WAIT_FOR_INPUT` is now pended on a manual queue and completed by the periodic timer on a dwPacketNumber edge, answering with the same 29-byte GET_STATE payload the synchronous path serves. Declining it was enough for classic xinput1_4, which just falls back to sync GET_STATE polling — that is why the pad has always worked there. It is not enough for WGI/GameInput, which poll asynchronously: to them a decline is a refusal, not a fallback. Completion is edge-gated because releasing a waiter on an unchanged packet spins its caller at timer rate. WAIT_GUIDE_BUTTON stays declined — we have no state to signal on. The INF adds UpperFilters=xinputhid on the XUSB devnode. Note the earlier attempt put that filter on the HID child of the *other* backend, which was simply the wrong devnode: XInput does not read HID at all, it enumerates GUID_DEVINTERFACE_XUSB, which is what this driver registers. Verified on .173: build + sign + catalog exit 0; infverif "INF is VALID"; the devnode starts Status OK with UpperFilters=xinputhid readable back from its enum key; and XInput still sees the pad (slot 1 live alongside the box's real Elite in slot 0), so the async queue is no regression to the path that already worked. NOT yet measured: whether WGI/GameInput now admit the pad. `IG_` is the wrong probe for this driver — it is a HID-path artifact and pf-xusb is System-class with no HID child, so its absence says nothing either way. That needs a real WinRT/GameInput enumeration test.	2026-08-09 17:29:10 +02:00
enricobuehler	0b252403cd	fix(web): fix the card inset at the root, not at the call sites ... The broken inset on the Displays configuration card was the symptom. The cause is structural, and it had already been diagnosed at least twice in-tree without being fixed. Two faults, both in components/ui/card.tsx: 1. The padding was a RESPONSIVE COMPOUND: `p-4 pt-0 sm:p-6 sm:pt-0`. tailwind-merge resolves conflicts only within a variant, so any call-site override won at the base and lost at `sm:` — correct on a phone, wrong on every desktop. Measured on the Displays card before this change: padding-top 24px at 500px, 0px at 1440px. 2. `pt-0` encoded an assumption about a SIBLING that nothing enforced — "a CardHeader is above me and supplies the top inset". Delete the header, which is exactly what tabbing a page does since the tab label replaces the card title, and the top inset silently vanishes at ≥640px. Fix: - One single-variant utility, `p-padding-card` — the same `--spacing-padding-card` token @unom/ui's own Card uses, so nested cards finally agree on their inset. A single variant cannot half-lose an override. - Top inset is now self-correcting: `[&:not(:first-child)]:pt-0`. Ask the DOM instead of the author. A headerless CardContent keeps its inset with nothing to remember. Seven call sites had grown their own compensation in five dialects — `p-6`, `p-card pt-card sm:pt-card` (×3), `p-4 sm:pt-6` (×3), `pt-4 sm:pt-6`, and my own `pt-6` from the tabs commit. All removed; they are the symptom-fixes this replaces. LogsCard even carried a six-line comment correctly describing the trap and working around it locally — that comment is now three lines saying it no longer needs saying. `flush` stays: full-bleed content is a real intent, expressed as a prop the component honours rather than a utility that has to out-argue the one already there. Guarded by UI/Card → "Inset with and without header", a headered/headerless pair that has to look identical on every side. It must be checked at BOTH widths — a single width cannot show this class of bug, which is why it kept surviving. Verified by measuring computed padding at 500px and 1440px: first child 20px on all four sides, after-a-header 0px top and 20px elsewhere, identical at both widths. tsc clean, biome clean on every touched file, 9/9 server tests, build + i18n clean, 32/32 screenshots.	2026-08-09 17:23:09 +02:00
enricobuehler	0ab17ee81d	fix(packaging): a post_merge step added in a release was unreachable forever ... A sysext upgrade is driven by the script from the OLD image -- /usr/bin/punktfunk-sysext is replaced by the very `systemd-sysext refresh` that runs mid-upgrade -- so a post_merge step ADDED in the new release is executed by nobody. The old script does not have it, and the new script never gets a turn: from then on `update` matches the "already on $cur" branch and returns before post_merge. The step is permanently unreachable on exactly the installs that need it, and nothing says so. Field-proven on the Bazzite host that took 0.25.0 -> 0.26.0 (2026-08-09). The casualty was the `punktfunk` group, which post_merge learned to create in 0.26.0 (62a6fa9f): 0.25.0's script ran the upgrade, so the group was never created, and every `punktfunk-sysext update` since has said "nothing to do". `pf-dm-helper` gates on membership in that group, so it refused every caller -- pkexec authorised it and the helper then declined itself -- and every managed gamescope takeover fell back to "stopping the display manager needs privilege", leaving sddm's autologin Relogin loop churning logind sessions for the whole stream. Re-run post_merge when already current. Everything in it is idempotent (guarded getent/groupadd, `install` of /etc mirrors, udevadm reload/trigger, sysctl, modprobe), so convergence is the honest behaviour and "nothing to do" was a lie about host state. Add an explicit `reapply` verb too, so the steps a sysext image cannot carry can be re-applied without reinstalling the image. Also print the membership hint. Creating the group is necessary but NOT sufficient and the difference is invisible until a stream fails: joining stays opt-in by design (writing vhci `attach` materialises an arbitrary emulated USB device), so post_merge now names the exact usermod when SUDO_USER is not a member. Matched with `grep -qx` so `punktfunk-update` does not read as `punktfunk`. bash -n clean; shellcheck clean apart from the pre-existing SC1091 on `. /etc/os-release`, which fires on the unmodified file too.	2026-08-09 17:08:24 +02:00
enricobuehler	4e04c2bbf8	feat(host/pads): route the Xbox pad to the HID backend behind PUNKTFUNK_XBOX_BACKEND=hid ... Wires `xbox_windows` into the per-pad router so an Xbox-family pad can be built as a real HID device instead of the XUSB companion, and adds the knob that selects between them. Opt-in rather than the new default, deliberately. XUSB is what classic-XInput games read today; the HID pad buys the Steam / WGI / GameInput / DirectInput visibility XUSB can never have, but whether Windows promotes it into an Xbox-profile device that XInput and WGI Gamepad accept is still the open question. Flipping the default before that is settled would trade a known-working path for an unproven one. The two backends are mutually exclusive per pad by construction — one match arm or the other — because presenting both hands a game two controllers for one pair of hands. Verified on .173: cargo check -p punktfunk-host exit 0, clippy -D warnings clean, `cargo test -p punktfunk-host gamepad` 8/8 green, fmt clean.	2026-08-09 17:03:25 +02:00
enricobuehler	31aef4b09f	feat(web): tab the Virtual displays page ... Same pill strip the plugin UIs use, via @unom/ui's Tabs: Configuration | Live displays. The page was two stacked cards, and the configuration card ALONE is taller than the viewport — the existing comment on the unsaved badge says as much, because that height is how pending edits went unnoticed. The live-display list sat below all of it, so in practice it was off screen. Two details that are not cosmetic: - The dirty marker moved from the card header onto the Configuration TRIGGER. Behind a tab the old badge would vanish entirely while Live was open — a strictly worse version of the problem it was added to solve. On the trigger it survives both tabs, and the Custom block keeps its own inline badge for when the tab IS open. - The strip is extracted as a presentational `DisplayTabs` rather than inlined in `DisplaySection`. The container calls `useBlocker`, which needs a router, so it cannot render in Storybook — and this page's story exists specifically to pin the MOTION NESTING of the preset grid (a card sets no delayChildren, so tiles nested one level deeper stop staggering). Inserting tabs changes that ancestor chain, so the story has to render the real one or it passes for the wrong reason. Adds Pages/Displays → "Unsaved on other tab", which switches to Live with a dirty draft: if the marker ever goes silent there, the warning is gone exactly when it matters. Verified: tsc clean, biome clean, `bun test server/` 9/9, vite build + i18n check clean, Storybook builds, 32/32 screenshots.	2026-08-09 16:58:46 +02:00
enricobuehler	97928516a0	fix(pf-capture): every NVIDIA HDR stream had red and blue swapped ... gamescope's capture textures are mappable, hence linear-tiled, and NVIDIA does not implement linear-tiled STORAGE for A2R10G10B10_UNORM_PACK32. Upstream says it plainly in rendervulkan.cpp: "imageStore lands in XBGR order there, swapping R/B". So the composite writes XBGR bytes into a buffer still LABELLED XRGB2101010, and our patch's spa_format_to_drm() derives that label from the negotiated SPA format alone, never asking the hardware what it can actually write. The host then believed the label, correctly at every step: xRGB_210LE -> PixelFormat::X2Rgb10 -> NV_ENC_BUFFER_FORMAT_ARGB10. DRM XRGB2101010 really is "B in the low 10 bits" and NVENC ARGB10 really is "B in the lowest 10 bits"; the Windows twin (R10G10B10A2 -> ABGR10) is correct by the same rule. Every mapping audits clean because the label was right and only the CONTENT was wrong -- which is why this survived a full trace of both ends. Fix the preference host-side: offer xBGR_210LE FIRST. The first compatible consumer pod wins, so that is what a gamescope session lands on, and an XBGR2101010 texture is one NVIDIA writes in its own order -- label and content agree. It costs nothing elsewhere: A2B10G10R10_UNORM_PACK32 is the universally supported packed-10 format, it is what upstream's own fallback picks, and X2Bgr10 has a first-class encoder path (NVENC ABGR10, VAAPI X2BGR10LE). xRGB_210LE stays as the second pod so a producer offering only it can still negotiate HDR instead of dropping to the SDR downgrade. Doing it here rather than in the patch set is deliberate: the real fix is for spa_format_to_drm() to offer only what vulkan_get_rgb10_capture_format() reports, but that function landed after 3.16.25 and the pin is 3.16.25-7-g60561e2+pfhdr4 (0 "2101010" strings in the shipped binary), so the deployed gamescope cannot self-correct. This ships in the host binary with no gamescope rebuild. Field-confirmed on the RTX 5070 Ti Bazzite host with 0.26.0, and confirmed host-side rather than client-side by reproducing the identical swap from two unrelated clients (16" MacBook Pro and Mac Studio). SDR was never affected -- it takes no packed-10 path. Gate (pf-lxcheck2, linux/amd64): fmt clean, clippy --all-targets -D warnings clean, cargo test -p pf-capture 60 passed / 0 failed incl. the new hdr_offers_xbgr_before_xrgb order pin.	2026-08-09 16:58:15 +02:00
enricobuehler	d498ff4a60	test(drivers): give the Xbox identity a root-enumerated id, and verify the whole thing on Windows ... `root\pf_xboxwireless` alongside the plain id, mirroring the DualSense model line — the INF already documents that variant as the one devgen/devcon tests bind, and without it the Xbox identity could only be exercised through a running host. Verified end to end on .173 (Windows 11 26200, WDK 10.0.26100.0): - build-gamepad-drivers.ps1 builds + signs + catalogs the driver, exit 0 - infverif /v /w on the generated pf_gamepad.inf: "INF is VALID" - pnputil stages the package; devgen creates the devnode; it starts clean: Status OK, Class HIDClass, "Punktfunk Virtual Xbox Wireless Controller" - it enumerates a HID child, Status OK, carrying HID_DEVICE_SYSTEM_GAME and HID_DEVICE_UP:0001_U:0005 — Windows parsed the constructed report descriptor and classified the pad as a Game Pad (usage page 0x01, usage 0x05), which is precisely what pf-xusb could never do Test devnode, phantom child, driver package and both certs were removed afterwards. Two build gotchas worth knowing, both already handled inside build-gamepad-drivers.ps1 and both of which cost a cycle here: CARGO_TARGET_DIR pointing outside the workspace breaks wdk-sys (wdk-build walks up from OUT_DIR looking for a Cargo.lock and finds none), and the WDK version must be pinned via Version_Number=10.0.26100.0 or bindgen picks SDK 10.0.28000.0, which ships no km/crt headers. Still open: the SwDeviceCreate USB identity (HID\VID_045E&PID_0B13) cannot be checked through a devgen node, which has no USB hardware ids — that needs the host path. So the WGI-promotion question is still unanswered, and host routing is still unwritten.	2026-08-09 16:54:00 +02:00
enricobuehler	bbc0513f0c	fix(validation): the kit could not read a real log — tracing wraps field names in ANSI ... Found by running it. The first V3a run on .25 encoded 2700 frames in BOTH arms, at 59.6 fps, with 22 perf windows each — and the kit reported "fewer than 3 usable perf windows", because `tracing`'s fmt layer wraps field NAMES in SGR escapes. The bytes on disk are `p99_us\e[0m\e[2m=\e[0m4601`, so `s/.*p99_us=\([0-9][0-9]*\).*/\1/p` never matched. The message text is plain, which is why the window COUNT was right and only the numbers vanished — and why the fixtures never caught it: they were hand-written, and cleaner than reality. Anything matching a field breaks the same way, so this was not only V3a: v2's `priority=Realtime`, the demotion `reason=`, and v4's rungs all read fields. Every log read now goes through one `log_cat` that strips SGR, and the spike is launched with NO_COLOR=1 so fresh logs are plain at the source too — a human grepping a red leg by hand is defeated by those escapes exactly as the parser was. The self-test gains the same four perf windows a second time, ANSI-wrapped, asserting an identical result: same numbers, same expectation, so a failure there can only mean the stripping broke. That fixture caught its own first draft, which built the line in one printf with 27 placeholders against 23 arguments and emitted empty escapes — hence the field-at-a-time helper. With this, V3a self-reports on .25 (sway headless, real dmabuf capture, AMD 780M/RADV, 2700 frames per arm, both arms at default GPU priority): in-process p50 2.08 ms p99 4.18 ms (21 windows) uncapped worker p50 2.07 ms p99 3.52 ms (21 windows) p99 delta -0.66 ms -> PASS R1's pre-registered abandonment gate does not fire: the process boundary is not merely under the +1.0 ms ceiling, it is measurably FASTER at the tail, while p50 is unchanged (2.08 vs 2.07). An earlier hand-extraction of the same logs gave -0.43 ms, so the direction reproduces across runs. Caveat for whoever reads this later: idle iGPU in a KVM guest, RADV, no GPU-bound load. This bounds the IPC hop; it says nothing about V3b, which still needs .21 under GRID 2.	2026-08-09 16:33:29 +02:00
enricobuehler	d13d253c2f	chore(web): @unom/ui 0.8.16 → 0.9.2 ... Brings the console onto the current design system. 0.9.x adds the Badge, Spinner, Skeleton, Switch, Table, EmptyState and CodeBlock primitives, and 0.9.2 carries the form fixes found while overhauling the rom-manager plugin UI: - Select's border and focus ring resolved to `--main`, which is the FOREGROUND here (`--main: var(--foreground)` in web/src/styles.css), so the trigger wore a near-white border and a 3px near-white focus ring. Its chevron and placeholder were painted `--secondary`, a SURFACE colour, and all but vanished. Now on `--input`/`--ring`, the same tokens InputText already used. - InputNumber declares a color-scheme, so the browser-drawn spinner arrows stop being near-black on a near-black field. Both defects were live in this console too — the console palette is what exposes them. Verified: codegen + vite build clean, `tsc --noEmit` clean, `bun test server/` 9/9, Storybook builds, 31/31 screenshots. A probe over all 61 stories reports ZERO page errors, and the two stories containing a Select now render it at h-input-height with `border: rgb(42, 33, 72)` (the input token) and a muted-foreground chevron. Note: the console's components/ui/ wrapper layer is unchanged and still required — @unom/ui's DialogContent remains a surface with no Portal or placement, which is exactly what web/src/components/ui/dialog.tsx supplies.	2026-08-09 16:27:08 +02:00
enricobuehler	2de604ecab	test(validation): the on-glass kit for the encode worker, including the 0.26.0-1 regression test ... WP3 of design/gpu-priority-capability-worker-implementation-plan.md. Five legs, the first of which is the test that would have caught the field incident: in a KDE session with the worker installed and capped, `getcap` on the host must be EMPTY, its CapPrm all zeroes, `readlink /proc/<pid>/exe` must resolve, and `punktfunk-host probe-compositor` must exit 0 — which on KWin succeeds only when the privileged zkde_screencast_unstable_v1 global was actually advertised to this client. Read-only by default; the one mutating rung (kill -9) is behind --allow-mutate and kills only a worker that is a child of the spike the script itself started. It NEVER calls setcap: the uncapped arms use a plain copy of the worker, which does not carry security.capability, verified uncapped before use. So no leg needs root and none restores state. A skip is never a pass — exit 2 means incomplete, distinct from 1 (failure). V3 is split, which the plan did not do. Its stated form compares against PW1's in-process-capped baselines, and those exist only on .21 under GRID 2: * V3a is the pre-registered abandonment gate and needs no capability at all — in-process versus an UNCAPPED worker, both at default priority, so the only difference is the process boundary. Fails if the worker's p99 exceeds inline by more than --gate-ms (1.0). This runs on any box with a GPU. * V3b is the lever itself, capped worker versus the refused in-process arm, and says plainly that an idle GPU makes it meaningless. The false PASS this kit exists to refuse: a CPU-backed frame makes the proxy pin itself in-process for the session, so a synthetic source would quietly turn the "worker" arm into a second in-process arm and pass the gate for the wrong reason. The worker arm is only accepted with a dmabuf-passthrough capture, a capability-carrying-worker line, and no fallback line anywhere in the log. Also asserts the host and worker are different inodes — a hardlink shares the file capability, which is the same incident by another route.	2026-08-09 13:07:31 +02:00
enricobuehler	f26d21125d	docs: the capability moves to the encode worker, and the host must never be given one ... Rewrites the "GPU scheduling priority" section around the split: punktfunk-encode-worker carries cap_sys_nice=ep, punktfunk-host carries nothing on any channel, ever. The KWin identification mechanism is spelled out in plain words and the failure line is quoted verbatim ("KWin does not expose zkde_screencast_unstable_v1 to this client") so someone searching for their symptom lands on the explanation. The warning names all three ways an operator would reach for the capability — hand setcap, a systemd AmbientCapabilities= line, a NixOS security.wrappers entry — because all three put it in the same permitted set and all three cost KDE desktop streaming. That is the failure mode that made this worth documenting: it looks exactly like a missing .desktop and survives reinstalling both ends. configuration.md gains PUNKTFUNK_ENCODE_WORKER (path, or `off` to force the in-process encoder) and re-describes PYROWAVE_QUEUE_PRIORITY as an intent forwarded to whichever process does the encode. kde.md gains one line on the troubleshooting bullet someone actually lands on: getcap on the host must print nothing. The published 0.26.0 notes are deliberately untouched — they are the record of what shipped. The flipped phrasing lives in v0.27.0's notes instead; v0.26.0.md:37 ("a system privilege that turns out to stop KDE recognising the host at all") is the line that goes stale when this ships.	2026-08-09 12:51:01 +02:00
enricobuehler	4f8cce6751	feat(packaging): grant CAP_SYS_NICE to the encode worker on all six channels, and assert the host never gets it ... 767e67ca's per-channel mechanics were correct; they were aimed at the wrong binary. Each one is restored here pointed at punktfunk-encode-worker, and every host-side removal from #136 stays verbatim. All grants remain best-effort — an uncapped worker still encodes, at default priority, so a failed setcap must never fail an install. * Arch: setcap in post_install AND post_upgrade (a replaced binary is a new inode). * RPM: %caps(cap_sys_nice=ep) in %files, never a %post setcap — %caps applies, restores and verifies, and covers Fedora as well as Bazzite via rpm-ostree layering. * Bazzite + Arch sysext: setcap on the staging tree before mksquashfs, which does record security.capability. The assertion is amended, not removed: host EMPTY is still a hard fail, and the worker must carry exactly cap_sys_nice=ep — missing is fine, anything else is not. * deb: setcap in postinst. * NixOS: security.wrappers for the WORKER plus PUNKTFUNK_ENCODE_WORKER in the unit. A file capability cannot live on a store path, and an ambient grant is right here precisely because nothing ever identifies the worker. The host's ExecStart stays on the store path. * Steam Deck: setcap the worker; the .desktop the script writes stays valid this time. Four things the plan's channel table missed: * packaging/arch/build-sysext.sh had no capability handling at all, and a sysext can never run a pacman scriptlet — the SteamOS image would have shipped the lever permanently inert. * scripts/steamdeck/update.sh had none either. It rebuilds both binaries, so a new inode drops the grant, and it is the documented steady-state path: the lever would have died on the first update. It also never healed a Deck already capped by 0.26.0-1. * A capped worker is AT_SECURE, and glibc drops $ORIGIN-expanded RPATH entries for secure binaries unless they normalise into a trusted system dir. Copying the host's rpath under BUNDLE_FFMPEG=1 would have left the capped worker unable to find libavcodec on exactly the channel that bundles it. Absolute DT_RPATH instead. * Nix crane scopes by -p, so the worker would not have been built at all, and it needs its own addDriverRunpath. scripts/ci/assert-cap-matrix.sh mechanizes the lesson from 0.26.0-1 — verify the PACKAGE, never the board. It unpacks the built Arch package, the deb, the rpm and the mounted sysext raw and asserts one matrix: the host carries NOTHING (hard fail), the worker exactly cap_sys_nice=ep. The sysext reader first proves it can round-trip a capability through mksquashfs/unsquashfs at all, so an unreadable artifact fails rather than issuing a blind PASS, and --self-test red-teams the assertions themselves. Red-teaming the leg found a real bug: setcap originally ran BEFORE the assertion, so "the worker arrived carrying something unexpected" was unreachable and a stray %caps would have been silently overwritten. Both sysext scripts now assert, then grant, then assert again.	2026-08-09 12:50:47 +02:00