4 Commits

Author	SHA1	Message	Date
enricobuehler	134874b3c8	fix(client/windows): repair the v0.15.0 MSIX build — ARM64 feature leak + illegal XML comment ... Both MSIX matrix jobs failed at the v0.15.0 tag, for two unrelated reasons, both introduced by this release. 0.13.0 and 0.14.0 shipped both packages; 0.15.0 shipped neither. ARM64 failed to BUILD. The PyroWave Windows un-gating (1ef0229b) moved `pyrowave-sys` in pf-client-core out of `cfg(target_os = "linux")` into a general optional dependency that pf-client-core's own `default = ["pyrowave"]` turns on. The ARM64 leg builds `--no-default-features` precisely to skip it, but that only disables defaults for the two packages named with `-p` — every internal edge kept inheriting them: clients/windows -> pf-client-core, clients/session -> pf-client-core, clients/session -> pf-presenter, and pf-presenter's own `default = ["pyrowave"]` -> pf-client-core. So the vendored Granite C++ compiled on ARM64 and stopped where it always does: muglm.cpp reaching for _MM_TRANSPOSE4_PS/_mm_storeu_ps, then `simd.hpp:103 #error "Implement me."`. Those three internal edges now pass `default-features = false`; the feature is enabled only through an explicit chain (clients/session's `pyrowave` -> pf-client-core/pyrowave + pf-presenter/pyrowave, and pf-presenter's `pyrowave` -> pf-client-core/pyrowave), so `--no-default-features` finally means what it says. Verified by feature resolution rather than assertion — `cargo tree -i pyrowave-sys`: aarch64-pc-windows-msvc, --no-default-features -> not in the graph (was: present) x86_64-pc-windows-msvc, default features -> present x86_64-unknown-linux-gnu, default features -> present PyroWave is NOT dropped from the Windows client. Decode has always run in the spawned punktfunk-session binary, whose own default keeps the feature on, and unification turns it back on for the shared pf-client-core wherever that binary is in the build (x64, Linux). The shell only ever offered "pyrowave" as a codec preference string — it holds no decoder and never called one, so linking the C++ into it was dead weight even on x64. x64 built fine and failed at PACKAGING: `makepri new` rejected the manifest with PRI191 "Appx manifest not found or is invalid" / malformed comment syntax. The console tile added in 2508b720 documented its flag inside an XML comment, and XML forbids `--` anywhere in a comment body, so the literal flag spelling made the whole manifest unparseable. Reworded, with a note to keep the next person from reintroducing it. Confirmed by parsing both revisions after template substitution: the tagged manifest fails at line 63 col 9, this one parses. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 23:20:29 +02:00
enricobuehler	2508b72062	feat(client/windows): make the console UI findable, and launchable on its own ... Two problems, one feature. The gamepad/couch UI existed but you had to already know it was there: - On the hosts page its card only rendered when a controller was CONNECTED, so with no pad plugged in there was no visible entry point at all -- the only other door being a per-host overflow menu behind a "..." nobody opens. The card now always shows, with copy that adapts to whether a pad is present, so the feature is findable before you own the hardware. - There was no way to start it directly. An HTPC or TV box wants the couch interface as its first screen, not the desktop shell. "punktfunk-client --console" now hands straight off to it (fullscreen unless --windowed), which covers shortcuts, Steam entries, autostart and Task Scheduler. The Start-menu tile needs its own executable: an MSIX <Application> cannot pass arguments to a full-trust exe, so "punktfunk-client.exe --console" is not expressible there. punktfunk-console.exe is a ~20-line hand-off to the session binary's browse mode, staged into the package and given its own tile ("Punktfunk Console"). Nothing new is implemented behind either door: a bare "--browse" was already a complete standalone client (host list, discovery, PIN pairing, settings, Wake-on-LAN, library). It just had no front door. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 19:06:06 +02:00
enricobuehler	67d58bfde3	feat(windows-client): cross-compile + ship ARM64 (aarch64) off the x64 runner ... windows.yml + windows-msix.yml gain an x86_64/aarch64 target matrix. ARM64 is cross-compiled on the one x64 Windows runner — the x64 MSVC toolset ships the ARM64 cross compiler, aarch64-pc-windows-msvc is tier-2 with host tools, and SDL3/libopus (build-from-source) cross-compile cleanly. The only arch-specific external dep is FFmpeg's import libs: the matrix points FFMPEG_DIR at a per-arch tree (x64 C:\Users\Public\ffmpeg, arm64 C:\Users\Public\ffmpeg-arm64, both FFmpeg 7.x / avcodec-61). Per-arch short CARGO_TARGET_DIR avoids a shared target dir; fmt + test run only for x64 (aarch64 can't execute on the x64 host). pack-msix.ps1 gains -Arch x64|arm64 (stamps the manifest ProcessorArchitecture, arch-suffixes the .msix/.cer); windows-msix.yml matrixes both arches and publishes ..._x64.msix / ..._arm64.msix. setup-windows-runner.ps1 provisions the rustup target + the ARM64 FFmpeg tree (idempotent). Verified live on the runner (home-windows-1): debug+release cross-build green, clippy -D warnings green, and MSIX pack produces a valid arm64 package (manifest arch=arm64; bundled exe/SDL3/avcodec/reactor-bootstrap all PE machine 0xAA64). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-19 11:44:24 +00:00
enricobuehler	2f2147b093	refactor: drop milestone names + consolidate clients; loss-recovery & rumble fixes ... Two bodies of work in one commit (the rename moved files the fixes also touched). Naming/structure cleanup (pre-launch): - Host modules m3.rs->punktfunk1.rs, m0.rs->spike.rs; CLI m3-host->punktfunk1-host, m0->spike; bare `punktfunk-host` now prints help. Types M3Options/M3Source-> Punktfunk1Options/Punktfunk1Source. - Clients consolidated out of crates/ into clients/: punktfunk-client-rs-> clients/probe (crate punktfunk-probe), client-linux->clients/linux, client-windows->clients/windows, punktfunk-android->clients/android/native (crate punktfunk-client-android; kept [lib] name=punktfunk_android so the JNI contract is unchanged). crates/ now holds only core + host. - Milestone codes M0-M4 purged from code/CLI/CLAUDE.md/README/docs/docs-site, kept only in docs/implementation-plan.md. docs/m2-plan.md-> docs/gamestream-host-plan.md. CI/gradle/flatpak paths updated. Client loss-recovery (video froze and never recovered after a brief drop): - Export punktfunk_connection_frames_dropped through the C ABI (the core already tracked it for the client keyframe-recovery loop; it was never reachable from the ABI clients). Regenerated punktfunk_core.h. - Apple (StreamPump + Stage2Pipeline) and Android (decode.rs) now poll frames_dropped and request a keyframe when it climbs -- the same loss-driven recovery Linux/Windows already had. Under infinite GOP the decoder silently conceals reference-missing frames, so the decode-error trigger rarely fires. Apple rumble robustness (worked then went spotty -- DualSense + Xbox): - Add CHHapticEngine stopped/reset handlers (rebuild on app background / audio interruption / server reset) and drop the permanent `broken` latch on a transient drive failure; latch only when the controller truly has no haptics. - Surface swallowed SDL set_rumble errors on Linux/Windows + diagnostic logging. Verified: cargo build/clippy/fmt --workspace, C-ABI harness, header drift. Not runnable on this box (verify in CI): Gitea workflows, gradle/Android, flatpak, Swift/decky. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-18 21:05:58 +00:00