Progress Report: Linux 6.19 – Asahi Linux

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 one

Asahi 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; DCP^{, DPXBAR, ATCPHY, and ACE. 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 one

For 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 good

The 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 a static value. While it
works for our use case, this solution precludes support for VRR, which brings us nicely
to our next topic.

Landing the plane

The DCP driver for Linux has historically been rather incomplete. This shouldn’t be surprising;
display engines are massively complex, and this is reflected in the absolutely enormous 9 MiB
blob of firmware that DCP runs. This firmware exposes interfaces which are designed
to integrate tightly with macOS. These interfaces also change in breaking ways between macOS
releases, requiring special handling for versioned structures and function calls.

All of this has led to a driver that has been developed in an suboptimal, piecemeal
fashion. There are many reasons for this:

• We lacked the time to do anything else, especially Janne, who took on the burden
  of maintaining and rebasing the Asahi kernel tree
• There were more important things to do, like bringing up other hardware
• We plan to rewrite the driver in Rust anyway to take advantage of better
  firmware version handling

On top of all that, it simply did not matter for the design goals at the time. The
initial goal was to get enough of DCP brought up to reliably drive the builtin displays
on the laptops and the HDMI ports on the desktops, and we achieved that by gluing
just enough of DCP’s firmware interface to the KMS API to scan out a single 8-bit ARGB
framebuffer on each swap.

We have since implemented support for audio over DisplayPort/HDMI, basic colour management
for Night Light implementations that support Colour Transformation Matrices, and
rudimentary hardware overlays. But this still leaves a lot of features on the table, such
as HDR, VRR, support for other framebuffer formats, hardware brightness control for
external displays (DDC/CI), and direct scanout support for multimedia and fullscreen
applications.

Supporting these within the confines of the current driver architecture would be difficult.
There are a number of outstanding issues with userspace integration and the way
in which certain components interact with the KMS API. That said, want to push forward with
new features, and waiting for Rust KMS bindings to land upstream could leave us
waiting for quite some time. We have instead started refactoring sections of the existing
DCP driver where necessary, starting with the code for handling hardware planes.

Why start there? Having proper support for hardware planes is important for performance
and efficiency. Most display engines have facilities for compositing
multiple framebuffers in hardware, and DCP is no exception. It can layer, move, blend and
even apply basic colour transformations to these framebuffers. The classical use case
for this functionality has been cursors; rather than have the GPU redraw the entire desktop
every time the cursor moves, we can put the cursor on one of the display engine’s overlay
planes and then command it to move that static framebuffer around the screen. The GPU is
only actively rendering when on-screen content needs redrawing, such as when hovering
over a button.

I shoehorned extremely limited support for this into the driver a while ago, and it
has been working nicely with Plasma 6’s hardware cursor support. But we need to go
deeper.

DCP is capable of some very nifty features, some of which are absolutely
necessary for HDR and direct video scanout. Importantly for us, DCP can:

• Directly scan out semiplanar Y’CbCr framebuffers (both SDR and HDR)
• Take multiple framebuffers of differing colourspaces and normalise them to the
  connected display’s colourspace before scanout
• Directly scan out compressed framebuffers created by AGX ^{and AVD}
• Automatically normalise mixed dynamic range content

All of these are tied to DCP’s idea of a plane. I had initally attempted to
add support for Y’CbCr framebuffers without any refactoring, however this
this was proving to be messy and overly complicated to integrate with
the way we were constructing a swap request at the time. Refactoring the
plane code made both adding Y’CbCr support and constructing a swap request
simpler.

We have also been able to begin very early HDR experiments, and get more complete
overlay support working, including for Y’CbCr video sources. Plasma 6.5 has
very basic support for overlay planes hidden behind a feature flag, however
it is still quite broken. A few Kwin bugs related to this are slated to be
fixed for Plasma 6.7, which may enable us to expand DCP’s overlay support
even further.

On top of this, Oliver has also begun working on compressed framebuffer support.
There are currently two proprietary Apple framebuffer formats we know of in use on Apple
Silicon SoCs; AGX has its own framebuffer format which is already supported in Mesa, however macOS
never actually sends framebuffers in this format to DCP. Instead, DCP always
scans out framebuffers in the “Apple Interchange” format for both GPU-rendered
framebuffers and AVD-decoded video. Oliver reverse engineered this new format
and added experimental support for it to Mesa and the DCP driver. While still
a work in progress, this should eventually enable significant memory bandwidth
and energy savings, particularly when doing display-heavy tasks like watching
videos. Experimentation with DCP and its firmware suggests that it may be capable
of directly reading AGX-format framebuffers too, however this will require further
investigation as we cannot rely on observations from macOS.

Additionally, Lina observed macOS using shader code to decompress Interchange
framebuffers while reverse engineering AGX, suggesting that some variants of AGX
may not be capable of working with the format. If this is the case, we will be
restricted to only using Interchange for AVD-decoded video streams, falling back
to either AGX format if it turns out to be supported by DCP, or linear framebuffers
for content rendered by the GPU.

Beyond adding new features, reworking the plane handling code has also
enabled us to more easily fix oversaturated colours on the builtin
MacBook displays, starting with kernel version 6.18. Folks currently using
an ICC profile to work around this problem should disable this, as it will
conflict with DCP’s internal colour handling.

Planes are just one part of the puzzle, however. There is still much work to be
done cleaning up the driver and getting features like HDR into a shippable state.
Watch this space!

Say cheese!

It’s been quite a while since we shipped webcam support, and for most users
it seems to have Just Worked! But not for all users.

Users of certain webcam applications, most notable GNOME’s Camera app, have been
reporting severe issues with webcam support since day one. Doing some initial
debugging on this pointed to it being a an issue with GNOME’s app, however this
turned out not to be the case. The Asahi OpenGL driver was actually improperly
handling planar video formats. The ISP/webcam exports
planar video framebuffers via V4L2, which must then be consumed and turned into
RGB framebuffers for compositing with the desktop. Apps such as GNOME’s Camera
app do this with the GPU, and thus were failing hard. While studying the
fix for this,
Janne noticed that Honeykrisp was not properly announcing the number of planes
in any planar framebuffers, and fixed
that too. In the process of debugging these issues, Robert Mader found
that Fedora was not building GStreamer’s gtk4paintablesink plugin with
Y’CbCr support, which will be fixed for Fedora Linux 43.

So all good right? Nope! Hiding behind these bugs in the GPU drivers were two more
bugs, this time in PipeWire. The first was an integer overflow in PipeWire’s
GStreamer code, fixed
by Robert. This then revealed the second bug; the code which determines the latency of a stream was
assuming a period numerator of 1, which is not always the case. With Apple Silicon
machines, the period is expressed as 256/7680, which corresponds to 30 frames per
second. Since the numerator is not 1, the latency calculation was not being normalised,
and thus ended up so long that streams would crash waiting for data from PipeWire.
Janne submitted a merge request
with a fix, which made it in to Pipewire 1.4.10. Why 256/7680 is not reduced to
1/30 is another mystery that needs solving, however at least now with these two
patches, we’re all good right? Right?

So, graphics programming is actually really hard. As it happens, the GPU kernel driver
was not properly handling DMA-BUFs from external devices, deadlocking once it was
done using the imported buffer. After fixing this and removing a very noisy log
message that was being triggered for every imported frame, the webcam came to life!
This should mean that the webcam is now fully supported across the vast majority of
applications.

The beast stirs

We’ve made incredible progress upstreaming patches over the past 12 months. Our patch
set has shrunk from 1232 patches with 6.13.8, to 858 as of 6.18.8. Our total delta in
terms of lines of code has also shrunk, from 95,000 lines to 83,000 lines for the same
kernel versions. Hmm, a 15% reduction in lines of code for a 30% reduction in patches
seems a bit wrong…

Not all patches are created equal. Some of the upstreamed patches have been small
fixes, others have been thousands of lines. All of them, however, pale in comparison
to the GPU driver.

The GPU driver is 21,000 lines by itself, discounting the downstream Rust abstractions
we are still carrying. It is almost double the size of the DCP driver and thrice the
size of the ISP/webcam driver, its two closest rivals. And upstreaming work has
now begun.

We were very graciously granted leave to upstream our UAPI headers without an
accompanying driver by the DRM maintainers quite some time ago, on the proviso
that the driver would follow. Janne has now been laying the groundwork for that
to happen with patches to IGT,
the test suite for DRM drivers.

There is still some cleanup work required to get the driver into an upstreamable
state, and given its size we expect the review process to take quite some time
even when it is ready. We hope to have more good news on this front shortly!

Correct, then fast

GPU drivers have a lot of moving parts, and all of them are expected to work
perfectly. They are also expected to be fast. As it so happens, writing software
that is both correct and fast is quite the challenge. The typical development
cycle for any given GPU driver feature is to make it work properly first, then
find ways to speed it up later if possible. Performance is sometimes left on
the table though.

While looking at gpu-ratemeter
benchmark results, Janne noticed that memory copies via the OpenGL driver were
pathologically slow, much slower than Vulkan-initiated memory copies. As in, taking
an hour to complete just this one microbenchmark slow. Digging
around in the Asahi OpenGL driver revealed that memory copy operations were being
offloaded to the CPU rather than implemented as GPU code like with Vulkan. After
writing a shader to implement this, OpenGL copies now effectively saturate the
memory bus, which is about as good as one could hope for!

But why stop there? Buffer copies are now fast, but what about clearing memory?
The Asahi driver was using Mesa’s default buffer clearing helpers, which work
but cannot take advantage of hardware-specific optimisations. Janne also replaced
this with calls to AGX-optimised functions which take optimised paths for
memory-aligned buffers. This allows an M1 Ultra to clear buffers aligned to
16 byte boundaries at 355 GB/s.

But wait, there’s more! While Vulkan copies were indeed faster than OpenGL copies,
they weren’t as fast as they could be. Once again, we were neglecting to use our
AGX-optimised routines for copying aligned buffers. Fixing this gives us some pretty
hefty performance increases for such buffers, ranging from 30% faster for 16 KiB
buffers to more than twice as fast for buffers 8 MiB and larger!

Perfecting packages

All this stuff around pushing pixels perfectly requires good delivery of the code,
and Neal has worked on improving the package management experience in Fedora Asahi Remix.

The major piece of technical debt that existed in Fedora’s package management stack was
that it technically shipped two versions of the DNF package manager concurrently,
which is exactly as bad as it sounds. Both versions had their own configuration,
feature sets and behavioural quirks.

DNF5, the newer version, introduces the ability to automatically transition
packages across vendors. This is important for us, as it streamlines our ability to
seamlessly replace our Asahi-specific forks with their upstreams packages as we get our code merged.
DNF4 cannot do this, and until Fedora Linux 41 was the default version used when running dnf
from the command line. To make matters worse, PackageKit, the framework used by GUI
software stores like KDE Discover, only supports DNF4’s API. Or rather, it did
only support DNF4’s API.

Neal has been working with the both the DNF and PackageKit teams to make this work
seamlessly. To that end, he developed
a DNF5-based backend for PackageKit, allowing GUI software managers to take advantage of
this new feature. This will be integrated
in Fedora Linux 44, however we will also be shipping it in the upcoming Fedora Asahi Remix 43.

The automated transition to upstream packages will begin with Mesa and virglrenderer
in Fedora Asahi Remix 44.

More conferences

Sven, chaos_princess, Neal and Davide met up at FOSDEM in Belgium last month to discuss
strategies for supporting M3 and M4, and to try their luck at nerd sniping folks into
helping out. Additionally, both Neal and Davide will once again be at at SCaLE
next month. Davide will be hosting an Asahi demo system at Meta’s
booth, so be sure to drop in if you’re attending!

One more go around

2026 is starting off with some exciting progress, and we’re hoping to keep it coming.
As ever we are extremely grateful to our supporters on OpenCollective
and GitHub Sponsors, without whom we would
not have been able to sustain this effort through last year. Here’s to anoter 12 months
of hacking!

James Calligeros · 2026-02-15