> Apple doesn't provide Linux drivers for their components, but neither does "anyone else", sadly.

?!?!

There are vendor-provided Linux drivers for pretty much everything?

Everything in Intel and AMD CPUs are supported in mainline. nVidia provides Linux drivers.

I don't have a clear view about how many devices nowadays are reverse-engineered, and how many are provided by someone with datasheet (it happens quite often that mainline drivers are not provided by vendor directly, but by a third party that got access to datasheet), but it really feels like most vendors do work with OS vendors to get their hardware supported, and that Apple is totally an exception in the hardware world.

I am aware that for GPUs specifically, the driver situation on Linux is pretty good (minus the Nvidia/Wayland friction). But a laptop is more than just a GPU and a CPU.

When I was shopping around a few years ago, the fingerprint reader even on Dell's Linux-focused developer laptops was dead. I liked the Razer Blade, but many components didn't support Linux; looks like the trackpad on some models still doesn't work.

If "any vendor" actively supported Linux, we wouldn't need companies like Framework or system76 that pick compatible components. I'm not saying that Apple is particularly helpful, just that they're hardly alone in not caring about Linux.

Apple has requested and obtained semi-custom hardware from vendors before. Their Boradcom wireless cards (around 2006-2012 IIRC) are almost produced only for them, and getting it run on Linux was a long endeavor.

Also, like Java, they have maintained their own nVidia drivers up to a certain point.

Today that gap is smaller since HW manufacturers are more open about their firmwares and drivers, and Linux is more widely adopted.

> Apple has requested and obtained semi-custom hardware from vendors before. Their Boradcom wireless cards (around 2006-2012 IIRC) are almost produced only for them, and getting it run on Linux was a long endeavor.

I just sent in a patch series to Linux a few days ago to get all custom Broadcom cards for T2 and M1 Macs working (~2017-present), with the right firmware selection logic. Took a week or so to develop and test on both ARM64 and x86. (There was some prior art but certainly nothing that would've taken more than a few more weeks to work out from scratch; besides, I found a Broadcom source dump for Android that contained most of the interesting knowledge excluding the Apple-only bits, since some of it is relevant to newer non-Apple chips too).

Once you have a team of the right people and enough motivation, getting reverse engineered hardware working on Linux doesn't take as long as everyone thinks :-)

I remember many people have bruised themselves by banging their heads to their peripherals and desks while trying to reverse these BCM chips and trying to make them work with Linux, however back in the day BCM was hostile towards Linux, and NDIS_wrapper was a thing...

OTOH, kudos for all the hard work you're doing on the kernel. Maybe one day I'd have enough spare time to work on that marvelous beast.

> Once you have a team of the right people and enough motivation, getting reverse engineered hardware working on Linux doesn't take as long as everyone thinks :-)

As long as the hardware (or the vendor) is not intentionally malicious towards Linux or being reverse engineered. I've seen my fair share. :-)

> I remember many people have bruised themselves by banging their heads to their peripherals and desks while trying to reverse these BCM chips and trying to make them work with Linux, however back in the day BCM was hostile towards Linux, and NDIS_wrapper was a thing...

The b43 days were definitely special, and that was a full from scratch reverse engineered driver plus open firmware, which is a crazy accomplishment. These days though, we just accept that we're going to have to run vendor firmware, either because there's signing involved or because it's a huge amount of work to attempt to reverse engineer and reimplement that bit. Firmwares have grown from dozens of kilobytes to megabytes and it's just not viable to rewrite all that any more, if it's even possible.

OTOH, we also have better tools for and experience reverse engineering now than we did back then. Ghidra has made "proper" disassembly and decompilation accessible to anyone, and we can run proprietary OSes in VMs to study how they interact with hardware.

> As long as the hardware (or the vendor) is not intentionally malicious towards Linux or being reverse engineered. I've seen my fair share. :-)

Well, it doesn't happen that often outside of closed platforms (i.e. needing an exploit to do anything) and Nvidia ;-)

Apple still maintains their own Java internally. Very minor tweaks and with their own CA since they self sign certain internally starting 2-3 years ago.

But the packages are still distributed by ORACLE, right?

Not the internal Java. That’s not for customers. That’s for apples internal servers.

AMD and Intel provide drivers for their components. Realtek provides drivers for their components. Even Nvidia provides Linux drivers for their components, in proprietary form. Several laptop vendors even sell their hardware with Linux preinstalled.

Apple not actively hindering Asahi Linux isn't exactly a great accomplishment. They chose not to write Linux drivers for their platform and that's their choice, but that puts them behind even Nvidia as far as supporting Linux goes.

FWIW, Nvidia actively sabotaged the Nouveau project with the firmware signing story; Apple aren't doing that (their firmware is signed but loaded pre-boot and they provide OS images we can use to set all that up, so it's seamless for Linux).

Great progress on Asahi. What's the firmware situation like in general ? Since firmware won't be redistributable, would users need to periodically 'fetch' it from Apple CDNs or OS images ? Also, in the past broadcom has been quite problematic for wifi. How is it on the new macs ?

There's two classes of firmware: the bits loaded pre OS boot by the OS loader (which runs before our Linux loader), and the bits loaded by Linux. Both classes come from macOS recovery images and our installer takes care of fetching that from Apple's CDN. For the pre-boot firmware, it just gets installed into the Preboot partition the same way it does for macOS, and we don't have to worry about it after that. For the firmware loaded by Linux (current list: WiFi, video decoder), I have a design for a vendor firmware mechanism where the installer copies a tarball to the EFI boot partition, and then distros will have a script that extracts that on first boot or when it changes.

Since Apple do not keep their firmware ABI stable across the board, we'll have specific firmware versions (=specific macOS versions they come from) "blessed" for Linux compatibility. For updates (bugfixes or security issues, chiefly) you'd re-run our installer which will eventually have an "upgrade my firmware please" mode. That would run from recovery mode, same as the original install. All this stuff is per-OS, so it does not affect any adjacent macOS install which will use its own firmware - you can upgrade macOS whenever you want without breaking Linux.

Wifi works fine (modulo some firmware support details that'll get ironed out); people have been doing performance and stability tests and there is no major issue. I've heard stories about bad radio performance on Macs in the past, but those are almost certainly due to using the wrong firmware or config. That's what my patch set fixes: we use all the same firmwares and configs that Apple does, so we get the same results.

> AMD and Intel provide drivers for their components.

ATI/AMD intentionally redesigned their GPU silicon to make it's possible to develop open source drivers without exposing HDCP secrets, and even the open source drivers can use HDCP if they want to.

This is not known very widely, but this is worthy of great praise if you ask me.

I don't think any GPU vendor has ever had HDCP secrets exposed to the OS. That'd be terrible security; you'd need mandatory OS secure boot to keep the keys secret. This is the case for Nvidia, for Apple M1s, etc; the OS never has to touch plaintext HDCP keys, and this has nothing to do with open source drivers.

Can you clarify what you mean exactly? I have a hard time believing AMD ever ran HDCP keys through the Windows kernel.

> I don't think any GPU vendor has ever had HDCP secrets exposed to the OS. That'd be terrible security; you'd need mandatory OS secure boot to keep the keys secret.

Yes, I'd not argue with that, I also never wanted or implied that I shall be able to get said keys from the card.

AMD/ATI back in the day said that, they have intentionally coupled video decoders, related logic and HDCP to same IP block for performance and silicon real-estate reasons, but in order to keep their promises about open drivers and accessible hardware, starting with (then) next generation silicon, they'll move all HDCP stuff to another IP. In turn, they will allow unfettered access to all GPU including 3D and video related features sans HDCP. However, with that architecture, even open drivers can use HDCP related hardware and functions without compromising the security and licensing around it, as a result allowing identical experience and freedom (from a developer standpoint) regardless of the driver used.

This is something to praise for, IMHO.

I still don't really understand how this is relevant for the drivers. Even if HDCP is part of another IP block, that doesn't mean open drivers can't use it. That's just an implementation detail. You can use HDCP on any platform the same way the proprietary drivers would (if you implement the right knobs to control it). Do you have a reference with more detail?

Ultimately the open driver should always be able to do all the same things the closed driver does and get the same result. If there are any secrets in the closed driver that "can't" be exposed, that's a security flaw in the design.

In their previous setup, as per their word, it was impossible to access video decoders and related machinery without exposing some HDCP stuff, incl. the key related storage and other secret stuff.

So, they were unable to provide the access they wanted to provide (for video decoders, at least), on the previous (then current) architecture.

That's... very weird. What would that expose? If you can read the keys at all from the OS, directly or indirectly, that's a security flaw. AFAIK AMD GPUs have supported video decode on Linux across all generations, so what was unavailable?

Considering the history of ATI with video, and how they enabled GL shaders to work with video acceleration, post processing and effects before anyone was able to dream this thing (Readeon 8500 was able to use shaders to post-process and apply effects to the video), I think their silicon layout was very convoluted and unconventional for today's standards.

Considering HDCP came later, it might have just been slapped as a side module and some of their math magic might be offloaded to GPU even. I remember having old ATI drivers having a very cinematic look when video was accelerated by the GPU itself (it was surreally beautiful), but they had to throw all this machinery out from the driver when they started to modernize their stack (and they broke video playback for months due to not supporting proper overlay formats).

Similarly, I think closed source drivers were programming some of the cards during initialization, because I remember they're talking about moving all this init step to the BIOS itself, and opening some doors on the BIOS to tweak the card during the init (clocks, fans, temp reads, etc. IIRC) for allowing OS and open drivers to play nicer and with less effort with the cards in the long run.

The details are hazy, because these transitions were made almost a decade ago if not longer. However, while NVIDIA was playing the deaf, and Intel was just starting to provide good open drivers for their IGPs, AMDs move as a prime GPU vendor brought a lot of good light to them.

If you want, I can try to dig the history and create a timeline for you, but it might not be an immediate endeavor.

Oh, I know that AMD has done a lot to help out the open ecosystem (and even interop with the closed parts - heck, I got their closed AMDGPU-PRO Linux drivers to work on the PS4 without any patches, even though that's not a GPU variant offered elsewhere, because the amdgpu userspace/kernel interface is just so well designed). I recommend AMD for Linux users; lately, they've been doing good work while Intel drivers bitrot, especially on older hardware.

I'm just quite confused as to how HDCP factors into all that. HDCP really is just a hardware block that's part of the video output which you enable or disable; there is a bunch of nonsense associated with PAVP and other such stuff on Windows, but none of that should really matter to Linux, nor should whatever way HDCP is implemented affect other features of the open drivers. AMD certainly do deserve credit for their work on Linux support, I just find your specific HDCP story quite strange :-)

But it is not all about GPUs. Broadcom is notoriously bad on many items and is used a lot for wifi and BLE and webcams, as is that touch pad vendor whose name I forgot that is in many laptops.

I installed Linux on a 2015 MBP recently and there is no real way to get the webcam working.

I'd agree if we were talking about desktop machines, which are basically a box around a GPU, CPU, and some networking. The situation there is infinitely better than on the M1 Mac Mini.

But if I go and buy a random Windows _laptop_ and try to slap Linux on it, I might have all sorts of issues with the trackpad, webcam, fingerprint sensors, never mind sleep/wake.

That's why Linux laptop vendors are a thing and deserve our praise (just like the companies you've mentioned)! All I'm saying is that Apple is hardly the only company left that doesn't actively support Linux.

People unfamiliar with computer history beyond the past decade are downvoting you.

Apple may not contribute much more than a bare platform with M1, but that isn't unusual in the scope of computer history. What's important is that they are not actively enforcing exclusivity or deterring the attempt. They've even shown tacit support in recent EFI patches by making changes that preserve the current mechanism other OSes can be loaded.