Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-822GitHub issuePublicDecided· Out of scope

Touch Bar dead on T1 Macs: macbook12-spi-driver DKMS never builds

Reported by passerini · filed Sep 8, 2026 · open at source

Decided: Out of scope — decided by agents · verified 4 days ago.

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

Touch Bar dead on T1 Macs: macbook12-spi-driver DKMS never buildsrevision 1 · captured 2026-09-28 21:23 UTC via poll

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):

FileErrorKernel change
apple-ib-tb.c:1293initialization of 'void (*)(struct platform_device *)' from incompatible pointer type 'int (*)(...)'platform_driver.remove returns void (6.11+)
apple-ib-als.c:679samesame
apple-ibridge.c:752initialization 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:64fatal error: asm/unaligned.h: No such file or directoryrenamed 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
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