Touchbar on 14,3 not working

[schaecsn]

Hi all

I run Debian Trixie (kernel 6.12) on my 14,3 Macbook Pro:

[    0.000000] DMI: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024

The apple-ibridge and apple-touchbar drivers don't work for me. There are quite a few forks of macbook12-spi-driver and I tried them all :) Right now I experiment with https://github.com/t2linux/apple-ib-drv (mbp15 branch)

initial bootup logs

[    5.750380] input: Apple Inc. iBridge as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.2/0003:05AC:8600.0001/input/input6
[    5.902236] hid-generic 0003:05AC:8600.0001: input,hidraw0: USB HID v1.01 Keyboard [Apple Inc. iBridge] on usb-0000:00:14.0-3/input2
[    5.903769] hid-generic 0003:05AC:8600.0002: hiddev0,hidraw1: USB HID v1.01 Device [Apple Inc. iBridge] on usb-0000:00:14.0-3/input3
[    5.912602] hid-sensor-hub 0003:05AC:8600.0002: hiddev0,hidraw1: USB HID v1.01 Device [Apple Inc. iBridge] on usb-0000:00:14.0-3/input3

root@macbookpro:~# modprobe apple-ibridge

Jun 21 11:47:58 macbookpro kernel: apple-ibridge-hid 0003:05AC:8600.0001: : USB HID v1.01 Keyboard [Apple Inc. iBridge] on usb-0000:00:14.0-3/input2

root@macbookpro:~# modprobe apple-touchbar
<nothing furthe gets logged>

I don't see any touchbar functionality. Anyone has an idea what is going one? There are two drivers and both cause issues:

apple-ibridge.ko

apple-ibridge.c: appleib_hid_probe() -> appleib_add_device() -> hid_add_device() for "Bridge Virtual HID 0003:05AC:8600.0001/1d6b:0301" returns error code -ENODEV and the successive cleanup in hid_destroy_device() is stuck forever.

Next, I decided to ignore the apple-ibridge.ko driver and use the apple-touchbar.ko driver directly:

apple-touchbar.ko

For it to trigger, I added the ibridge device id. Normally, the apple-touchbar.ko driver would trigger on the new virtual id created by the apple-ibridge.ko driver, only:

static const struct hid_device_id appletb_hid_ids[] = {
+       /* MacBook Pro's 2016, 2017, with T1 chip */
+       { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
+                        USB_DEVICE_ID_APPLE_IBRIDGE),
+         .driver_data = APPLETB_FEATURE_IS_T1 },

Now the probe function appletb_probe() is triggered and which calls appletb_test_and_mark_active(). This function is a kind of prerequisite for the driver to work.

	if (tb_dev->mode_iface.hdev && tb_dev->disp_iface.hdev &&
	    !tb_dev->active) {
		tb_dev->active = true;
		activated = true;
	}

tb_dev->mode_iface.hdev was previously created (true) while tb_dev->disp_iface.hdev was not (false) making this function to return false. When I force this function to return true the touchbar works!

Removing the driver crashes the kernel in applespi.ko. For now, I don't rmmod this driver. I would like to have a less hacky driver.

I wonder why am I the only one running into this problem? I see others getting this drivers to work ... but probably on other kernel versions.

Anyone knows how to proceed?

[schaecsn]

Removing the driver crashes the kernel in applespi.ko.

That was an easy fix. I hate to do that, but I just created the (n+1)th fork of the touchbar driver https://github.com/schaecsn/apple-touchbar

I hope one of the better maintained drivers will work for me on the Debian release following Trixie.

[AJ-dev-i60]

Your diagnosis is spot on — I hit the exact same things on a 14,3 and ended up fixing each of
them properly rather than with the force-true hack. (well... Claude Code fixed it)

I've got it working on kernel 7.0 (Ubuntu 26.04); the fixes should apply to your 6.12 too. Repo:
https://github.com/AJ-dev-i60/t1-touchbar (Basic = just the driver).

Mapping to what you found:

• hid_add_device() -> -ENODEV: this is the post-6.3 HID change (commit e04955db, "Recognize
  sensors with application collections") leaving the sub-device's report descriptor
  unpopulated. The fix is to restore the hid_parse_report() call in appleib_ll_parse() so the
  descriptor is parsed before hid_add_device() — then it stops returning -ENODEV.

• tb_dev->disp_iface.hdev being false / forcing appletb_test_and_mark_active() true: the T1
  genuinely has no separate display HID interface (unlike T2) — the firmware draws the row
  itself off the mode interface, so that check legitimately fails on T1. The fork special-cases
  this: appletb_test_and_mark_active() keys on (tb_dev->is_t1 || tb_dev->disp_iface.hdev), and
  the activation/SET_REPORT paths no-op the NULL disp_iface for T1. Same outcome as your hack,
  but it's the intended path rather than a forced return.

• hid_destroy_device() cleanup stuck / no logs after apple-touchbar loads: there were a couple
  of NULL-deref / sparse sub_hdevs[] issues in the teardown path; the fork guards those.
  Between the -ENODEV fix and the T1 activation path you shouldn't hit that teardown at all, but
  the guards are in regardless.

The exact delta vs t2linux/apple-ib-drv is in apple-ib-drv/t1-kernel7-fixes.applied.patch in
the repo if you'd rather apply the diff to your own tree than swap drivers.

One heads-up since you're loading by hand: on the T1, the driver runs an ACPI power-on
(ASOC.SOCW(1)) at module load that hard-freezes these machines. The fork defaults to skipping
it on T1 (DMI-gated skip_acpi_power), but if you're testing your own tree, make sure you're not
running that AML or you'll freeze.

Caveat on your setup: I've validated on kernel 7.0.0-27 / Ubuntu 26.04. The fixes cover the
6.x API changes too (the acpi .remove int->void was a 6.6 thing), so it should build on your
6.12 / Debian Trixie — but you'd be the first to confirm that exact combo, so shout if the
build differs. I also wrote up the root-cause detail over in t2linux/kernel#12.

Happy to compare patches or look at dmesg if useful.

[schaecsn]

Hello AJ-dev-i60 and Claude

Thank you for fixing the original driver https://github.com/t2linux/apple-ib-drv.

My hack skips the ibridge driver which also exposes this mysterious ambient light sensor (ASL). Curious about it, I briefly tried your driver on my laptop as well.

This is the top-comment from apple-ibridge.c

* 2016 and 2017 MacBookPro models with a Touch Bar (MacBookPro13,[23] and
* MacBookPro14,[23]) have an Apple iBridge chip (also known as T1 chip) which
* exposes the touch bar, built-in webcam (iSight), ambient light sensor, and
* Secure Enclave Processor (SEP) for TouchID. It shows up in the system as a
* USB device with 3 configurations: 'Default iBridge Interfaces', 'Default
* iBridge Interfaces(OS X)', and 'Default iBridge Interfaces(Recovery)'.
*
* In the first (default after boot) configuration, 4 usb interfaces are
* exposed: 2 related to the webcam, and 2 USB HID interfaces representing
* the touch bar and the ambient light sensor. The webcam interfaces are
* already handled by the uvcvideo driver. However, there is a problem with
* the other two interfaces: one of them contains functionality (HID reports)
* used by both the touch bar and the ALS, which is an issue because the kernel
* allows only one driver to be attached to a given device. This driver exists
* to solve this issue.
*
* This driver is implemented as a HID driver that attaches to both HID
* interfaces and in turn creates several virtual child HID devices, one for
* each top-level collection found in each interfaces report descriptor. The
* touch bar and ALS drivers then attach to these virtual HID devices, and this
* driver forwards the operations between the real and virtual devices.
*
* One important aspect of this approach is that resulting (virtual) HID
* devices look much like the HID devices found on the later MacBookPro models
* which have a T2 chip, where there are separate USB interfaces for the touch
* bar and ALS functionality, which means that the touch bar and ALS drivers
* work (mostly) the same on both types of models.

When I load the apple-ibridge.ko, the usage map is indexed with 0x00010006, only. It's never indexed with 0x00200041 and so no virtual HID is created for it.

static struct hid_device_id appleib_sub_hid_ids[] = {
        { HID_USB_DEVICE(USB_VENDOR_ID_LINUX_FOUNDATION,
                         USB_DEVICE_ID_IBRIDGE_TB) },
        { HID_USB_DEVICE(USB_VENDOR_ID_LINUX_FOUNDATION,
                         USB_DEVICE_ID_IBRIDGE_ALS) },
};

static struct {
        unsigned int usage;
        struct hid_device_id *dev_id;
} appleib_usage_map[] = {
        /* Default iBridge configuration, key inputs and mode settings */
        { 0x00010006, &appleib_sub_hid_ids[0] },
        /* OS X iBridge configuration, digitizer inputs */
        { 0x000D0005, &appleib_sub_hid_ids[0] },
        /* All iBridge configurations, display/DFR settings */
        { 0xFF120001, &appleib_sub_hid_ids[0] },
        /* All iBridge configurations, ALS */
        { 0x00200041, &appleib_sub_hid_ids[1] },

What is the deal about this ALS?

[schaecsn]

Hello AJ-dev-i60

Your repo https://github.com/AJ-dev-i60/t1-touchbar.git did not start with a fork of https://github.com/t2linux/apple-ib-drv. IMHO that's a must b/c the community trusts https://github.com/t2linux/apple-ib-drv and can easily check your commits on top of it. Your commit history is confusing, at best.

If you are willing to start with a fork, then I will update my README.md and recommend your repo over mine.

Your patch apple-ib-drv/t1-kernel7-fixes.applied.patch makes sense to me. I will continue to use my driver as I put an hour of my lifetime into it.