Phoronix first reported the imminent release based on Asahi Linux’s August 26 progress report. The project’s own account is more valuable than the headline: it identifies exactly what has changed, which parts live in its downstream kernel rather than mainline Linux, and the major missing component users should keep in mind before treating this as a full replacement for macOS.
The important shift is that Asahi is moving M3 support from a developer bring-up effort toward a distributable release. That is a practical dividing line. A machine that can boot a hand-assembled kernel is useful to driver developers; a machine that can run an installer-supported Fedora Asahi Remix configuration is useful to owners, IT labs and Linux users who need repeatable deployment and updates.
M3 support has crossed several hardware hurdles
The latest Asahi Linux report says its developers have brought up USB 3.0 and Thunderbolt across the M3 series by reverse-engineering changes in Apple’s USB-C controller arrangement. Earlier Apple Silicon systems and base M3 machines used an Apple-specific controller called ACE2, accessed over I²C. Apple moved M3 Pro and M3 Max systems to ACE3, which uses the SPMI management bus instead.
That sounds like an implementation detail, but it is the difference between a Linux installation that merely recognizes basic peripherals and one that can use high-speed external storage, docks and Thunderbolt-connected equipment. Asahi says both the SPMI interface and ACE3 controller support are now functioning in its Linux work, allowing USB 3.0 and Thunderbolt on all M3-series devices.
The team also reports full webcam support on M3 models that include a built-in camera, after accommodating an M3 Max-specific initialization difference in the image signal processor driver. Microphone support required a separate fix for a new high-frequency decimator and a substantially different initialization message. These are the mundane-looking driver changes that determine whether a laptop is viable for remote work rather than merely interesting on a test bench.
Those accomplishments build on progress reported in June, when Asahi said M3 systems had working PCIe, NVMe storage, Wi-Fi, Bluetooth, keyboard, trackpad, CPU frequency switching and core scheduling. The stated target is now an official release, with more details due “in the coming weeks.” Asahi has not given a date, named a Fedora Asahi Remix build, or published a final device-by-device support list for the release.
That omission is sensible. An installer release carries a much higher support burden than a development branch, particularly on hardware with multiple port layouts, display panels and peripheral configurations. But prospective users should read “almost ready” as a status report, not a shipping announcement.
The M3 release will still be a downstream Linux product
The biggest qualification is upstreaming. Asahi’s new M3 enablement is currently headed for its downstream linux-asahi code, not yet the stock kernel that ordinary distributions ship. The project explicitly says the patches will take longer to enter mainline Linux.
That affects how M3 owners should plan deployments. The first official route will almost certainly rely on the Asahi-maintained kernel, boot chain and packaging used by Fedora Asahi Remix. Installing an arbitrary ARM64 distribution or replacing the Asahi kernel with a generic upstream kernel could discard exactly the hardware support that makes this release useful.
Asahi’s own feature documentation defines linux-asahi as code that is stable or mostly stable in its downstream environment, with upstream integration expected later. It labels work-in-progress features separately. That distinction is important for sysadmins: downstream does not mean unreliable, but it does mean the hardware-enablement stack remains project-specific and must be maintained in step with Apple firmware behavior and the distribution.
There is also a visible documentation lag—or, more charitably, a difference between “working in current development” and “ready to claim as supported in the matrix.” The progress report states that USB 3.0 and Thunderbolt are working on M3-series devices. Yet Asahi’s M3 feature table still labels USB 3.0 over Thunderbolt ports as WIP and Thunderbolt as TBA.
The project has not explained that mismatch. It may simply mean the table has not caught up with the August 26 code, or that the team does not consider the feature stable enough to mark as officially available in a release. Until the release notes resolve it, users who depend on a Thunderbolt dock, display chain or storage array should not assume every configuration is validated merely because controller support now exists.
GPU acceleration remains the release’s central limitation
The M3 release announcement is significant precisely because it is landing before the hardest remaining work is done. Asahi’s February report said M3 graphical environments were software-rendered, slow and energy intensive, and that M3 GPU support would not arrive soon. The current feature matrix still lists the M3 GPU as work in progress, while M3 Pro, M3 Max and M3 Ultra GPU support is marked TBA.
That means the first release should be judged as a platform-enablement release, not as a performance Linux workstation release. Users can expect a much more complete basic system than the early M3 experiments offered: storage, input, wireless, audio components, cameras and external I/O are what make daily use possible. But graphical workloads, desktop responsiveness under heavier compositing, games, GPU compute and battery efficiency will remain constrained until the new GPU architecture is properly supported.
Apple changed the M3 GPU substantially from the M1 and M2 family, adding hardware features including ray tracing, mesh shading and Dynamic Caching. Asahi cannot reuse its earlier Apple GPU driver work unchanged; it has to reverse-engineer the altered instruction set and interfaces. In parallel, its display controller work targets the firmware interface from macOS 14.8.3 because M3 Macs cannot run the macOS 13.5 firmware ABI used on M1 and M2 support.
The release therefore represents a calculated compromise. In February, Asahi said it did not want to repeat the rough initial era of Arch Linux ARM builds on M1 hardware, but also could not reasonably wait until every M1/M2 feature had reached parity. The August status update suggests it has completed enough of the laptop fundamentals to accept that compromise.
Power management and video are advancing on separate tracks
M3 support is only part of the report. Asahi is also working on deeper CPU idle states in a way that can be accepted by upstream Linux. Its current downstream implementation can use a deeper form of ARM’s Wait For Interrupt idle behavior, but upstream ARM64 power-management rules expect the Power State Coordination Interface, or PSCI.
Asahi’s proposed answer is a PSCI conduit built through UEFI Runtime Services. This is more than housekeeping: idle-state behavior has direct consequences for heat, battery draw and suspend-like efficiency. The work is not yet described as completed, so M3 users should not mistake the imminent release for the final word on battery life.
The project is also refining hardware video decoding. Its Apple Video Decoder work can now handle H.264, H.265 and VP9 decoding on supported machines, while M3-class hardware adds AV1 capability. But desktop integration remains incomplete. Asahi says its current VA-API translation approach does not ship by default in Fedora Asahi Remix and does not work with Firefox’s video-decoding sandbox.
That is another example of why hardware support claims need to be read at the application layer. A driver recognizing a media block does not automatically mean browser streaming or conferencing software will use it. The same distinction applies to the project’s direct scan-out effort, which aims to move decoded or rendered frames to the display without needless copies through CPU and GPU memory. It could reduce memory-bandwidth use and power draw substantially, but it is still work in progress rather than a feature of the upcoming M3 release.
M4 and M5 owners are still outside the installer
Asahi has also achieved early NVMe and PCIe progress on M4 and M5 systems, including a fix for a multi-core boot crash. The project says it can enumerate PCIe devices and use NVMe storage on those newer chips. That is genuine forward movement, but Asahi is unambiguous that little else is working and that M4 and M5 machines are not ready to be enabled in the Asahi Installer.
Apple’s M4 introduced new obstacles, including changes around its System Protection Monitor and memory-protection mechanisms that initially broke Asahi’s hypervisor-based tracing approach. Asahi says it has restored that ability by emulating the relevant mechanisms sufficiently to load and observe Apple software, albeit more slowly than on M1 through M3 systems. That gives developers a path to continue reverse-engineering future Apple hardware; it gives end users no near-term deployment promise.
For M3 owners, the practical consequence is straightforward: wait for the official Asahi release and read its exact supported-device and known-issues list before repartitioning a Mac or committing hardware to Linux. The project has solved enough of the machine to make that release meaningful. It has not solved enough to make M3 support equivalent to mature M1 or M2 installations, and the unaccelerated GPU remains the line between an early usable desktop and a complete one.
