a59abe2e3e
ci / docs-site (push) Successful in 31s
ci / rust (push) Successful in 6m30s
deb / build-publish (push) Successful in 3m58s
ci / web (push) Successful in 27s
apple / swift (push) Successful in 1m16s
ci / bench (push) Successful in 1m34s
docker / build-push (--build-arg FEDORA_VERSION=44, ci, ci/fedora-rpm.Dockerfile, punktfunk-fedora44-rpm) (push) Successful in 6s
docker / build-push (., web/Dockerfile, punktfunk-web) (push) Successful in 6s
docker / build-push (ci, ci/fedora-rpm.Dockerfile, punktfunk-fedora-rpm) (push) Successful in 4s
docker / build-push (ci, ci/rust-ci.Dockerfile, punktfunk-rust-ci) (push) Successful in 5s
docker / build-push (docs-site, docs-site/Dockerfile, punktfunk-docs) (push) Successful in 4s
rpm / build-publish (bazzite, punktfunk-fedora-rpm) (push) Successful in 5m13s
rpm / build-publish (fedora-44, punktfunk-fedora44-rpm) (push) Successful in 5m18s
docker / deploy-docs (push) Successful in 17s
The earlier buttonHome handler wasn't enough: on macOS the SYSTEM grabs the DualSense Home/PS button by default (opens Launchpad's Games folder), so it never reached the app. The fix is to disable the system gesture on the element — `physicalInputProfile.buttons[GCInputButtonHome].preferredSystemGestureState = .disabled` (Apple's documented mechanism) — which hands the button to us. Then drive `guide` DIRECTLY from that element's pressedChangedHandler instead of via buttonMask: the legacy `extendedGamepad.buttonHome` is unreliable/often nil even when the physical element exists, so reading it in the mask dropped presses. `sendGuide` folds the bit into `buttons` so a held PS button still releases on focus loss. On tvOS the element is reserved (nil) → the block no-ops. The host already maps BTN_GUIDE → the DualSense PS bit, so this completes the chain. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>