The Asahi Linux project announced on August 26, 2026, that official support for the entire M3 Mac lineup is nearly complete — a milestone that will give millions of MacBook Pro, MacBook Air, and iMac owners running Apple’s 2023 chip generation their first opportunity to install a community-developed Linux operating system on bare metal, without virtualization. In the same report, the team confirmed that early bring-up work on M4 and M5 systems has already begun — a pace that, if sustained, would represent the fastest generation-over-generation expansion in the project’s six-year history.

The report, published by developer James Calligeros and covering progress made in the Linux 7.2 kernel cycle, details how the team solved the final hardware problems standing between M3 Macs and a full Linux installation. That answer has always been the same: reverse-engineering each undocumented Apple hardware block until a driver can be written for it. Apple does not publish technical specifications for its Mac hardware, leaving community developers to decode proprietary protocols by watching what the hardware does and inferring what it expects.

Why M3 Required a Fresh Round of Driver Work

Every Apple Silicon generation arrives with hardware changes that break drivers written for the previous one. The M3 lineup, which Apple shipped starting in late 2023 as the foundation of its refreshed MacBook Pro, MacBook Air, and iMac, was no exception.

The most significant change for Linux support purposes was Apple’s decision to replace the USB-C port controller used on M1 through base M3 machines — a Texas Instruments chip called the CD3217 (also referred to internally as ACE2) — with a new component called ACE3 on M3 Pro and M3 Max models. The difference matters because the two chips sit on different communication buses. ACE2 communicated over I2C, a well-understood serial bus the team already had drivers for. ACE3 uses SPMI — the System Power Management Interface — a different bus standard that required separate reverse-engineering work before Linux could talk to it at all.

Developers mildsunrise and chaos_princess determined that ACE3’s register layout is essentially identical to ACE2’s — the same logic wrapped in a different interface. Once SPMI support was in place, USB 3.0 and Thunderbolt began working across every M3 Mac model.

The M3 audio hardware required a different kind of fix. Apple introduced what the team calls a “High Frequency” decimator for the M3 generation — an audio signal-processing stage that requires a new set of filtering coefficients and a larger initialization sequence than the equivalent hardware on M1 and M2. Without the correct coefficients, the microphone driver loads but produces garbage data. chaos_princess completed the reverse-engineering for M3 audio, and built-in microphones now work on all M3 Macs that have them.

Webcam support took a simpler path. The image signal processor hardware changed little from earlier generations; the M3 Max model simply skipped one initialization message that the driver did not expect to be missing. Adding support for the skipped message completed webcam functionality across the M3 lineup.

Display support is described as “almost at feature parity” with M1 and M2 systems. The team targets a specific version of Apple’s macOS firmware for each hardware generation — M3 machines target the display controller interface found in macOS 14.8.3 — and progress toward full parity is nearly complete. An official M3 release is expected in the coming weeks.

Hardware Video Decoding Reaches the Desktop

One of the less visible but practically important achievements in this cycle is hardware-accelerated video decoding via Apple’s Video Decoder block, known internally as AVD. Developer sofus refined AVD support to the point where H.264 (AVC), H.265 (HEVC), and VP9 decoding now work reliably on all Asahi-supported machines, with AV1 decoding available on M3 and newer hardware additionally.

The challenge is getting mainstream desktop software to actually use it. AVD is a stateless decoder — it converts an encoded video frame into raw pixel data and does nothing else. That architecture maps naturally to the Linux kernel’s V4L2 Stateless API, but most desktop software including web browsers has historically used VA-API instead of V4L2, the interface that AMD and Intel support on their hardware.

To bridge the gap, sofus forked a VA-API-to-V4L2 Stateless translation layer originally written by hardware accelerator specialist Bootlin, which had been abandoned and no longer compiled without patches. With the translation layer installed and an environment variable configured, VA-API applications can use AVD for hardware-accelerated video decoding on Apple Silicon. The solution does not yet ship by default in Fedora Asahi Remix and does not work with Firefox’s sandboxed video decoder, but the team says a shippable configuration is close.

The team is also working toward “direct scanout” — a pipeline in which decoded video frames travel directly from the hardware decoder to the display controller, bypassing GPU memory entirely. On macOS, this allows the GPU to power down completely during video playback, with the display controller simply displaying frames as the decoder produces them. Making direct scanout work on Linux requires that the decoder and display controller agree on a shared framebuffer format. Apple’s hardware uses a format called Interchange that is supported by both the display controller and video decoder; Asahi developers have wired Interchange support into both the display controller driver and the Mesa graphics stack.

The final piece — getting the KDE Plasma compositor (KWin) to take advantage of it — has not arrived yet. KWin currently treats Apple’s GPU and display controller as separate hardware blocks, which triggers a code path that disables the DMA buffer sharing API used for direct scanout. KWin developers are working on a fix that could ship in Plasma 6.8.

What Does It Mean to Run Linux Without EL3?

Beyond the M3 hardware milestones, the most structurally significant development in the Linux 7.2 cycle may have gone unnoticed by users focused on the installer release: Asahi developer Sven Peter submitted a Request for Comments patch to the Linux kernel mailing list that could, if accepted, open the door to Apple Silicon becoming a fully supported platform in the Linux kernel mainline — not just in Asahi’s downstream fork.

The problem involves how operating systems put CPU cores to sleep. ARM64 kernel maintainers require that any platform accepted into the mainline use the Power State Coordination Interface, or PSCI — a standardized API that lets the OS delegate CPU sleep and wake functions to firmware. Apple Silicon, however, lacks EL3, the ARM exception level where PSCI firmware is expected to run. The Linux kernel at EL2 has no higher exception level to hand control to, so it cannot issue the standard SMC (Secure Monitor Call) that would normally invoke PSCI. This has left the Asahi team running an Apple-specific CPU idle driver that works correctly but cannot be merged upstream.

Sven’s solution exploits a detail in the PSCI specification that most implementations ignore: the spec defines its interface without mandating a specific conduit, listing SMC and HVC only as examples. By carving out a memory region for Asahi’s m1n1 bootloader firmware and leaving behind a PSCI implementation accessible as a UEFI Runtime Service — the same mechanism UEFI uses for things like firmware variable access after boot — Sven provides the kernel with a valid PSCI endpoint via UEFI that happens to run at the same exception level. The patches are on the mailing list as an RFC. Whether ARM64 maintainers accept the interpretation is the open question. If they do, Apple Silicon CPU power management could join the mainline, removing the last major architectural barrier to Apple Silicon becoming a standard ARM64 Linux target available to any distribution without a separate fork.

How Does Asahi Linux Work on an M4?

The M4 bring-up, while too early for daily use, revealed additional layers of Apple’s platform security infrastructure — and how the team is navigating them.

The most immediate problem was a change in Apple’s NVMe storage controller firmware in the macOS 15.x firmware bundle. Without the updated initialization sequence, Linux could not read the drive. Yureka and Sven worked through the changes in both the m1n1 bootloader and the kernel driver; NVMe storage now works on both M4 and M5. PCIe device enumeration — the process by which Linux detects and identifies hardware on the bus — is also functional, and a crash triggered by booting with more than one CPU core active has been fixed. Those patches are already in linux-next.

M4 also introduced a CPU power management constraint with no equivalent on prior Apple Silicon. On M1 through M3, per-core power state behavior can be fine-tuned through what ARM documentation calls “chicken bits” — low-level configuration registers. Apple configures and then locks these registers in mBoot starting with M4. The consequence is that issuing a Wait For Interrupt (WFI) instruction — the ARM mechanism for parking an idle CPU core — causes M4 cores to lose their state entirely and crash whatever was running on them. Yureka worked around this by adding a kernel command-line parameter that makes idle loop behavior configurable, including a basic no-operation loop that prevents crashes during early boot before the CPU idle driver loads.

M4 also broke the m1n1 hypervisor that the Asahi team uses for hardware reverse-engineering. Apple’s Secure Page Table Monitor (SPTM) — a security subsystem that manages memory at a hardware level inside Apple’s Guarded Execution Framework (GXF), a set of exception levels running parallel to standard ARM64 — is mandatory on M4 and above. The m1n1 hypervisor previously had no understanding of GXF or SPTM, and crashed on M4 machines.

Sven drew on earlier reverse-engineering work he had already done on Apple’s SPRR (a custom page table permissions system for GXF code) to teach m1n1 to emulate GXF and SPRR, then load Apple’s SPTM binary inside the hypervisor itself. The result is restored MMIO tracing on M4 — and a path forward for new hardware bring-up across future Apple Silicon generations.

M4 and M5 Macs are not yet available through the Asahi Installer. The project has no timeline to announce for those platforms. Working storage, PCIe enumeration, and stable multicore boot represent the minimum foundation needed before other hardware work can begin — and that foundation is now confirmed on both chips.

What Is Asahi Linux, and Who Is It For?

Asahi Linux has been porting Linux to Apple Silicon since late 2020, when Apple announced its transition away from Intel processors. The project operates entirely through reverse-engineering — Apple does not release hardware documentation — and has grown from a one-person funded effort by founder Hector Martin into a community project operating under shared governance since Martin’s departure in February 2025. It is funded through GitHub Sponsors and Open Collective.

The flagship distribution is Fedora Asahi Remix, released as a stable build and maintained in partnership with the Fedora Project. M1 and M2 Macs running Fedora Asahi Remix have full GPU acceleration (including conformant OpenGL 4.6 and Vulkan 1.3 drivers), Wi-Fi, Bluetooth, audio, webcam, and display output. By those metrics, Asahi Linux already makes M1 and M2 machines viable as daily-driver Linux workstations for developers and power users — a result many observers considered unlikely when the project launched.

M3 support will extend that capability to a much larger installed base. The MacBook Air M3, released in March 2024, became one of the best-selling Mac laptops of that year. M3 MacBook Pros and iMacs shipped starting in October 2023. All will be covered by the upcoming release.

Frequently Asked Questions

Can you run Asahi Linux on an M3 Mac right now?

Not through the official installer — yet. As of August 27, 2026, the M3 release is described as “almost ready” with an announcement expected in the coming weeks. M1 and M2 Macs are fully supported by the Fedora Asahi Remix installer today. M3 users who want to track progress can follow the project’s blog at asahilinux.org.

What hardware works — and what does not — in the upcoming M3 release?

The Linux 7.2 progress report confirms that webcam, built-in microphone, USB 3.0, Thunderbolt, and display output are all now working on M3 Macs. GPU acceleration (via the AGX driver), Wi-Fi, Bluetooth, and battery management were already functional on M3 from prior work. Hardware-accelerated video decoding via the VA-API translation layer does not yet ship by default and is not compatible with Firefox’s sandboxed decoder.

What is the PSCI problem, and why does it matter for Apple Silicon Linux?

PSCI is the standard interface ARM defines for CPU power management on Linux. All hardware accepted into the Linux kernel mainline is required to use it. Apple Silicon lacks EL3, the processor exception level where PSCI firmware normally runs, which has blocked Asahi’s CPU idle code from being merged upstream. Sven Peter’s RFC patch proposes using a UEFI Runtime Service as an alternative PSCI conduit — a novel interpretation of the spec. If accepted, it could allow Apple Silicon to be supported natively in any standard Linux distribution, not just through Asahi’s fork.

When will Asahi Linux support M4 and M5 Macs?

No timeline has been announced. The team has confirmed that NVMe storage, PCIe enumeration, and multicore boot are working on both M4 and early M5 systems — the essential foundation for further hardware bring-up — but neither chip is ready for daily use and neither is available through the Asahi Installer. Given that M3 support took approximately three years from M3’s introduction in late 2023, M4 support should not be expected before 2027 at the earliest.