19 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	bed58b75b6	feat(apple): the statistics overlay is reachable on tvOS ... An Apple TV session had no way to the stats overlay at all. Every other client cycles it in-stream — Ctrl+Alt+Shift+S on the desktops, a three-finger tap on touch — and tvOS has neither a keyboard nor a screen to tap, so the only route was Settings before connecting (or a profile). The docs' own "cycle with" table simply had no row for it. Two surfaces, because an Apple TV may have a controller in the room or only the remote: - Select + X on a controller, cycling one tier per completion. Built like Android's mic chord (Select + Y) and deliberately disjoint from the escape chord — X is none of its four buttons, so reaching for one can never trip the other. Read off the wire mask like the escape chord, so a Select the hold-Select gesture has turned into a guide can't cycle the overlay on its way past. Available on every Apple platform: a controller in both hands is exactly the case the keyboard combo and the three-finger tap can't serve. - Hold Play/Pause on the Siri Remote. Its right-click is therefore deferred until the press resolves — a tap still right-clicks, delivered on release with the release trailing by TAP_PRESS — because a right button held for half a second is a context menu on every desktop this streams. A non-forwarding slot now claims the stats chord's elements too, alongside the escape chord's: on tvOS an unclaimed button's press stays the system's and the chord would silently never complete. Tests pin both chords' masks against their GameController alias lists, that the two overlap only on Select, and that the claim list covers both without duplicates — the failure mode is nothing happening, with nothing logged.	2026-08-08 23:24:09 +02:00
enricobuehler	5a4305c072	merge: bring current main into the gyro correctness branch ... main moved ~60 commits while this branch was in progress, and one of them matters here: PR #88 (the phone-gyro mirror) landed, touching the same motion path. One conflicted file, `GamepadCapture.swift`, in three places — all of them the two changes meeting rather than disagreeing: - **Slot fields.** #88 added `motionSent` + `lastAccel` for its flush-parks-motion fix; this branch removed `lastMotionNs` with the 4 ms drop-throttle. Kept both decisions: the parking state stays, the throttle field goes. - **forwardMotion's head.** #88 added the mirror stand-down (`pad 0` yields while the phone speaks for it); this branch deleted the throttle guard. Kept the stand-down, dropped the guard. - **The send.** This branch converts into the DualSense report frame; #88 records what went out so `flush` can replay it beside a zero gyro. Both, with the recording placed AFTER the conversion — `flush` replays `lastAccel`, so it has to be the vector that actually went on the wire, or a still pad's gravity gets parked in the wrong axis. The two features compose exactly, which is worth stating because it is not luck: this branch gates motion capture on `hasRotationRate`, and #88 engages the phone mirror when `hasRotationRate != true`. They are complements — a pad either drives its own gyro or the phone mirrors for it, never both and never neither. Everything else auto-merged. Note `DeviceGyroRemapTests` is `#if os(iOS)`, so the macOS suite reports the same 215 as before the merge rather than gaining #88's six — checked, not assumed. Gates re-run against the merged tree rather than trusting either side's: Linux fmt + build + `clippy --locked --all-targets -D warnings` + punktfunk-core and pf-inject suites; Apple 215 tests and the iOS-triple typecheck; Android kit + app compile and tests. All green.	2026-08-07 19:34:22 +02:00
enricobuehler	0170da2a5f	fix(client/apple): stop dropping rotation, and stop inventing it ... G13 — the three capture-fidelity findings from the gyro sweep, two fixed and one argued. **The 4 ms floor was a DROP, and it was shedding real rotation.** A sample arriving 3.9 ms after the last one was discarded outright. That is the wrong shape for this signal: buttons and sticks are absolute state, so a dropped frame costs nothing — the next one says everything it would have. Angular velocity is a RATE, and a consumer integrates it into an angle, so a dropped sample is rotation that happened and can never be recovered. GameController's delivery jitters around the pad's own ~250 Hz, so a floor set AT that rate does not shed a rare extra sample; it sheds a steady fraction of every turn. And the error is one-signed, so it accumulates — aim drifting short, which reads as bad sensitivity rather than as a bug. Nothing needed the ceiling. GC delivers at the sensor's rate rather than faster, the SDL client has always forwarded every sample, and the host's idle watchdog is a 100 ms timeout this cannot outpace. The throttle's two fields went with it: `lastMotionNs` was left set-but-never-read once the guard was gone, and `motionIntervalNs` had no other consumer. (Notes elsewhere say `flush` parks motion and reads it — that is PR #88's branch, not this one. Checked rather than assumed.) **An X-Box pad was streaming gyro it does not have.** Capture attached to any `GCMotion`, and an X-Box controller exposes one that reports gravity and NOTHING else. So the client sent a permanently-zero `rotationRate` to the host as authoritative gyro, under a declaration saying this pad has one. That is worse than having no motion plane at all: a game sees a controller being held perfectly still forever, and there is nothing to fall back to and nothing to notice. Now gated on `hasRotationRate`, which is GameController's own answer to the question we actually mean. The settings badge had the same bug from the same cause — `hasMotion` was `motion != nil`, so an X-Box pad got a gyroscope icon. It now reads `hasRotationRate` too. One wrong predicate was driving both the UI promise and the wire behaviour, which is why they were wrong together. That also simplifies G8's "your gyro can't reach this session" notice, which had to test `hasRotationRate` itself to avoid nagging about a gyro the pad never had. With the attach gated on it, the notice is just the else-branch. **Motion stays on the main queue, and this is the argument for why.** GameController's `handlerQueue` is a property of the CONTROLLER, not of an element, so moving motion off main moves buttons, sticks, the touchpad and the escape chord with it. This class is `@MainActor` throughout — eight `assumeIsolated` sites, the slot table, the gesture timers — so that is a rewrite of the isolation model rather than a queue assignment, and it would put the tvOS escape chord (the only controller way out of a stream there) on a background queue. That is a real risk for a speculative gain. The comment says so at the call site, and names the measurement to make first if it ever does bite: the host's per-pad motion inter-arrival histogram already reports exactly this and would say whether the delay is client-side or on the wire. Gate: macOS `swift build` + the full suite (215 tests, 5 skipped, 0 failures) and the iOS-triple typecheck green. No test pins the throttle removal or the capability gate: both are properties of live `GCMotion` delivery, which this module cannot fake — there is no injectable seam, and inventing one to assert "we called sendMotion twice" would test the mock. They are argued at the call sites instead, in the same spirit as the parts of `DsCapture` that are not unit-testable in their module either. On-glass verification is owed with the two already outstanding on that rig.	2026-08-07 19:12:02 +02:00
enricobuehler	efb7f99129	fix(client/apple): motion arrived in the wrong frame — measured against a real pad ... G16 step 1, and the second half of what 9e9bb9f4 started. That commit fixed the SIGN of acceleration (Apple reports the gravity vector, pointing down; a pad reports proper acceleration, pointing up). This fixes the FRAME, which is a separate defect and was never going to show up as an inverted axis — it shows up as roll where the game reads yaw. The wire is a unit passthrough. `dualsense_proto::write_report` puts gyro[0..3] and accel[0..3] straight into the virtual pad's report bytes 16.. and 22.., in order, with no permutation — the same slots a real DualSense fills. So the frame the wire is DEFINED in is the pad's own report frame, and forwarding GameController's x/y/z unconverted was speaking a different language with the same vocabulary. Both frames measured 2026-08-07 from ONE physical DualSense on one desk, read twice — over raw HID and through GameController — so this is two readings of the same controller in the same orientations rather than two documents: DualSense report frame: (Right, Up, Backward) axis 0 pitch, 1 yaw, 2 roll GameController frame: (Right, Forward, Up) Right is already slot 0; Up is GC's z and moves to slot 1; slot 2 wants Backward, which is GC's y negated. Hence (x, z, -y), applied to gyro AND acceleration because it is a change of basis and both live in that basis. Notable: the wire's documented naming was right all along — gyro[0]=pitch, [1]=yaw, [2]=roll is exactly what the hardware does. And Android needs no remap at all: it forwards the pad's own axis order un-remapped, which is correct. Its old reading was purely the scale bug f6de620f fixed. Only Apple was converting nothing. How the hardware frame was established, since a wrong frame here is invisible. Gravity at rest put +0.997 g on axis 1. Yaw clockwise-from-above drove axis 1 negative (98% of the rotation), pitch nose-down drove axis 0 negative (100%), roll right-side-down drove axis 2 negative (95%) — plain right-hand rule, and (a0 x a1 = a2) confirms the triad is right-handed. The accelerometer then corroborated the gyro's assignment independently: under pitch-down axis 2 rose 0.160 -> +0.339 (nose down raises the back, so world-up gains a Backward component) and under roll-right-down axis 0 went +0.021 -> -0.197, while yaw left acceleration untouched. Two different physical quantities agreeing on one triad. Apple's frame took four attempts, and the failures are worth recording because each was a different way to be confidently wrong: - peak |w| over a window containing BOTH the tip-down and the return stroke can record the return, with the opposite sign. Yaw (a continuous one-way spin) was unaffected; pitch and roll were exactly the two that disagreed with everything else. - reading `gravity + userAcceleration` when `hasGravityAndUserAcceleration` is FALSE yields a constant (0,0,1) in every orientation. It looks like data. The tell is that it never moves. The client's own else-branch on `m.acceleration` is the correct read and is what the instrument now mirrors. - `da/dt = -w x a` holds only for gravity, so testing it during vigorous waving — when `m.acceleration` carries inseparable linear acceleration — fits nothing. The frame that survived all of that: static poses, three of them, three repetitions each. Nose-down moved axis 1 by -0.635 (so axis 1 is Forward), right-side-down moved axis 0 by -0.686 (so axis 0 is Right), flat put +0.99 on axis 2 (Up). That conclusion holds whether or not the acceleration negation is right, because negating flips the measured vector and the physical direction it represents together. Confidence, stated honestly. The accelerometer half is solid: nine pose measurements, and mapping the flat pose through gives (+0.005, +0.992, +0.192) against the hardware's own (+0.021, +0.997, +0.160) — all three components, including the small tilt term that is what distinguishes this mapping from the five other permutations that also put gravity on slot 1. That the gyro shares the frame unmodified rests on a weaker measurement: a gravity-dominated consistency test that preferred (+x,+y,+z) by 1.22x, which is a margin, not a landslide. It is corroborated by the yaw reading (the one rotation measured without the return-stroke ambiguity) agreeing with right-hand rule in that frame, and by the peak-vs-return mechanism explaining the two that did not. A device-side confirmation is still owed and is listed below. The tests carry the measurements, not just the conclusion. Resting gravity is asserted against BOTH readings of that pose; each rotation is asserted to reach the slot the wire reads it from; and two properties guard the shape rather than the numbers — that the conversion is an isometry (a basis change may not stretch anything) and that it preserves handedness. That last one matters most: a permutation with the wrong number of sign flips is a REFLECTION, which looks plausible axis by axis and inverts every rotation. Mutation-checked: dropping only the negation fails 6 assertions across 4 of the 5 cases, the handedness test among them. Owed, and not claimed done: on-glass re-verification through a real iOS device, together with the two already owed on that rig (the 9e9bb9f4 sign fix and the Android calibration read) — one pass covers all three. G14's DualSense neutral acceleration is now unblocked by this measurement (1 g on slot 1, not the z-up the notes assumed) but is deliberately left to its own change; and that constant must NOT be propagated to switch_proto, which is a different device whose frame nobody has measured. Gate: macOS `swift build` + the full suite (215 tests, 5 skipped, 0 failures) with the five new cases observed in the run's own output, and the iOS-triple typecheck green.	2026-08-07 18:41:54 +02:00
enricobuehler	aaa58ad817	feat(client/apple): say when a pad's gyro can't reach the session, and stop powering it ... G8's Apple half — the UI hint 77797a9e left owed, plus the suppression, which on this client is worth more than it was on the SDL one. The failure being fixed is entirely silent. A controller with a gyro, in a session whose virtual pad has no motion plane, simply does nothing when tilted: nothing in the app says so, and from the couch a session that resolved an X-Box backend is indistinguishable from a broken sensor. The fix is the Controller type setting, so the hint has to name it — a badge that only said "motion unavailable" would leave the player exactly as stuck. Asked per pad, off what the slot declared, via the predicate punktfunk-core now carries. `GamepadCapture` is the one client where this is naturally per pad already: `openSlot` computes `manager.declaredKind(for:)` and puts it in `slot.pref`, so the question is answered where the pad is opened rather than on every sample. `GamepadType.motionReaches(declared:asked:resolved:)` is static and pure so it can be tested without a live session; the connection's instance method fills in the two halves it owns, and `requestedGamepad` is stored beside `resolvedGamepad` for the same reason it exists in the Rust client — the echo is only this pad's answer when the pad declared what we asked for. Where Apple differs from the SDL client, and better: it never powers the IMU. The existing code already declined to activate sensors when forwarding was off, reasoning that with nothing to forward there is no reason to make the pad stream gyro over Bluetooth and burn its battery — `closeSlot` is careful to power them back down for exactly that reason. A host that built this pad a backend without a motion plane is the same situation, so it takes the same branch. No per-sample check, no handler attached, and a DualSense in an X-Box-class session stops paying for a sensor nobody reads. The hint fires only for a pad that really has a gyro (`motion.hasRotationRate`). A gravity-only GCMotion — what an X-Box controller exposes — would otherwise produce a notice about a feature the player never had. That is a narrower condition than the capture path itself uses, deliberately: making the capture gate agree is G13's job and its own change. The badge sits in the bottom-centre stack with the muted-mic badge and the start-of-stream banner, at every stats tier and with the overlay off, because this is not a statistic. Unlike the mic badge it is not a control: the setting is not reachable mid-stream on every platform and applies from the next session anyway. So it states the fact, names the setting, and leaves after the banner's same 6 s. Every platform including tvOS — a DualSense on an Apple TV is an ordinary way to play, and is exactly the pad this happens to. The model owns the expiry rather than the view, so a second pad's hint replaces the first cleanly instead of stacking, and ending the session cancels a pending clear rather than carrying a stale hint into the next stream. Non-vacuity proven by mutation, not assumed: collapsing the predicate to `resolved.hasMotion` fails 4 assertions, including the mixed-pad row that is the whole reason it is not a session-level check. The table mirrors the Rust one row for row — a client that disagrees with the host here either kills a working gyro or streams ~250 Hz into a void, and both are silent. Gate: macOS `swift build` + the FULL suite (210 tests, 5 skipped, 0 failures) with the two new cases observed in the run's own output, and the iOS-triple typecheck green (`arm64-apple-ios17.0`, iOS slices + hand-assembled xcframework per the memory recipe) — the badge and the overlay it joins are on every platform, so the macOS build alone would not have covered them. tvOS remains unverifiable from this Mac; the badge deliberately reuses the neighbouring banner's shape rather than introducing anything tvOS-specific.	2026-08-07 16:55:03 +02:00
enricobuehler	9e9bb9f466	fix(client/apple): acceleration was upside down — measured on glass ... G16, first result. A DualSense paired to an iPhone, streaming to a Linux host, lying flat and face up: hid-playstation decoded z = −0.99 g where a DualSense owes +1.00. Vector magnitude was 1.006 g, so the scale was already correct — this is purely direction, and it was wrong for every accelerometer sample the Apple client has ever sent. The cause is a convention mismatch, not a sign typo. Apple reports acceleration as the gravity VECTOR, which points down: a device face-up on a table reads z = −1. An accelerometer physically measures proper acceleration, and at rest that is the +1 g normal force pushing UP — which is what a DualSense's report, and therefore our wire, carries. The two are exact negatives. Both branches were affected, because `m.acceleration` follows the same Apple convention as the gravity/userAcceleration split, so reading the "raw vector" was not an escape from it. `rotationRate` is a true angular rate and needs no flip. The same session confirmed that independently: rotating the pad clockwise seen from above produced a negative yaw, which is correct under the right-hand rule about an up-pointing Z. That asymmetry — accel wrong, gyro right — is itself evidence for this diagnosis rather than a blanket frame error, and it is why the fix is three negations at one site instead of a remap. The sweep predicted this ("Apple accel plausibly INVERTED — CoreMotion gravity -1 g vs DS +1 g up at rest") but could not confirm it without hardware. It is now measured, and the mechanism is confirmed in the code rather than inferred from the number. Method, for whoever repeats it: the readout is python-evdev on the host reading the virtual pad's own motion node, dividing by the axis `resolution` the kernel publishes, so it prints deg/s and g. That is downstream of the calibration blob — the same layer a game reads — which is what makes a sign error visible to a human at all. Two things this does NOT establish. The host was a KVM guest, so the DualSense could not be attached natively for a side-by-side reference reading; the test stands on the DualSense convention being a fixed property of the hardware, which is decisive for the at-rest sign but weaker for the gyro axis ORDER. And the fix itself is unverified on glass: confirming it needs a rebuilt client on the device, so someone should re-run the same at-rest reading and see +1.00. Gate: `swiftc -parse` clean. A full typecheck needs the gitignored PunktfunkCore.xcframework assembled first and has not been run.	2026-08-07 14:56:27 +02:00
enricobuehler	1f54b75c5c	feat(client/apple): the phone's gyro can speak for a gyro-less pad ... Opt-in "Gyro from this device" (DefaultsKey.gyroFromDevice, off by default, iOS only): while player 1's forwarded controller reports no rotation rate of its own — no GCMotion, or the gravity-only motion an Xbox pad exposes — this device's IMU sources pad 0's wire motion instead. The rumble-on-device mirror's sibling, data flowing the other way: same session-scoped UserDefaults read, same hardware-gated settings rows, same pad-0 rule. DeviceGyro wraps CMDeviceMotion at the ~100 Hz CoreMotion ceiling on a dedicated serial queue (not main — the controller path's main-queue delivery is a known jitter source), converts with the shared GamepadWire constants, and rotates each sample from the device's portrait frame into the controller frame by interface orientation, so a phone clipped landscape yaws when the player yaws instead of rolling. The remap matrix is derived and pinned by DeviceGyroRemapTests. GamepadCapture owns engage/stand-down (reconcile, suspend/resume, stop), and suppresses pad 0's controller-motion forwarding while the mirror runs — two writers on one pad's motion state would fight, and the accel-only stream would stomp the mirror's gyro with zeros. Also fixes the stale-motion latch from the gyro sweep on the controller path: flush now parks motion at zero (keeping the last accel, so gravity doesn't become free-fall), and the mirror's stop sends the same closing zero. The host holds motion as state and re-emits it — a nonzero angular velocity left behind read as endless rotation for as long as an overlay (Control Center pull-down) kept the app inactive.	2026-08-07 11:38:13 +02:00
enricobuehler	9fb41affba	fix(clients/settings): a controller setting you can't use no longer looks like one you can ... Turn "Forward controllers" off and four rows below it stop meaning anything — nothing is forwarded, so there is no pad type to pick and no guide button to route. GTK desensitised them, the touch settings on both mobile clients dimmed them and the console UI refused the step; the Windows client and BOTH controller-navigable screens left them fully live, so you could sit there changing settings that did nothing. Windows: `.enabled(s.gamepad_forwarding)` on the forwarded-controller picker, pad type, guide button and hold-Select rows — the same builder the echo-cancellation row already used to follow the mic switch. Apple's gamepad settings had no way to say it: `Row` carried `adjustable` (which only hides the chevrons) and nothing else. Added `Row.enabled`, dimmed the row CONTENTS only so the glass still reads as a focusable row, and enforced the inertness centrally in `adjust(id:)` / `activate(id:)` rather than in each builder's closure. The hint bar drops "Adjust"/"Change" on a dimmed row, because advertising them was the same lie the live row told. Android's gamepad settings already had `GpRow.enabled` — documented as "dimmed + inert" — but it only faded the label: every dimmed row still stepped and still wrote its setting. The "No profiles yet" placeholder looked inert only because its own closures were empty. Made it real in one named place (`liveRow`), covering all three input paths (left/right, A, and a tap on the already-focused row), then gated the pad rows on it. Also on that screen: the DualSense / DualShock passthrough toggle, which the touch settings have carried beside its SC2 twin all along. It was missing exactly where it matters most — a TV box has no touch interface to fall back to, so there was no way to reach it at all. Apple capture, separately: with forwarding off, opening a slot still claimed EVERY element's system gesture and powered the controller's IMU. Neither reaches the host, so the first only took the user's screenshot/Home gestures away for nothing and the second drained the pad's battery streaming gyro over Bluetooth. Narrowed rather than skipped — the escape chord is read off the same slot and on tvOS is the ONLY controller way out of a stream, so the chord's own four buttons keep their claim. A test pins the alias list against the chord mask; if they drift the symptom is a session nobody can leave, with nothing logged. Closes R17, R18, R19 (design/haptics-sweep-2026-08-03.md M11). R17 as filed named Windows and "Apple"; Apple's TOUCH settings were already correct and Android's controller-navigable screen was not — both corrected here. Verified: Windows clippy -D warnings exit 0 on a real Windows box; Apple swift build clean + full suite 192 tests / 0 failures (3 new); Android :app: + :kit: green (5 new); cargo fmt --all --check clean. Each fix probed by reverting it — every probe failed the tests it should.	2026-08-04 22:25:51 +02:00
enricobuehler	1db7058a5d	feat(clients/input): system buttons route around local overlays ... Pressing guide/Steam/QAM collided with the client device's own shell: iOS 26 opens its Game Overlay for the Home press (no app opt-out until iOS 27 makes it a user setting), and a Gaming-Mode client opened BOTH Steam overlays for one press — the local one covering the stream. Two cross-client tier-P settings, zero wire changes: - system_buttons (auto|forward|local): raw guide+misc1 passthrough. Auto forwards everywhere EXCEPT under gamescope, where SteamOS reacts to the same physical press no matter what. - guide_gesture (auto|on|off): hold Select ALONE ~350ms sends the HOST's guide, down until release — held on, that's the host's long-press, which opens a Gaming-Mode host's QAM for regular pads. A Select tap is delivered on release with its up TAP_PRESS (50ms) behind, because per-transition sends fold into seq'd GamepadState snapshots and a back-to-back pair can coalesce into no press at all. A Select inside a combo (the escape chord) passes through untouched. Auto arms it only where the raw press can't reach the host cleanly: gamescope, iOS/iPadOS, tvOS. The same SelectGesture rules live in pf-client-core (pure state machine + unit tests), the Apple client (mask-diff adaptation in GamepadCapture), and Android's GamepadRouter. Settings rows on every surface (GTK, WinUI, console UI, Decky, Apple x2, Android x2) with profile plumbing throughout. punktfunk-session grows a control socket ($XDG_RUNTIME_DIR[/app/$FLATPAK_ID]/punktfunk-session-ctl.sock — the one runtime path a flatpak and the host see identically): 'guide'/'qam' verbs inject synthetic taps. The Decky panel gains a Host menus section (visible while the client runs) whose buttons press the host's Steam/QAM and close the local menu so the host's shows through. iOS 27's GCControllerHomeButtonSettingsManager deep-link is a TODO (the class needs the Xcode 27 SDK to compile). Docs: input, client-settings, steam-deck. Design: punktfunk-planning design/system-buttons-routing.md. Gates: docker clippy --all-targets --locked -D warnings + tests (pf-client-core 88 incl. 6 new gesture tests, pf-console-ui 47), cargo fmt --all --check, swift build (macOS), gradle kit+app compile, decky tsc --noEmit + py_compile. clients/windows not compiled (no box).	2026-08-04 21:46:27 +02:00
enricobuehlerandClaude Opus 5	b297542c4d	feat(clients/input): controllers can stop being forwarded, for couches that hand the pad over another way ... A controller that reaches the host by USB passthrough — VirtualHere and friends, or simply a pad plugged into the host — arrived there twice: once as the real device, once as the virtual pad this client built from the same hands. Games read both, so a stick drifts against the centred second pad and menus take every input twice. New per-client setting, "Forward controllers", default on (today's behaviour). It is tier-P, so a profile can decline what another profile forwards. On Linux and Windows it is deliberately stronger than "send nothing". Opening a controller is what CLAIMS it — SDL's HIDAPI drivers take the device node — and a claimed device is one a passthrough tool cannot bind, so with this off the session opens no slot at all and never enables the Valve HIDAPI drivers. Menu navigation is untouched: the launcher still opens the active pad, and a session supersedes menu mode whether it forwards or not, so the pad is free for the whole time a stream is up. The consequence, documented at both the setting and the chord: the controller escape chord is read off forwarded pads, so it is unavailable there. The Apple and Android input stacks claim nothing, so those clients keep their slots and their chords and only gate the wire sends — losing tvOS's only controller way out of a stream would have been the worse bug. Android does stop its DualSense and Steam Controller 2 USB captures, which do claim the device. Surfaces: GTK, WinUI, the console settings screen, Apple's touch and gamepad settings, the Android touch and gamepad settings, and Decky (which also hides the rows that now have nothing to act on). Everywhere the "which pad" and "pad type" rows grey out while it is off. Verified: cargo clippy --all-targets -D warnings + 79 tests on pf-client-core, pf-console-ui, punktfunk-client-session and punktfunk-client-linux (linux/amd64 container, gate proven non-vacuous with a planted error); swift build for the Apple clients; gradle compile + 49 unit tests for Android (likewise proven); tsc for Decky. clients/windows is UNCOMPILED — both Windows boxes were offline; its edits were reviewed against the helper signatures by hand. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 22:21:26 +02:00
enricobuehlerandClaude Opus 5	0d9d78398c	fix(drivers/windows): name each virtual pad for what it is — one shared description read as "the setting did nothing" ... `pf_dualsense.inx` gave all four hardware ids a single %DeviceDesc%, so Device Manager labelled an emulated DualShock 4, DualSense Edge and Steam Deck pad "punktfunk Virtual DualSense". The HID layer was always per-type — device_type picks the PID (09CC for DS4), the report descriptor and the product string — but the one place a user goes to check said DualSense for every choice, which reads exactly like the controller-type setting being ignored. Split into four model lines over the same install section, one description each. No binding, service or descriptor change; stampinf's 9.9.MMdd.HHmm DriverVer increments on every build, so pnputil takes the update. InfVerif on the WDK runner: INF is VALID. Also correct the Slot.pref comment from the previous commit: emulating a DualShock 4 gives up adaptive triggers by construction. HidOutput::Trigger is emitted only by dualsense_proto, and a DS4 has no trigger-effect reports — the host never generates any to send. Rumble and the lightbar remain. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 16:56:44 +02:00
enricobuehlerandClaude Opus 5	6edd700910	fix(client/gamepad): honor an explicit controller type — the per-pad arrival was re-declaring the physical pad ... The "Controller type" setting reached the Hello and stopped there. Every pad then opened with a GamepadArrival carrying its DETECTED kind, and the host builds each virtual device from that arrival — the session default is only the fallback for a pad that never declares one. So "emulate my DualSense as a DualShock 4" put a DualSense on the host the instant the controller connected, and no amount of reconnecting helped. Apple and the native clients both; Android already applied the setting per pad. The setting now rides the declaration too: explicit wins for every slot, Automatic keeps per-pad detection so a mixed session stays honest. The physical kind still drives the LOCAL feedback paths — a DualSense emulated as a DualShock 4 keeps its lightbar and adaptive triggers, and a Deck keeps its rumble keep-alive. Regressed in 97c67b26 / 76be4c3e (multi-controller support); ships in 0.19.x. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 16:56:44 +02:00
enricobuehlerandClaude Opus 4.8	26cac9ce20	fix(gamepad): truncate stick/trigger axes uniformly across clients (G25) ... Apple's GamepadCapture rounded axis values (`(v * scale).rounded()`) while SDL-core and Android truncate, so a half-pressed control emitted 128 on Apple vs 127 elsewhere. Drop `.rounded()` so `Int32(Float)` truncates toward zero on Apple too; rails are unchanged (full deflection stays 255 / ±32767). Also clamp SDL-core's LeftX/RightX to a symmetric -32767 like the Y axes and the other clients already do, instead of letting the raw i16 reach -32768. Verified: Apple `swift build` + full PunktfunkKit suite (124 pass); SDL half on Windows .173 `cargo clippy -p pf-client-core -- -D warnings` (green). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 22:05:13 +02:00
enricobuehlerandClaude Opus 4.8	68b9f108ab	feat(gamepad/apple): send Share/Create as BTN_MISC1 + pin wire bits to the C ABI ... G5: buttonMask mapped the dedicated share/create/capture element onto BTN_BACK, the same bit as View (buttonOptions). On an Xbox-Series pad those are two distinct physical buttons, so Share was indistinguishable from View on the host and never delivered the capture bit the host already decodes (DualSense mute / Steam quick-access). Route it to BTN_MISC1 instead, matching the Rust client's `Button::Misc1 => wire::BTN_MISC1`. Adds `misc1` to GamepadWire and allButtons so a held capture button is released on flush like the others. (On-glass verify owed on a real Xbox-Series pad; a clone pad that exposes one button as both buttonOptions and Share now emits back+misc1 for it — harmless on a plain xpad session and rare otherwise.) G22 (partial): define paddle1..4 for wire completeness, but leave them out of buttonMask/allButtons until the GameController paddleButton1..4 ↔ BTN_PADDLE physical correspondence is confirmed on a real Elite pad. G15: replace the 3-bit spot-check with an exhaustive assertion of every GamepadWire button/axis constant against the generated C ABI header (punktfunk_core.h), so any Swift-side drift from punktfunk_core::input::gamepad fails CI. swift build + full PunktfunkKit suite green (124 passed, 5 skipped). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 11:14:26 +02:00
enricobuehlerandClaude Opus 4.8	5cd66eca59	fix(gamepad/apple): stop releasing held guide on concurrent input ... `sync()` XOR-diffs the full `GamepadWire.allButtons` set (which includes guide) against `slot.buttons`, but `buttonMask` deliberately omits guide — it's driven separately by the Home handler via `sendGuide`. So while guide was physically held, the first stick/trigger/face-button move made `changed` carry the guide bit and the diff loop emitted a spurious guide-UP (then the real release was swallowed by `sendGuide`'s `guard now != slot.buttons`). Effect: you could not hold PS/guide while doing anything else — e.g. holding guide to keep the host's Steam overlay engaged released it the instant you touched a stick. The Rust reference client folds guide through the same diff as every other button and has no such split. Fix: preserve the current held guide bit through the diff (`buttonMask(g) | (slot.buttons & GamepadWire.guide)`) so guide is never seen as "changed"; `sendGuide` stays the sole toggler and `flush`/`allButtons` still release it on close/deactivation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 11:12:47 +02:00
enricobuehlerandClaude Opus 4.8	97c67b2692	feat(apple): multi-controller support ... Roll the pf-client-core slot pattern to the Apple client (Swift): - GamepadManager tracks all connected GCControllers, assigning each a stable lowest-free wire pad index + concrete type, emitting GamepadArrival on connect and GamepadRemove on disconnect (index freed for reuse on re-plug). - GamepadCapture binds every controller with per-controller Slot state (buttons/axes/fingers/motion), threading the pad index into flags on every event; GamepadWire/InputEvents carry the pad + the two new events. - GamepadFeedback + RumbleRenderer go per-pad (rumbleByPad, slots[pad]), routing rumble/HID back to the correct controller by wire index. - ContentView/Settings surface every forwarded controller. pad 0 => flags 0, so single-controller wire is byte-identical. Cannot build on the Linux dev box (no Swift toolchain / Apple frameworks); wire bytes hand-checked against input.rs and GamepadWireTests extended for multi-pad. CI apple.yml (swift build/test on macOS) is the compile gate. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 21:53:07 +02:00
enricobuehlerandClaude Fable 5	3ba19f28a2	feat(apple): the gamepad UI comes to tvOS - focus-driven, with real session controls ... The console UI now runs on tvOS through the NATIVE focus engine: carousel cards and settings rows are focusable Buttons (Siri Remote and pads both navigate; imperative scrollTo replaces the drop-prone scrollPosition binding), while iOS/macOS keep the 60 Hz poll untouched - on tvOS it carries only what focus has no concept of: X/Y screen actions and left/right value adjust with the poll's dominant-axis feel (onMoveCommand proved input-source-dependent: keyboard intercepted, pad dpad not -> double steps). Text entry uses the system fullscreen keyboard (TVTextEntry); pairing + library present as covers under the launcher; the game library defaults ON; settings values slide a quiet 14 pt in the step's direction. Session controls: controller/remote input routes EXCLUSIVELY through GameController during a stream (GCEventViewController, interaction disabled) - a pad's B no longer doubles as a UIKit menu press that ended sessions mid-game. Deliberate exits only: the cross-client escape chord (hold L1+R1+Start+Select 1.5 s - pf-client-core's contract, now implemented on all Apple platforms) and holding the remote's Back >= 1 s; the start-of-stream banner (now also on tvOS) teaches both. The Siri Remote's touch surface drives the host pointer - press = left click, Play/Pause = right click, release-tail jumps gated so motion stays truly relative. tvOS 26 regressions fixed at the root: the app-wide brand tint rendered every unfocused control as a blank pill (tint dropped on tvOS) and the 17 pt root font shrank the whole platform (29 pt there), plus 10-foot sizing across host cards, the gamepad screens, and the stats HUD (whose misleading "Press Menu" hint is gone). Acknowledgements scrolls by focus-sized chunks and Menu pops instead of suspending; full-width focusSections make the home actions reachable from any column. The presenter defaults to stage-3 glass pacing on tvOS (a 60 Hz panel fed a 60 fps stream is the sticky-FIFO worst case behind the 50 ms display stage) and is pickable from the gamepad settings; HDR capability advertises from AVPlayer.eligibleForHDRPlayback instead of the current mode's EDR headroom, so an SDR home screen no longer hides an HDR TV. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 16:59:01 +02:00
enricobuehlerandClaude Fable 5	a35a761c37	feat(apple/gamepad): claim controller system gestures during capture — PS button opens the Steam overlay, share/create stops screenshotting locally ... While a pad drives a stream, GamepadCapture now sets EVERY element's preferredSystemGestureState to .disabled (restored to .enabled on unbind). iOS/macOS attach system gestures to several controller buttons — share/create took a LOCAL screenshot instead of reaching the game, and only the Home element was opted out before. With the gestures claimed, the already-wired chains do their job: PS/Home → wire guide → BTN_MODE on the virtual xpad (the Steam-overlay button) / the PS bit on the virtual DualSense. Also fold the share/create/capture element (GCInputButtonShare) into the back/select wire bit — clone pads like the GameSir G8 expose their screenshot button only as the share element, not buttonOptions (OR onto the same bit, so double-exposed pads are harmless). The G8's other extra button (M) is a firmware-local modifier (turbo/hair-trigger/swap) invisible to the OS. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-02 23:36:16 +02:00
enricobuehlerandClaude Fable 5	34fe896ade	feat(apple): gamepad UI v2 — controller settings + add host, aurora, macOS ... Sources reorganized (client: Home/Session/Settings/Stores/Support/Trust; kit: Audio/Connection/Gamepad/Input/Support/Video/Views) with the big files split along the same seams. The gamepad mode is couch-complete, and now on macOS too (the living-room Mac case), not just iOS/iPadOS: - GamepadSettingsView: a console-style, fully controller-navigable settings screen (X from the launcher) — up/down moves focus, left/right steps values (clamped, boundary thud), A cycles/toggles, B closes; the focused row shows a one-line description. Backed by GamepadMenuList, the vertical sibling of GamepadCarousel, and SettingsOptions — the option lists hoisted out of SettingsView statics and shared by the touch, tvOS and gamepad settings. - GamepadAddHostView + GamepadKeyboard: register a host end to end with a pad — field rows open an on-screen controller keyboard (dpad grid, A types, X backspaces, B done); the launcher carousel ends in an Add Host tile, so the dead-end "add one with touch first" empty state is gone. - Launcher polish: contextual hint bar with the pad's real button glyphs, controller name + battery chip, one shared console chrome. - GamepadScreenBackground: an animated aurora (TimelineView-driven drifting blobs in the brand's violet family, breathing radii, slow hue shift, legibility scrim; freezes under Reduce Motion). Pure SwiftUI on purpose — a .metal library only bundles reliably in one of the two build systems (SPM vs the xcodeproj's synced folders) these sources compile under. - macOS port: settings/add-host/library present as sized sheets (a macOS sheet takes its content's IDEAL size, and the GeometryReader-driven screens collapsed to nothing), NSScreen-based mode lists, scroll indicators .never (the "always show scroll bars" setting overrides .hidden), tray scrims so scrolled rows dim under the pinned title/hints, extra title clearance, and a PUNKTFUNK_FORCE_GAMEPAD_UI=1 dev hook — launcher/settings/add-host/keyboard/ library render-verified live on a real Mac + LAN hosts. - GamepadMenuInput: X button support, and (re)start now snapshots held buttons so a controller handoff press never fires twice (the B that closed the keyboard no longer also cancels the screen underneath). - Cleanups: one "Connection failed" alert in ContentView instead of one per home screen; HostDiscovery.advertises/unsaved shared by both home screens. - host: can_encode_444 stub for the non-Linux/Windows host build (the macOS synthetic-source loopback used by the Swift tests). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-02 11:24:44 +02:00