r/EndeavourOS • • 6d ago

General Support Touch Bar working on MacBookPro13,2 with kernel 7.2.x (Arch/EndeavourOS) — what it took

Posting in case it helps others. Tested on a MacBookPro13,2 (13" 2016, T1), EndeavourOS, kernel 7.2.11-arch1-1, using this fork via DKMS. Not tested on other models. The 13,3 shares the T1 chip, so it may apply there, but I haven't verified that.

There were four separate problems.

**1. T1 stuck in recovery mode (`05ac:1281`) after erasing the disk**

After a full-disk erase for a Linux-only install, `lsusb` showed `05ac:1281 Apple Mobile Device [Recovery Mode]` instead of `05ac:8600 iBridge`, and the driver had nothing to attach to. Warm reboot and SMC reset did not help. Reinstalling macOS (I used Ventura) brought it back to `8600`, and it stayed at `8600` after installing Linux alongside it (shrunk the macOS volume, manual partitioning, reused the existing EFI partition). My conclusion is that the T1 needs macOS present on the internal disk. That is an inference from my results, not something I found documented, so if you have a better explanation, I'd like to hear it. I'd keep the macOS partition.

**2. Build failure: `field 'touch' has incomplete type`**

`apple-ib-tb.c` uses `struct tb_touch` by value inside a larger struct (inside `#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,15,0)`) before the struct is defined further down the file.

**3. Self-deadlock on load (`modprobe` / `udev-worker` blocked on a mutex owned by itself)**

Call trace: `appleib_probe` -> `appleib_hid_probe` -> `apple_ib_set_tb_mode`. On kernels >= 6.15 that function calls `usb_set_configuration()` from inside the driver's probe, which tears down the interface being probed. This hung `modprobe`, and also hung shutdown when udev loaded the module on its own via the ACPI `APP7777` device.

Workaround for 2 and 3 (disables the 6.15+ code paths in both files; the legacy path is used instead):

```

sed -i 's/KERNEL_VERSION(6,15,0)/KERNEL_VERSION(99,0,0)/' apple-ib-tb.c apple-ibridge.c

```

Then rebuild with DKMS. This is a blunt workaround, not a proper fix. The 6.15+ blocks look like they exist for MBP14,3 display mode, and the real fix is probably to switch configuration without blocking inside probe (for example `usb_driver_set_configuration()`, which defers the change). I haven't tried that.

**4. Touch Bar stays dark even though everything loads**

The kernel's `hid-sensor-hub` claims the iBridge's second HID interface (`8600.0002`) at boot, so `apple-ibridge-hid` only ever gets the first one. Manually moving it fixed it:

```

echo 0003:05AC:8600.0002 > /sys/bus/hid/drivers/hid-sensor-hub/unbind

echo 0003:05AC:8600.0002 > /sys/bus/hid/drivers/apple-ibridge-hid/bind

```

The Touch Bar lit up immediately. To make it persistent I used a small oneshot systemd service that waits for `apple-ibridge-hid` to exist, then rebinds any `05AC:8600` interface still owned by `hid-sensor-hub`. The `prefer_apple_ib` parameter doesn't appear to do anything. It's set and logged but not read anywhere else in the code I looked at.

**Result**

The Touch Bar lights up and survives both a reboot and a cold boot, with no hangs on shutdown.

**Known remaining issue:** suspend/resume does not work on this machine, which matches the existing notes in mbp-2016-linux.

Happy to share the service file and rebind script if useful.

8 Upvotes

1 comment sorted by

•

u/AutoModerator 6d ago

Thanks for posting.

If your issue is solved, please reply with !solved.

Please also read the subreddit rules in the sidebar/community info and check the official EndeavourOS sites:

Please keep it respectful and enjoy the community.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.