cb22

macbook12-spi-driver

C2016–2020

cb22 / macbook12-spi-driver

macbook12-spi-driver

WIP input driver for the SPI touchpad / keyboard found in the 12" MacBook (MacBook8,1 + MacBook9,1)

Explore on GitHub Read Hacker News discussions

4Distinct people

7Mentions

0Explicit recommenders

329GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

WIP input driver for the SPI touchpad / keyboard found in the 12" MacBook (MacBook8,1 + MacBook9,1)

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year7 dated mentions

Observed mentions: 2016-11-10 23:03:47 UTC to 2020-04-26 04:34:27 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	3	3
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	2	2
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	2	2

What Hacker News says

7 sources

Dunedan·Apr 26, 2020

> I envy your knowledge and ambition. What you've done is beyond my capabilities. I mostly did just coordination and verification. The only code I contributed are very small workarounds for the NVMe controller and webcam. Nothing noteworthy. The serious work of reverse engineering and implementing custom drivers was done by others which are to be applauded much more! There is one person I want to point out in particular and that's roadrunner2 [1] who took the existing input driver for the 12" Retina MacBook and not just made it work with the MacBook Pro's, but also implemented support for the TouchBar and ambient light sensor. As this driver is based solely on reverse-engineered workings of the input system and Apple does very unique stuff there this was so much effort. Including very subtle, but surprising bugs (e.g. [2]) which could've

Read the rest

easily avoided if documentation would've been available. roadrunner2 is also the one to applaud for bringing the support for keyboard and touchpad to mainline Linux. As that not just required an input driver, but also touched other subsystems and required serious refactorings that was quite an achievement as well and is the reason keyboard and touchpad even work out of the box after booting a Linux distribution nowadays (although it's still not perfect as some distributions don't enable the applespi driver yet). [1]: https://github.com/roadrunner2/macbook12-spi-driver [2]: https://github.com/cb22/macbook12-spi-driver/issues/53

In Install Ubuntu 20.04 LTS on MacBookPro14,1

cb22·Apr 12, 2020

> I'm not saying that people don't use Linux on laptops by the way, I meant that the overlap between people who run Linux and use a MBP isn't very large (because Linux on Apple can be anything from annoying to install to near impossible). Maybe I'm in the tiny minority here, but I much prefer the way touchpad handling on Linux behaves compared to both Windows and macOS. At least on sway, it feels more 'accurate' than either of those two - you move your finger and the cursor actually goes to where you want it. > But, as far as I know, Apple still releases the source code for Darwin, right? So shouldn't it be possible to port the trackpad functionality from there? Unfortunately not! I worked on reverse engineering a driver for the SPI touchpad found in newer (but not too new) Macbooks and based most of it on packet captures from Windows' Ev

Read the rest

ent Log [1] [1] https://github.com/cb22/macbook12-spi-driver/issues/3#issuec...

In Bored? How about trying a Linux speed run?

Dunedan·Nov 11, 2017

> Can I install Debian on it and have stuff working? Depends on the kind of Mac you buy. I can only comment on their mobile offerings: - Best supported are the current MacBook Airs. Everything except the Webcam should work out-of-the-box. The webcam needs the out-of-tree bcwc_pcie driver (https://github.com/patjak/bcwc_pcie)). - The Retina MacBooks need some manual work before being usable (e.g. need to compile out-of-tree keyboard & touchpad driver (https://github.com/cb22/macbook12-spi-driver)), but should work fine as well. - The MacBook Pros before October 2016 are also quite good supported, the support for newer ones is still quite incomplete (check out https://github.com/Dunedan/mbp-2016-linux for details), although it's possible to use them as daily driver if you're aware of the limitations.

In “We have obtained fully functional JTAG for Intel CSME via USB DCI”

Dunedan·Sep 18, 2017

> Apple just doesn't seem to care about build quality beyond the cosmetics of their Mac lineup. A great example of this is how they have dual connections from the keyboard & trackpad to the mainboard (USB and SPI), while the UEFI and Linux have drivers to support the keyboard fully, macOS has no driver for the built-in USB connection. Well, it's complicated. In the past mobile Macs used USB to connect the input devices like most other notebooks do. At a certain point Apple decided that it would be a good idea to switch to SPI for power consumption reasons. Following that decision there were certain models which had wired both, e.g. the MacBook Pro 2015. While Apple switched already to use SPI there, Linux still used USB, as there was simply no driver support. The Retina MacBook in 2015 was the first mobile Mac which didn't support USB for

Read the rest

input devices anymore. The MacBook Pro followed in late 2016. That left Linux without a working driver for the input devices. A year ago somebody started to reverse engineer the SPI protocol to get a working driver: https://github.com/cb22/macbook12-spi-driver/ The release of the SPI-only MacBook Pros end of last year sparked the further development of this driver, so it's slowly reaching a state were everything is just working (maybe except for advanced Touchpad features). That driver is still not included in any major Linux distribution, as it's still pretty experimental and also required patching the Linux kernel for quite some time, because Apple does some ACPI-related stuff different than the PC-world. Thankfully support for Apples way will land in the upcoming Linux 4.14 (https://github.com/torvalds/linux/commit/53ac64aac9af8cd0e54...) making some code in the driver redundant (https://github.com/cb22/macbook12-spi-driver/pull/46). So I would say that whole topic isn't about not to care about build quality, but about to care about power consumption. Still having USB on some generations of Macs in addition to SPI was probably simply to ease the migration by unbundling the hardware changes from the software changes.

In Thinkpad X62

ndesaulniers·Nov 11, 2016

ah, there's also an interesting discussion in an GH issue. They reference the data sheets of the parts mentioned from an iFixit teardown. There's also discussion of disassembling the OSX driver. And here's info on how the author sniffed SPI traffic on Windows. [1] [0] https://github.com/cb22/macbook12-spi-driver/pull/1#issuecom... [1] https://github.com/cb22/macbook12-spi-driver/issues/3#issuec...

In Warning: 2016 MacBook Pro is not compatible with Linux

ndesaulniers·Nov 10, 2016

Thanks for the link to the WIP driver. Since you have a lot of experience in this area, I'm curious: 1. What's the __1e6 alignment? [0] I've never heard of that. 2. How is the driver author going about writing that driver? Some of the comments seem to allude to analyzing what the Windows driver is doing. Do you think they're disassembling the Windows driver and trying to re-implement a Linux compatible driver in C? I don't see how anyone could implement a driver like this off the bat without some data sheet or existing code to look at. Edit: thanks to people pointing out it's __le16, not __1e6. I need to change my font; even now I can barely tell the 1 and l apart. [0] https://github.com/cb22/macbook12-spi-driver/blob/master/app...

In Warning: 2016 MacBook Pro is not compatible with Linux

mjg59·Nov 10, 2016

The three primary issues here are: 1) The input devices are on SPI, not USB. Apple's ACPI tables don't provide the GPIO mappings for these things via the standard mechanisms, so the chipset driver won't bind. You then still need another driver for the SPI controller, and there's an out of tree one at https://github.com/cb22/macbook12-spi-driver/ . Longer term, the kernel needs to be able to parse Apple's ACPI tables and that driver needs merging. 2) Apple's NVME hardware uses the wrong PCI device class, possibly because it's not entirely NVME compatible (trying to read 64 bits of mmio register space in one go will fail, for instance). Linux has a specific entry for the older Apple NVME devices, and that may need to be broadened. 3) Having source ID checking enabled when doing IRQ remapping results in the system hanging on boot. It's uncle

Read the rest

ar what the underlying problem is. Windows works fine because Apple provide drivers for (1) and (2). (3) is unclear - Windows may be setting up interrupt remapping differently, or it may never enable source ID verification. These issues are far from unusual when dealing with Apple hardware ((1) was true for the new Macbook, (2) has been true since Apple introduced NVME, (3) is the kind of weirdness that we've seen on Apple hardware ever since they went Intel), and this particular set of breakage is unsurprising. I spend some time while I was at Red Hat trying to keep Apple hardware working (https://mjg59.dreamwidth.org/12037.html is an example of what we had to do), but I don't know that anybody's really working terribly hard on it these days.

In Warning: 2016 MacBook Pro is not compatible with Linux