Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Touch Bar dead on T1 Macs: macbook12-spi-driver DKMS never builds
Reported by passerini · filed Sep 8, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
What happened
On a MacBookPro13,3 (2016 15", T1 chip), the Touch Bar is completely dead after
a fresh install. The row is dark and no function keys are available.
Three separate causes stack up, all in the Omarchy install path:
1. `fix-spi-keyboard.sh` installs the DKMS package but not `linux-headers`.
install/hardware/apple/fix-spi-keyboard.sh runs:
omarchy-pkg-add macbook12-spi-driver-dkmslinux-headers is not a dependency of that package, and nothing else in the
install pulls it in for this code path. (install/hardware/fix-bcm43xx.sh does
add dkms linux-headers alongside broadcom-wl, so the omission looks
accidental.) Without headers DKMS silently never builds:
$ dkms status
(empty)
$ ls /var/lib/dkms/
(empty)The install prints no error, so the machine boots looking healthy. Keyboard and
trackpad still work because the kernel's own in-tree applespi covers them —
only the Touch Bar is missing, which makes this easy to misread as an
unsupported-hardware problem.
2. With headers installed, `macbook12-spi-driver` does not compile on kernel 7.1.
$ sudo pacman -S linux-headers
...
==> dkms install --no-depmod macbook12-spi-driver/0+git.315 -k 7.1.9-arch1-2
Error! Bad return status for module build on kernel: 7.1.9-arch1-2 (x86_64)Five instances of kernel API drift since the driver's last update (2019):
| File | Error | Kernel change |
|---|---|---|
apple-ib-tb.c:1293 | initialization of 'void (*)(struct platform_device *)' from incompatible pointer type 'int (*)(...)' | platform_driver.remove returns void (6.11+) |
apple-ib-als.c:679 | same | same |
apple-ibridge.c:752 | initialization of 'const __u8 *(*)(...)' from incompatible pointer type '__u8 *(*)(...)' | hid_driver.report_fixup returns const __u8 * |
apple-ibridge.c:901 | 'struct acpi_driver' has no member named 'owner' | .owner removed from struct acpi_driver |
applespi.c:64 | fatal error: asm/unaligned.h: No such file or directory | renamed to linux/unaligned.h (6.12+) |
The mainline drivers do not cover this hardware, so there is no fallback:hid-appletb-kbd, hid-appletb-bl and appletbdrm all match only 05AC:8302
/ 05AC:8102, which are T2 Macs. The T1 iBridge is 05AC:8600.
3. Even once built, `apple-ibridge` loses a driver race against `hid-sensor-hub`.
Both HID interfaces of the iBridge expose modaliashid:b0003g0003v000005ACp00008600. hid-sensor-hub claims it with a generic
vendor/product match; apple-ibridge claims it viaHID_USB_DEVICE(0x05AC, 0x8600). Both match, so whichever registers first wins
— and udev loads hid-sensor-hub from modalias as soon as USB enumerates,
well before systemd-modules-load gets to apple-ibridge:
kernel: hid-sensor-hub 0003:05AC:8600.0002: hiddev96,hidraw1: USB HID v1.01 Device [Apple Inc. iBridge]
kernel: apple_ibridge: loading out-of-tree module taints kernel
kernel: apple-ibridge-hid 0003:05AC:8600.0001: input,hidraw0: USB HID v1.01 Keyboard [Apple Inc. iBridge]apple-ibridge recovers .0001 from hid-generic but never gets .0002, and
the Touch Bar stays dark. Both platform devices bind and probe cleanly, so
nothing in the log suggests a failure.
What was expected
A working Touch Bar on a Mac model that fix-spi-keyboard.sh explicitly
detects (MacBookPro13,[123] is in its regex).
Steps to reproduce
- Install Omarchy 4.0.2 on any T1 Mac (MacBookPro13,x or MacBookPro14,x).
- Boot and look at the Touch Bar — dark.
dkms status→ empty.
Fix
All three parts were needed to get it working here:
- Add
linux-headersto theomarchy-pkg-addcall infix-spi-keyboard.sh. - Patch
macbook12-spi-driverfor the four API changes above. I excluded
applespi from the DKMS build rather than fixing its one-line include, since
the in-tree applespi is maintained, already works, and the DKMS copy would
shadow it via updates/dkms/ — the three iBridge modules don't reference it.
3. Ship a softdep so apple-ibridge registers first:
# /etc/modprobe.d/apple-ibridge.conf
softdep hid-sensor-hub pre: apple-ibridgeAfter all three, apple-ibridge-hid owns both .0001 and .0002 and the
Touch Bar works.
I'm happy to open a PR for items 1 and 3 if that's useful. Item 2 belongs in themacbook12-spi-driver-dkms package rather than in the installer.
System details
- Model: MacBookPro13,3 (Mac-A5C67F76ED83108C), Apple T1
- Omarchy: 4.0.2-1
- Kernel: 7.1.9-arch1-2
- CPU: Intel Skylake-H
- GPU: Intel HD Graphics 530 (i915) + AMD Radeon Pro 460 (amdgpu)
- iBridge: USB
05ac:8600
View raw text
### What happened On a MacBookPro13,3 (2016 15", T1 chip), the Touch Bar is completely dead after a fresh install. The row is dark and no function keys are available. Three separate causes stack up, all in the Omarchy install path: **1. `fix-spi-keyboard.sh` installs the DKMS package but not `linux-headers`.** `install/hardware/apple/fix-spi-keyboard.sh` runs: ``` omarchy-pkg-add macbook12-spi-driver-dkms ``` `linux-headers` is not a dependency of that package, and nothing else in the install pulls it in for this code path. (`install/hardware/fix-bcm43xx.sh` does add `dkms linux-headers` alongside `broadcom-wl`, so the omission looks accidental.) Without headers DKMS silently never builds: ``` $ dkms status (empty) $ ls /var/lib/dkms/ (empty) ``` The install prints no error, so the machine boots looking healthy. Keyboard and trackpad still work because the kernel's own in-tree `applespi` covers them — only the Touch Bar is missing, which makes this easy to misread as an unsupported-hardware problem. **2. With headers installed, `macbook12-spi-driver` does not compile on kernel 7.1.** ``` $ sudo pacman -S linux-headers ... ==> dkms install --no-depmod macbook12-spi-driver/0+git.315 -k 7.1.9-arch1-2 Error! Bad return status for module build on kernel: 7.1.9-arch1-2 (x86_64) ``` Five instances of kernel API drift since the driver's last update (2019): | File | Error | Kernel change | |---|---|---| | `apple-ib-tb.c:1293` | `initialization of 'void (*)(struct platform_device *)' from incompatible pointer type 'int (*)(...)'` | `platform_driver.remove` returns `void` (6.11+) | | `apple-ib-als.c:679` | same | same | | `apple-ibridge.c:752` | `initialization of 'const __u8 *(*)(...)' from incompatible pointer type '__u8 *(*)(...)'` | `hid_driver.report_fixup` returns `const __u8 *` | | `apple-ibridge.c:901` | `'struct acpi_driver' has no member named 'owner'` | `.owner` removed from `struct acpi_driver` | | `applespi.c:64` | `fatal error: asm/unaligned.h: No such file or directory` | renamed to `linux/unaligned.h` (6.12+) | The mainline drivers do not cover this hardware, so there is no fallback: `hid-appletb-kbd`, `hid-appletb-bl` and `appletbdrm` all match only `05AC:8302` / `05AC:8102`, which are T2 Macs. The T1 iBridge is `05AC:8600`. **3. Even once built, `apple-ibridge` loses a driver race against `hid-sensor-hub`.** Both HID interfaces of the iBridge expose modalias `hid:b0003g0003v000005ACp00008600`. `hid-sensor-hub` claims it with a generic vendor/product match; `apple-ibridge` claims it via `HID_USB_DEVICE(0x05AC, 0x8600)`. Both match, so whichever registers first wins — and udev loads `hid-sensor-hub` from modalias as soon as USB enumerates, well before `systemd-modules-load` gets to `apple-ibridge`: ``` kernel: hid-sensor-hub 0003:05AC:8600.0002: hiddev96,hidraw1: USB HID v1.01 Device [Apple Inc. iBridge] kernel: apple_ibridge: loading out-of-tree module taints kernel kernel: apple-ibridge-hid 0003:05AC:8600.0001: input,hidraw0: USB HID v1.01 Keyboard [Apple Inc. iBridge] ``` `apple-ibridge` recovers `.0001` from `hid-generic` but never gets `.0002`, and the Touch Bar stays dark. Both platform devices bind and probe cleanly, so nothing in the log suggests a failure. ### What was expected A working Touch Bar on a Mac model that `fix-spi-keyboard.sh` explicitly detects (`MacBookPro13,[123]` is in its regex). ### Steps to reproduce 1. Install Omarchy 4.0.2 on any T1 Mac (MacBookPro13,x or MacBookPro14,x). 2. Boot and look at the Touch Bar — dark. 3. `dkms status` → empty. ### Fix All three parts were needed to get it working here: 1. Add `linux-headers` to the `omarchy-pkg-add` call in `fix-spi-keyboard.sh`. 2. Patch `macbook12-spi-driver` for the four API changes above. I excluded `applespi` from the DKMS build rather than fixing its one-line include, since the in-tree `applespi` is maintained, already works, and the DKMS copy would shadow it via `updates/dkms/` — the three iBridge modules don't reference it. 3. Ship a softdep so `apple-ibridge` registers first: ``` # /etc/modprobe.d/apple-ibridge.conf softdep hid-sensor-hub pre: apple-ibridge ``` After all three, `apple-ibridge-hid` owns both `.0001` and `.0002` and the Touch Bar works. I'm happy to open a PR for items 1 and 3 if that's useful. Item 2 belongs in the `macbook12-spi-driver-dkms` package rather than in the installer. ### System details - Model: MacBookPro13,3 (Mac-A5C67F76ED83108C), Apple T1 - Omarchy: 4.0.2-1 - Kernel: 7.1.9-arch1-2 - CPU: Intel Skylake-H - GPU: Intel HD Graphics 530 (i915) + AMD Radeon Pro 460 (amdgpu) - iBridge: USB `05ac:8600`
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
- Related PRpr/7064· confirmed
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 11:10 UTC