A switch with nothing behind it

FreeSlapMac 1.1.0 ships a “Lid Creaking Sound” toggle. The label is in the binary, the description is in the binary, the preference is in the binary — and there is no lid-sensor code and zero references to the creaking.mp3 sitting inside its own bundle. This is the missing half: a 385-line user-level helper that reads the MacBook lid-angle sensor at 20 Hz and plays that unused asset, packaged as an installer with a self-test.

01What was actually wrong

The investigation started from a sound that never played and a sensor that clearly existed. Both were true, and unrelated:

• The hardware is fine. An M2 MacBook Air (Mac14,2) exposes a lid-angle sensor at HID usage page 0x20 / usage 0x8A, read as feature report 1. A live read returns 01 68 00 → 0x0068 → 104°. Reading it needs no root and triggers no permission prompt.
• The free app never asks for it. Its GUI binary contains Lid Creaking Sound, the sentence “Plays a creaking door sound when you open or close the lid.” and the _creakingEnabled preference — and the string creaking.mp3 appears 0 times, LidAngle 0 times.
• The sound file was already there: Contents/Resources/Sounds/creaking.mp3, 150,816 bytes, 5.136 s, never referenced.
• The paid SlapMac has the feature — LidAngleSensor ×4, CreakAudioEngine ×3, lidCreakEnabled ×2. The free build shipped the switch without the engine.

02Evidence: free vs paid, same machine

03The sensor contract

04The decision path

hinge moves
   │
   ▼
IOHIDDeviceGetReport(dev, kIOHIDReportTypeFeature, 1)     20 Hz, unprivileged
   │  01 68 00 → 104°
   ▼
speed = |angle − prev| / Δt                                ignore Δt > 0.5 s (sleep/stall)
   │
   ├── speed < 1.5 °/s ................. drift, log nothing
   ├── 1.5 ≤ speed < 8 °/s ............. movement, no creak
   └── speed ≥ 8 °/s
          │
          ├── last creak < 1.4 s ago ... rate-limited (one creak per movement burst)
          └── gate: _creakingEnabled true   app open or quit — it never played this
                 │
                 ▼
          afplay -t 1.8 -v clamp(1.0 + speed/40, 1.0, 2.0) creaking.mp3
                 │
                 ▼
          ~/Library/Logs/lidcreak.log   creak vol=1.82

05Constants, and why each one exists

06What actually came out of the speaker

Not a claim — the helper's own log, one tilt of the screen:

20:31:03  move 80->85 deg  speed=32.9 deg/s  CREAK
20:31:03  creak vol=1.82
20:31:03  move 84->80 deg  speed=39.6 deg/s  skip:retrigger   (one creak per movement)
20:31:13  move 95->94 deg  speed=4.6  deg/s  skip:slow       (drift)

And the installer's self-test, which is what a new user sees at the end of install.sh:

lidcreak 1.0.1
LID ANGLE: 94.0
APP RUNNING: False  TOGGLE ON: True
SYSTEM OUTPUT: volume=60 muted=False
GAIN: 1.50  (afplay -v)
played creaking.mp3

07Audible, on the third try

v1.0.0 was published before it produced a sound, and the way it failed is worth writing down: every part worked, and the result was still silence.

• 422 creaks played and nobody heard one. The log has 422 trigger=YES lines from a single session. The Mac's output was volume:0, muted:true — muted, so every one of those afplay calls was rendered into nothing. The helper had no idea, and neither did the log: it reported success because afplay exited 0.
• With the app quit, the gate blocked everything. app_running() ran every trigger. Fast lid moves of 61.1 and 136.3 °/s were logged as trigger=no — the same text used for "the lid barely moved". FreeSlapMac was closed, and since the app never played this sound in the first place, requiring it only ever produced silence with no explanation.
• Even unmuted, 0.35 was too quiet. creaking.mp3 is mastered 30 dB below the tap sounds: mean −30.5 dBFS, peak −6.2 dBFS. At 0.35 gain the creak sits around −39 dBFS — about the level of a laptop fan.

1.0.1 fixes the three separately, because they are three separate lies: the gate now only reads the preference (the app can be quit), the gain runs 1.0–2.0 against the measured peak, and every skip is logged with its reason so "no sound" has an answer instead of a shrug. The helper also refuses to pretend: --self-test prints the output volume and mute state, and if the Mac is muted the daemon logs a warning instead of quietly succeeding.

It does not fix a muted Mac by itself, and it should not: a helper that turns your system volume up is the same behaviour that makes FreeSlapMac so annoying. It tells you instead — one warning in the log, one line in the self-test.

08Install, verify, remove

unzip freeslapmac-lidcreak-1.0.1.zip && cd freeslapmac-lidcreak
bash install.sh          # copies the helper, writes the LaunchAgent, self-tests
tail -f ~/Library/Logs/lidcreak.log     # tilt the screen: watch it fire
bash uninstall.sh        # agent, helper and logs gone; the app is untouched

Three files, no bundle surgery, no code-signing: the app is never modified, so a FreeSlapMac update cannot conflict with it — and uninstalling the helper restores the original silence.

09Failure modes

10Evidence table

Verified on macOS 26.6, MacBook Air M2 (Mac14,2), FreeSlapMac 1.1.0 (build 5), Python 3.9 (the /usr/bin/python3 the LaunchAgent runs). The installer was also dry-run against a sandbox $HOME and a test launchd label: install → self-test → uninstall, twice, exit 0 both times, with the live agent untouched.

11What is next

• Upstream: the honest fix is 20 lines inside FreeSlapMac — the sensor API is unprivileged and the asset is already bundled. This package exists because the app is a closed binary.
• Multiple creaks per movement: a continuous lid swing currently yields one creak per 1.4 s. Layering two truncated clips with different start offsets would sound more like a hinge and less like a sample.
• Direction-aware sound: opening and closing could use different pitch — the sign of Δangle is already computed.