Asahi Linux Progress Report: Linux 6.19

Hacker News · Feb 18, 2026 · Collected from RSS

Full Article

Happy belated new year! Linux 6.19 is now out in the wild and… ah, let’s just cut to the chase. We know what you’re here for.The big oneAsahi Linux turns 5 this year. In those five years, we’ve gone from Hello World over a serial port to being one of the best supported desktop-grade AArch64 platform in the Linux ecosystem. The sustained interest in Asahi was the push many developers needed to start taking AArch64 seriously, with a whole slew of platform-specific bugs in popular software being fixed specifically to enable their use on Apple Silicon devices running Linux. We are immensely proud of what we have achieved and consider the project a resounding and continued success.And yet, there has remained one question seemingly on everyone’s lips. Every announcement, every upstreaming victory, every blog post has drawn this question out in one way or another. It is asked at least once a week on IRC and Matrix, and we even occasionally receive emails asking it.“When will display out via USB-C be supported?”“Is there an ETA for DisplayPort Alt Mode?”“Can I use an HDMI adapter on my MacBook Air yet?”Despite repeated polite requests to not ask us for specific feature ETAs, the questions kept coming. In an effort to try and curtail this, we toyed with setting a “minimum” date for the feature and simply doubling it every time the question was asked. This very quickly led to the date being after the predicted heat death of the universe. We fell back on a tried and tested response pioneered by id Software; DP Alt Mode will be done when it’s done.And, well, it’s done. Kind of.In December, Sven gave a talk at 39C3 recounting the Asahi story so far, our reverse engineering process, and what the immediate future looks like for us. At the end, he revealed that the slide deck had been running on an M1 MacBook Air, connected to the venue’s AV system via a USB-C to HDMI adapter!At the same time, we quietly pushed the fairydust branch to our downstream Linux tree. This branch is the culmination of years of hard work from Sven, Janne and marcan, wrangling and taming the fragile and complicated USB and display stacks on this platform. Getting a display signal out of a USB-C port on Apple Silicon involves four distinct hardware blocks; DCP1, DPXBAR2, ATCPHY3, and ACE4. These four pieces of hardware each required reverse engineering, a Linux driver, and then a whole lot of convincing to play nicely with each other.All of that said, there is still work to do. Currently, the fairydust branch “blesses” a specific USB-C port on a machine for use with DisplayPort, meaning that multiple USB-C displays is still not possible. There are also some quirks regarding both cold and hot plug of displays. Moreover, some users have reported that DCP does not properly handle certain display setups, variously exhibiting incorrect or oversaturated colours or missing timing modes.For all of these reasons, we provide the fairydust branch strictly as-is. It is intended primarily for developers who may be able to assist us with ironing out these kinks with minimal support or guidance from us. Of course, users who are comfortable with building and installing their own kernels on Apple Silicon are more than welcome to try it out for themselves, but we cannot offer any support for this until we deem it ready for general use.The other big oneFor quite some time, m1n1 has had basic support for the M3 series machines. What has been missing are Devicetrees for each machine, as well as patches to our Linux kernel drivers to support M3-specific hardware quirks and changes from M2. Our intent was always to get to fleshing this out once our existing patchset became more manageable, but with the quiet hope that the groundwork being laid would excite a new contributor enough to step up to the plate and attempt to help out. Well, we actually ended up with three new contributors!Between the three of them, Alyssa Milburn (noopwafel), Michael Reeves (integralpilot), and Shiz, with help from Janne, wrote some preliminary Devicetrees and found that a great deal of hardware worked without any changes! Adding in some minor kernel changes for the NVMe and interrupt controllers, Michael was able to boot all the way to Plasma on an M3 MacBook Air!In fact, the current state of M3 support is about where M1 support was when we released the first Arch Linux ARM based beta; keyboard, touchpad, WiFi, NVMe and USB3 are all working, albeit with some local patches to m1n1 and the Asahi kernel (yet to make their way into a pull request) required. So that must mean we will have a release ready soon, right?A lot has changed in five years. We have earnt a reputation for being the most complete and polished AArch64 desktop Linux experience available, and one of the most complete and polished desktop Linux experiences in general. It is a reputation that we are immensely proud of, and has come at a great personal cost to many. We will not squander it or take it for granted.Ideally, the current state of M1 and M2 support should be the baseline for any general availability release for M3. We know that’s not realistic, however nor is releasing a janky, half-baked and unfinished mess like the initial ALARM releases all those years ago. So, what needs to be done before we can cut a release? Quite a bit, actually.The first thing intrepid testers will notice is that the graphical environment is entirely software-rendered. This is extremely slow and energy intensive, and barely keeps up with scrolling text in a terminal window. Unfortunately, this is not likely to change any time soon; the GPU design found in M3 series SoCs is a significant departure from the GPU found in M1 and M2, introducing hardware accelerated ray tracing and mesh shaders, as well as Dynamic Caching, which Apple claims enables more efficient allocation of low-level GPU resources. Alyssa M. and Michael have volunteered their time to M3 GPU reverse engineering, and building on the work done by dougallj and TellowKrinkle, have already made some progress on the myriad changes to the GPU ISA between M2 and M3.We are also relying on iBoot to initialise DCP and allocate us a framebuffer, rather than driving DCP directly (and correctly) ourselves. This is extremely slow and inefficient, and prevents us from properly managing many display features, such as the backlight. Since no M3 devices can run macOS 13.5, and since Apple made a number of changes to the DCP firmware interface for macOS 14, bringing up DCP on M3 devices will require more reverse engineering. Luckily these changes only affect the API itself, and not the protocol used to communicate between the OS and coprocessor. This means we can reuse our existing tooling to trace the new firmware interface with minimal changes.Beyond hardware enablement, there are also the numerous integrations and finishing touches that make the Asahi experience what it is. Energy-Aware Scheduling, speaker safety and EQ tuning, microphone and webcam support, and a whole host of other features that folks expect are still not there, and won’t be for some time. Some of these, like Energy-Aware Scheduling, are quality of life features that are not likely to block a release. Others, such as getting M3 devices supported in speakersafetyd, are release-blocking.We don’t expect it to take too long to get M3 support into a shippable state, but much as with everything else we do, we cannot provide an ETA and request that you do not ask for one.Hertz so goodThe 14" and 16" MacBook Pros have very nice displays. They have extremely accurate colour reproduction, are extremely bright, and are capable of a 120 Hz refresh rate. But there’s a catch.On macOS, you cannot simply set these displays to 120 Hz and call it a day. Instead, Apple hides refresh rates above 60 Hz behind their ProMotion feature, which is really just a marketing term for bog standard variable refresh rate. One could be forgiven for assuming that this is just a quirk of macOS, and that simply selecting the 120 Hz timing mode in the DCP firmware would be enough to drive the panel at that refresh rate on Linux, however this is not the case.For reasons known only to Apple, DCP will refuse to drive the MacBook Pro panels higher than 60 Hz unless three specific fields in the surface swap request struct are filled. We have known for some time that these fields were some form of timestamp, however we never had the time to investigate them more deeply than that. Enter yet another new contributor!Oliver Bestmann took it upon himself to get 120 Hz working on MacBook Pros, and to that end looked into the three timestamps. Analysing traces from macOS revealed them to count upward in CPU timer ticks. The timestamps are almost always exactly one frame apart, hinting that they are used for frame presentation timekeeping. Presentation timekeeping is required for VRR to work properly, as the compositor and driver must both be aware of when specific frames are actually being shown on the display. Compositors can also use this sort of information to help with maintaining consistent frame pacing and minimising tearing, even when VRR is not active.At this stage, we are only interested in a consistent 120 Hz, not VRR. Since macOS couples the two together, it is difficult to ascertain exactly what DCP expects us to do for 120 Hz. Clearly the timestamps are required, but why? What does DCP do with them, and what exactly are they supposed to represent?Sometimes, doing something stupid is actually very smart. Assuming that the timestamps are only meaningful for VRR, Oliver tried stuffing a static value into each timestamp field. And it worked! Starting with kernel version 6.18.4, owners of 14" and 16" MacBook Pros are able to drive their builtin displays at 120 Hz.Now of course, this solution is quite clearly jank. The presentation timestamps are currently being set every time the KMS subsystem triggers an atomic state flush, and they are definitely not supposed to be set to