Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Warning: 2016 MacBook Pro is not compatible with Linux

reddit.com

Post reply on HN
Print view View original

261–270 of 285 posts

Re: Warning: 2016 MacBook Pro is not compatible with Linux

#261

Post by geocar »

userbinator wrote: post #252
geocar wrote: post #220

Earlier quoted context omitted.

> 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 "ba…

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 p…

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

Re: Warning: 2016 MacBook Pro is not compatible with Linux

#262

Post by pinkrooftop »

ominous wrote: post #248
pinkrooftop wrote: post #3

A more accurate description is that Linux isn't compatible with the new Macbook Pro. It's not Apple's job to make their laptop compatible with Linux.

It is not [insert place]'s job to respect [insert other place] ideals of liberty. It is not comedians' job to respect other's religious beliefs. It is not democracy's job to please everyone. What was your point again?

apples and oranges

Re: Warning: 2016 MacBook Pro is not compatible with Linux

#263

Post by pinkrooftop »

teto-plz wrote: post #98
pinkrooftop wrote: post #3

A more accurate description is that Linux isn't compatible with the new Macbook Pro. It's not Apple's job to make their laptop compatible with Linux.

Two things being compatible with each other is a symmetric relation, so the order doesn't matter.

logically yes, but the subtext of this usage in English adds hidden variables

Re: Warning: 2016 MacBook Pro is not compatible with Linux

#264

Post by leifliddy »

ndesaulniers wrote: post #112
mjg59 wrote: post #97

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…

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…

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

Re: Warning: 2016 MacBook Pro is not compatible with Linux

#265

Post by leifliddy »

leifliddy wrote: post #264
ndesaulniers wrote: post #112

Earlier quoted context omitted.

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…

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

Re: Warning: 2016 MacBook Pro is not compatible with Linux

#266

Post by busterarm »

colemickens wrote: post #197
busterarm wrote: post #25

Earlier quoted context omitted.

I wish I'd gotten a 2015 and put OpenBSD on it. Oh well :(

Are they out of stock, or just can't bring yourself to buy 18mo old hardware? I feel like mid-summer next year we're going to start seeing signs of a new Pixel for the Andromeda merging of Android/ChromeOS.

Prices are climbing because they're harder to get now but yes on point 2.

Re: Warning: 2016 MacBook Pro is not compatible with Linux

#267

Post by WayneBro »

emgeee wrote: post #204
userbinator wrote: post #202

Earlier quoted context omitted.

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 extensib…

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

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

Re: Warning: 2016 MacBook Pro is not compatible with Linux

#268

Post by userbinator »

geocar wrote: post #261
userbinator wrote: post #252

Earlier quoted context omitted.

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 p…

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

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.

Re: Warning: 2016 MacBook Pro is not compatible with Linux

#269

Post by mi100hael »

kyriakos wrote: post #181
mi100hael wrote: post #54

Earlier quoted context omitted.

The hardest part for me was finding a 15" PC laptop without the retarded number pad. I'm quite happy with my Dell M5510, but it was basically the only alternative to a MBP.

There's people like me who want the number pad. Also I can't live without separate home & end keys.

I have no problem with offering the numpad as an option for users who do a lot of numerical entry. I just don't want the damn thing forced on me.

Re: Warning: 2016 MacBook Pro is not compatible with Linux

#270

Post by geocar »

userbinator wrote: post #268
geocar wrote: post #261

Earlier quoted context omitted.

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

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…

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

Post reply on HN