By ByteBot
Asahi Linux dropped its Linux 7.2 progress report yesterday, August 26, landing on Hacker News with 370 points and 195 comments — one of the day’s top stories. The headline: M3 support is now functionally complete, M4 and M5 have their first real kernel milestones, and a years-long power management obstacle has a working solution. For the millions of developers running M-series MacBooks who want native Linux on Apple Silicon, this report is worth reading closely.
M3 Support Is Nearly Complete in Asahi Linux
With Linux 7.2, the M3 series achieves near-complete hardware support. Webcam works via the ISP (Image Signal Processor) driver. Microphone is operational through a “high frequency” decimator with updated coefficients. USB 3.0 and Thunderbolt land via ACE3 — a new SPMI-based USB controller Apple introduced with M3, replacing the I2C-based ACE2 used in M1 and M2. Both controller generations are now supported.
The sticking point for M3 was ATCPHY — the USB3/Thunderbolt PHY. Apple’s N3 (3nm) process transition changed the hardware behavior enough that M3 required a completely different initialization sequence compared to M1/M2’s N5/N4 chips. Contributors chaos_princess and mildsunrise reverse-engineered it. The display controller firmware (DCP) also hit near-parity with M1/M2, now targeting macOS 14.8.3 ABI. According to Linuxiac’s coverage, M3 installer support is the logical next step after these kernel milestones.
Hardware Video Decode Arrives for Apple Silicon
The Apple Video Decoder (AVD) now handles H.264, H.265, and VP9 on M1, M2, and M3. M3 and newer add AV1. Reliability is solid for H.264 and H.265; VP9 and AV1 continue improving. However, getting hardware decode to work in practice requires manual setup that has not yet landed as a Fedora Asahi default.
The root cause is an API mismatch. AVD is stateless hardware — each video frame is decoded independently with no persistent firmware state. That maps cleanly to the V4L2 Stateless API. Desktop software, however, expects VA-API. Developer sofus maintains a translation layer that bridges the gap, but it requires a manual environment variable for now:
export LIBVA_DRIVER_NAME=v4l2stateless
export LIBVA_DRIVERS_PATH=/usr/lib64/dri
mpv --hwdec=vaapi your-video.mp4Firefox hardware decode remains broken — the browser’s video sandbox doesn’t cooperate with the translation layer. For hardware-accelerated video, mpv, VLC, or a Chromium-based browser work fine. This isn’t a daily-driver blocker for most workflows, but it is an honest gap worth knowing before committing to Asahi as your primary system.
Related: Apple M6 and M5 Ultra: What Developers Need to Know
M4 and M5 Linux: First Milestones, Not Yet Ready
M4 and M5 are now booting Linux and enumerating PCIe devices — real progress, even if neither chip is anywhere near installer-ready. NVMe works after the team reverse-engineered Apple’s macOS 15.x NVMe firmware ABI changes. A crash that fired when enabling more than one CPU core has been fixed. Developers Yureka and Sven have been driving M4/M5 bring-up, as detailed in the Phoronix coverage of recent Asahi milestones.
One concrete sign of how differently each Apple Silicon generation behaves at the silicon level: WFI (Wait For Interrupt) causes M4 to lose CPU state entirely. On M1 through M3, WFI is safe and used normally. On M4, calling WFI crashes whatever was running. The workaround — a no-op idle loop configured via kernel command line — is now in linux-next. Apple also locked down per-core “chicken bit” registers starting with M4, removing a tuning mechanism M1-M3 relied on. Every generation is a new reverse-engineering project from scratch.
Power Management Gets a Working Solution
Linux’s standard CPU power management uses PSCI (Power State Coordination Interface), which requires calling into EL3 (Secure Monitor) firmware. Apple Silicon has no EL3 layer — m1n1 runs at EL2. This architectural mismatch has blocked proper CPU idle states and sleep on Asahi for years.
Sven’s solution: use UEFI Runtime Services as a callback mechanism from the kernel at EL1 back into m1n1 at EL2, bypassing the EL3 requirement entirely. It’s unorthodox, but it works. RFC patches are on the Linux mailing list; m1n1 has been updated to reserve the necessary memory and implement the PSCI interface. When this lands, proper sleep/wake and meaningfully better battery life follow. Direct scanout — GPU pushing frames straight to the display without a memory copy — also hit a functional milestone this cycle, pending a KDE Plasma 6.8 fix on the Kwin side.
Key Takeaways
- M3 hardware support is functionally complete in Linux 7.2 — webcam, microphone, USB 3.0, Thunderbolt, and hardware video decode. Installer support is the remaining step
- Hardware video decode works on M1/M2/M3 with manual VA-API setup; AV1 is supported on M3+; Firefox hardware decode remains broken
- M4 and M5 boot Linux and can enumerate NVMe and PCIe, but are not installer-ready. Apple continues changing hardware behavior between generations in ways that require full re-implementation
- A UEFI-based PSCI conduit is at RFC stage — this unblocks proper CPU power management and better battery life for all Apple Silicon hardware
- Direct scanout (GPU-to-display, no memory copy) is functional and pending a KDE Plasma 6.8 fix to reach most users
