Hacker News new | past | comments | ask | show | jobs | submit login

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




The input devices are on SPI, not USB

Things like this make me wonder if Apple is deliberately going for proprietariness as a sort of vendor-lock-in, because I can't see any other compelling reasons for coming up with a completely different interface for such basic and existing devices. USB and PS/2 are standardised to the point that hardware and software for them are widely available and cheap. They're also extensible, so one does not have to reinvent everything to add additional features.

I still remember when the first "Intel Macbooks" came out with nearly identical hardware to a PC laptop of the same era, i.e. keyboard and trackpad looked like standard PS/2 devices. Later models of PCs and Macs started using USB internally (which is in some ways more complex, since the existing PS/2 interface was provided by the EC via LPC whereas USB may require an additional controller and definitely requires routing additional signals between it and one of the USB ports on the chipset), but at least they would still work relatively standardly.

Personally, I'm all for new features but implemented in backwards-compatible or relatively standard ways. Apple doesn't seem to be a fan of that.


> I can't see any other compelling reasons for coming up with a completely different interface for such basic and existing devices.

I don't know enough about the implementation to speak to why they made this choice, but for what it's worth, SPI is a standard[1] - and a quite old one. I suspect, were we to follow this down the rabbit hole, that we'd find it's related to power management.

1. https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bu...


That well may be (regarding the power management), but while SPI as standard is old, the use of SPI is not standard. I've implemented quite a few SPIs (mostly FPGA) to interface with various commercial devices and virtually all of them had a different protocol, i.e. 8bit vs 7bit words, different bits to denote write or read, etc. Some of them didn't even use SS signal. I wouldn't really called them standard, and I say that with regret. More hardware could be used in a more standard manner.


that's a good guess. I would agree. SPI is not connection-oriented and "comes up and goes down" (to the extent that it goes up and comes down at all) very fast with very little active memory needed to support the communication.


Neither is PS/2, which also being a synchronous serial interface with very low overhead, does share many characteristics with SPI at the physical layer:

https://en.wikipedia.org/wiki/PS/2_port#Legacy_port_status_a...

The PS/2 interface saves power due to its interrupt-driven nature compared to USB which requires periodic polling, so it is a popular interface for laptops' internal keyboards and pointing devices

The major difference is that PS/2 is a de-facto standard up to the application layer/software interface, while the MacBook SPI protocol is unique to Apple.


PS/2 isn't high enough bandwidth to support decent multitouch, which is why most modern PC touchpads come up in PS/2 mode and then transition to SPI.


You are right that SPI is a standard, although like RS232 it only exists in hardware and data layers, while USB is up to application layer.

You argument in this case is very similar to defending use of custom TCP protocol for web browsing. While TCP is standard, there is nothing standard about it to browse the web, we have HTTP for that


Apple were already using USB for the PPC iBooks, and continued that with the Macbook - Linux has always complained that it can't find a PS/2 controller on x86 Apples. But USB is poor from a power management perspective, and so input devices on low power systems are frequently run over SPI instead. Apple began this with the Macbook (which is basically a tablet shaped like a laptop) and have started extending it across their entire mobile range. There are entirely sound reasons for doing this, and it's not unique to Apple.


My Acer Cloudbook trackpad is I2C, a similar simple bus. It can be configured in BIOS to fallback to PS/2 with reduced capabilities.

PS/2 is too slow for the volume of data coming out of a modern touchpad. USB is a lot more hardware, though that is small in the context of a CPU. It may just be that with I2C running around the motherboard for all the miscellaneous devices it just makes sense to use that.


Just an FYI SPI is a pretty standard interface in the embedded world


True, but SPI is really just referring to the physical layer protocol while the layers above can vary considerably and be proprietary. The only thing that's constant is that it is a synchronous serial protocol.

It's not like USB which defines device classes and the higher-level layers of the stack, or PS/2 where e.g. all PS/2 keyboards or mice are expected to have an identical basic set of functionality and behaviour. There are certainly proprietary "vendor-specific" extensions to those, but e.g. it's almost a given that if you plug in a USB keyboard, all the standard QWERTY keys should work effortlessly; and while there may be extensions like displays and touchbars that require specific drivers, the core functionality doesn't change.

If I understand correctly, what Apple did here is invent their own protocol for the keyboard which is completely different from what any PC or earlier Macs have, thus the lack of any functionality from Linux. And given how crucial a keyboard is to being able to do anything with the computer, it's no wonder this has caused much consternation.

I think many people are used to the idea that even if the OS does not provide drivers for specific devices, basic functionality like keyboard, mouse, and video (even if it's something like a VGA 640x480 16 colours mode) should still be present --- partly to enable "bootstrapping" into more functionality by installing and troubleshooting the drivers.


> I think many people are used to the idea that even if the OS does not provide drivers for specific devices, basic functionality like keyboard, mouse, and video (even if it's something like a VGA 640x480 16 colours mode) should still be present --- partly to enable "bootstrapping" into more functionality by installing and troubleshooting the drivers.

Then I think people need to step back and appreciate that this "basic functionality" is actually really expensive in terms of price, space, power and performance.

Would they really pay more for Apple hardware if it booted up with a full internal USB or a PS/2?

What if it made the laptop heavier? Shortened the battery life? These things are very important to me: I wouldn't buy a heavier Mac.

Could this be mitigated with custom ASICs? Or a new power switch and some extra power controllers (e.g. a soft switch to turn off the fallback 8042 and start using the faster more sensible SPI interface)? Perhaps, but someone has to pay for it.

Moaning about things that don't make sense to change -- that someone just doesn't like, just makes that someone unhappy.


Could this be mitigated with custom ASICs? Or a new power switch and some extra power controllers (e.g. a soft switch to turn off the fallback 8042 and start using the faster more sensible SPI interface)? Perhaps, but someone has to pay for it.

PS/2 has not been implemented with a real 8042 for a very long time. Standard laptop ECs which are cheap and widely available have optimised dedicated hardware to handle the protocol. Speed is not a problem either, because this doesn't need to be a physical PS/2 interface with a separate keyboard on the end of it --- in the designs I've seen, the EC scans the key matrix itself and just provides a PS/2 software interface. It really doesn't matter what the physical interface on a laptop is, since the software interface is what's important here; Apple could've used something similar to PS/2 but increased the clock rate to whatever they needed, and it'd still look the same and be compatible to existing software.

USB is not a good idea from a power perspective since it is a polled bus and there's plenty of additional unneeded complexity throughout the whole stack, but PS/2 is interrupt-driven and extremely low-power.

In fact, it is a synchronous serial protocol just like SPI, so what appears to have happened with these MacBooks is that Apple basically reinvented PS/2 in their own "Think Different" way.


> Apple could've used something similar to PS/2 but increased the clock rate to whatever they needed, and it'd still look the same and be compatible to existing software.

If you deliver a byte per interrupt to be compatible with PS/2 then your system has to wake up more frequently than a DMA/SPI interface.

> USB … is a polled bus

> PS/2 is interrupt-driven and low-power enough for me.

This is wrong.

USB and PS/2 both deliver an interrupt when there is data available.

USB can be configured to directly store the data in memory, so that in the ISR the operating system simply scans memory.

PS/2 on the other hand has to be polled inside the ISR, whether there is data available or not. Not a problem for a keyboard, but touchpads send a lot of data (of course, this is why everyone uses SPI for touchpads)

> It really doesn't matter what the physical interface on a laptop is, since the software interface is what's important here

This is a common, but fundamental misunderstanding of how software and hardware work.

Hardware is not mere programmable matter, it has wires and current, and those wires take up space, and that current draws down your battery.

A lot of laptop vendors have to include "compatibility chips" that take up space and draw down battery because they don't control the software, but if they did control the software they could make their users happier.


If you deliver a byte per interrupt to be compatible with PS/2 then your system has to wake up more frequently than a DMA/SPI interface.

Nothing says Apple couldn't just add DMA capabilities to a PS/2 controller, sort of like how bus-master IDE works.

USB can be configured to directly store the data in memory, so that in the ISR the operating system simply scans memory.

That's just DMA, but the USB controller itself has to physically poll the bus. (Excepting some features in USB 3.x, which I don't think I've seen any use of currently for keyboards or mouses.)

PS/2 on the other hand has to be polled inside the ISR, whether there is data available or not. Not a problem for a keyboard, but touchpads send a lot of data (of course, this is why everyone uses SPI for touchpads)

If I remember correctly, the polling is only necessary for writing commands to the controller+device, and not the usual reading of data. There are plenty of touchpads that use PS/2 as well, and they usually appear to be mouses until switched to a different protocol mode.

A lot of laptop vendors have to include "compatibility chips" that take up space and draw down battery because they don't control the software, but if they did control the software they could make their users happier.

"compatibility chips" - such as?

Hardware is not mere programmable matter, it has wires and current, and those wires take up space, and that current draws down your battery.

The amount of processing required for a USB stack is far greater than for PS/2 and presumably Apple's custom SPI solution. I think the main point to take away from all this discussion is that although Apple could've taken an existing widespread and compatible interface with similar characteristics and enhanced it to fit their requirements, they didn't.

...and that obviously many users here are not "happier" because of it, but Apple doesn't care.


> Nothing says Apple couldn't just add DMA capabilities to a PS/2 controller, sort of like how bus-master IDE works.

Except cost.

> That's just DMA, but the USB controller itself has to physically poll the bus.

Who cares? The USB controller requires a fraction of the power that the CPU does.

If I have to choose between a microcontroller polling for "interrupt endpoints" and the CPU, you know what I'm going to choose.

> If I remember correctly, the polling is only necessary for writing commands to the controller+device, and not the usual reading of data.

No. You must wait for inb(0x64) & 1 before reading from 0x60. Note this dance is actually quite long:

http://lxr.free-electrons.com/source/drivers/input/serio/i80...

It's probably okay for a keyboard and a low-resolution mouse. Maybe. It's definitely not okay for a touchpad.

> There are plenty of touchpads that use PS/2 as well, and they usually appear to be mouses until switched to a different protocol mode.

With extra chips.

I think the main point to take away from all this discussion is that although Apple could've taken an existing widespread and compatible interface with similar characteristics and enhanced it to fit their requirements, they didn't because it was more expensive.

FTFA.

You might think some people want Apple laptops to be hacker friendly, and you might be right, but my point is that you should consider that some people would rather they be cheaper and lighter and more power efficient.


You must wait for inb(0x64) & 1 before reading from 0x60.

The code clearly shows that all the ISR does is read from the status port, and if there is data available, read it from the data port. It only does nothing in the unlikely case that no data is available (could be a spurious interrupt.) I have written code like this before. There is no waiting, no polling. Receive an interrupt, read a byte. Some devices will actually let you read multiple bytes (just keep reading until one of the bits in the status register goes off.)

You're claiming it would significantly increase cost to enhance an existing interface (as opposed to redesigning everything and the nontrivial NRE of that?), on a laptop that itself costs far more than the majority of others using a standard or slightly enhanced standard interface.


>In fact, it is a synchronous serial protocol just like SPI, so what appears to have happened with these MacBooks is that Apple basically reinvented PS/2 in their own "Think Different" way.

Ugh. Almost everybody uses SPI for touchpads these days, although they frequently also provide a PS/2 compatibility mode. Apple don't care about working with stock operating systems other than their own (the Bootcamp installer injects additional drivers for Windows), so they decided not to bother.


Wheels are pretty standard on cars too. Shouldn't every computer have wheels?


I imagine it's more that they don't care and SPI is simpler/cheaper than USB when you custom make your hardware.


I don't necessarily think Apple cost minimizes in that way. They build and engineer in ways other companies cannot or won't risk. My example being their 10k cnc machine purchase for MacBook cases. Or I could be totally wrong and this is what they're doing, of course.


PPC Mac laptops used ADB as an internal protocol for many years after no Apple computer shipped with external ADB ports.

My recollection was that the transition to using USB as an internal protocol came slightly before the PPC->Intel transition, and that the first several generations of X86 Mac laptops used USB internally for trackpads and keyboards. You sure there were ever any using PS/2? Seems unlikely.


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


1.) It is __le16 with an L, not __1e16, and it means that it is a little endian field for bitflags, the tooling makes sure it is properly handled (not mixed with numbers or fields in the wrong endianess). See this Stack Overflow post and especially the links in the accepted answer: https://stackoverflow.com/questions/9680399/what-does-typede...


it's not 1e6, it's le16

Little endian 16 bit

As for the driver itself, the spi interfaces are not too hard to understand. It's unlikely anyone is disassembling anything.

The normal way to figure out the packets the touchpad uses are to look at the datasheets/etc you can find on whoever made the touchpad.

In this case, it's a bcm5974, and if you look at that driver, you'll see the packet format is the same.

Otherwise, you write a packet dumper and start pushing things


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


The author details here what he did to debug the windows spi driver: https://bugzilla.kernel.org/show_bug.cgi?id=108331#c51


"As an aside, for anyone interested in helping reverse engineer things: It's possible to get Windows to dump everything it sends on what it calls SPB - basically SPI & I2C. Open the Event Viewer and enable View -> Show Analytic and Debug Logs. Then head to Application and Services Logs -> Microsoft -> Windows -> SPB-ClassExtension. Right click on Analytic and enable it - all events will be logged. Disable it when done, and look for the 1023 events, and view the details tab - they'll give you the full buffer contents. Other events will let you know things like the direction of the transfer, etc."


Actually, (2) has been fixed for the 2015 Macbook, I suppose that can help for the Macbook Pro. We have been trying to fix the SPI issue for a while, see this[0]

As I've posted before, I am so happy now the Macbook Pro is out because we desperately need help on this issue.

[0] https://bugzilla.kernel.org/show_bug.cgi?id=108331


Tangential Question: Would you say that Thinkpads are still the safest bet if you're looking for good RHEL/Fedora support & updates?


For the Thinkpads, yes. Lenovo is one of the companies that maintains a list such as this: https://support.lenovo.com/us/en/documents/pd031426 (This is a list of computers that they have certified one or more Linux distros against -- typically RHEL and Ubuntu).

Any of the problems that you usually hear are typically on their non-Thinkpad lines.


Unfortunately, currently that supported machines list is empty!


It isn't when I bring it up -- I wonder if there is a javascript issue that is causing a problem (such as with noscript, or an adblocker?) I'm seeing about 25 pages of systems. For current systems, I'm seeing the T460, T460p (with Ubuntu 14.04), and T460s with both Ubuntu and RHEL 7.2. Also seeing the X1 carbon, and X1 carbon yoga with Ubuntu certification.

For the X260, for example, it has these links: https://access.redhat.com/ecosystem/hardware/2199571 http://www.ubuntu.com/certification/hardware/201511-20298/


I'm also seeing the full page now. I do use an adblocker in Firefox but not in Chrome and the page looked the same in both browsers.

Thank you!


Ish, but if you're considering something ultrabookish then the Dell XPS range has the most people working on it. Probably better sticking with Thinkpads if RHEL is a hard requirement.


XPS 13 and 15 (or the equivalent Precision series) No question about it. Lenovo has hardware whitelists and has frequently broken Linux compatibility with its BIOS.


>* frequently broken Linux compatibility with its BIOS.*

No, not on Thinkpads.


7 years on the Dell Precision line with Fedora, amazing machines.

Fedora, given its leading edge nature, will have better hardware support than RHEL as the latest firmware will always come first to the former.


A lot of Red Hat employees (and engineers) use them. At least some of the models are very well supported.



Those aren't ThinkPads.

The ThinkPads are an semi-independent division within Lenovo.


I wonder if _OSI(Darwin) has to do with it




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: