fix: identify the Siri Remote's touch surface by its known geometry, fail closed otherwise - #4
Open
greghughespdx wants to merge 2 commits into
Open
Conversation
…th config pin override 'First non-built-in MT device' wrongly binds a Magic Trackpad on desktop Macs (no built-in trackpad to filter out), leaving remote swipes dead and the trackpad double-interpreted. Auto-select now picks the smallest sensor surface (Siri Remote ~3460x3640 vs Magic Trackpad ~15600x11040); an explicit device can be pinned via 'defaults write com.hypervibe.app trackpadDeviceID -string 0x<id>'. Candidates and the chosen device are logged to /tmp/hypervibe.log.
greghughespdx
changed the title
JamesZwq
added a commit
to JamesZwq/hypervibe
that referenced
this pull request
Jul 20, 2026
- ConfigStore.save now REFUSES to overwrite an on-disk config that doesn't parse (a hand-edit typo the app is running the fallback for), and backs up config.jsonc→.bak before any overwrite — so a UI gesture can no longer erase all bindings by writing fallback-derived content (fable machinarii#1). - Layer 'used' marking moved above the Spaces/repeatKey early-returns and wired into the select / swipe / two-finger paths, so hold-layer + repeat-key/click/gesture is momentary, not a false sticky toggle (fable machinarii#2). - Track the sticky-activator button so re-tapping toggles OFF even when the .layer binding isn't visible from inside the layer's own inherits chain (fable machinarii#3). - Hot-reload clears a sticky layer whose mode was deleted/renamed (else all keys resolve nil with no way to pop) (fable machinarii#4). Disconnect now KEEPS the sticky layer (BLE idle-disconnect shouldn't drop it) and only unwinds the momentary hold (fable machinarii#8). Pending double-tap singles are cancelled on disconnect (fable machinarii#6, partial). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
TouchHandler's device-selection heuristic picked the smallest-surface external multitouch device as "the remote's touchpad" with no absolute check against what the Siri Remote's surface actually looks like. With no remote connected, a Magic Trackpad is the only (and therefore "smallest") external device, so it got silently adopted: every trackpad swipe fired a remote gesture command, injecting slash-commands into whatever text field had focus. Same defect class as the media-key fix (5ed859d): consume only events confidently identified as remote-origin, let everything else pass through untouched. MTDevice exposes no vendor/product ID (unlike the HID button path's RemoteDetector.isSiriRemote vendor/product match), so identity here is established from the remote's known touch surface geometry (~3460x3640) versus any Magic Trackpad's (smallest known ~15600x11040, over an order of magnitude larger). Extracted the check into RemoteTouchSurface.swift, a framework-free pure function, so it can be unit-tested without linking MultitouchSupport.framework. Also removed the blind "use second device if available" fallback — the same class of guess this fix replaces. If no device can be confidently identified as the remote, no device is selected at all (fail closed): a missed remote is caught on the next reconnect scan; a wrongly-adopted trackpad was the actual bug. Added Tests/run-tests.sh (standalone swiftc compile+run, no SwiftPM — this repo's Package.swift deliberately excludes the private framework, per its own header comment, and the documented build path is build.sh) covering the Siri Remote surface, current and older Magic Trackpad surfaces, built-in-trackpad rejection, malformed-input fail-closed behavior, and the area threshold boundary. All 8 pass; verified the harness catches a regression by temporarily loosening the threshold. Rebuilt binary via build.sh to match current source (no running HyperVibe process was touched or restarted).
greghughespdx
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up hardening of this PR after real-world use exposed a hole in the first approach.
The original commit selected the smallest-surface external multitouch device as the remote. That fixed desktop Macs where "first external device" grabbed a Magic Trackpad, but the relative heuristic still failed in one common case: with no remote connected, a Magic Trackpad is the only (and therefore smallest) external device, so it got silently adopted and every trackpad swipe fired a gesture command into whatever had focus.
The second commit replaces the relative heuristic with positive identification: a device is only eligible if its surface geometry matches the Siri Remote's known touch surface (~3460x3640) - an order of magnitude smaller than any Magic Trackpad (~15600x11040). MTDevice exposes no vendor/product ID, so surface geometry is the identity signal, the touch-path analogue of the HID button path's vendor/product match. If no candidate qualifies, no device is selected at all (fail closed): a missed remote is picked up on the next reconnect scan, while a wrongly-adopted trackpad was the actual bug. The blind "use second device if available" fallback is removed for the same reason.
The explicit pin override (
defaults write com.hypervibe.app trackpadDeviceID -string 0x<id>) is unchanged and still wins over auto-selection.The check lives in
RemoteTouchSurface.swiftas a framework-free pure function with a standalone test harness (Tests/run-tests.sh, plain swiftc, no SwiftPM) covering the remote's surface, current and older Magic Trackpad sizes, built-in trackpad rejection, malformed input, and the threshold boundary - 8/8 passing.Verified on a desktop Mac with both a Siri Remote and a Magic Trackpad: remote gestures work, trackpad swipes pass through untouched.