VeltronNET/Dragon-Linux
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

chore: fixups

Browse source
This commit is contained in:
MattTheTekie 2025-08-01 18:46:22 -04:00
commit d5de494d40
2 changed files with 30 additions and 386 deletions
Download patch file Download diff file Expand all files Collapse all files

231
content/blog/2025/03/21-progress-report-6-14.md
View file

@ -1,11 +1,14 @@
+++
date = "2025-03-21T09:00:00+10:00"
draft = false
title = "Progress Report: Linux [KERNEL VER]"
slug = "progress-report-6-14"
title = "Progress Report: Linux [VER]"
slug = "sample-text-1"
author = "Matthew Pitsicalis"
+++
## Sample Text
WIP - REDO
As March draws to a close and Linux 6.14 nears release, now is a good time to
provide you all with our first major progress update since [taking the lead on
the project](https://asahilinux.org/2025/02/passing-the-torch/). Going forward,
@ -26,227 +29,3 @@ California Linux Expo, while I sat in the dark with no power as Tropical Cyclone
Alfred ravaged Southeast Queensland and northern New South Wales. Despite this,
we managed to get through quite a bit. You can find the meeting minutes
[here](https://asahilinux.org/docs/project/board/minutes/20250307).
## Lightening the load
After four years of development, we have racked up a considerable patch
set. Here are some quick-fire stats:
- 90,000+ lines of code added to the Linux kernel as of 6.13, across 1250 patches
- A downstream U-Boot with a number of Apple Silicon and USB stack fixes
- A downstream Mesa - required since our GPU uAPI is not upstream yet
- A downstream virglrenderer - required since our GPU uAPI is not upstream yet
- A downstream Flatpak runtime extension - required since we have a downstream Mesa
This is... less than ideal. Rebasing, testing, and releasing
our forks is a massive drain on our time. This is especially true
of Janne, who has the Sisyphean task of keeping our kernel patch set applying
upstream and porting it to every stable point release. That is hours of work
on an almost weekly basis, especially as the pace of Rust abstraction upstreaming
increases. We can't keep doing this.
We want to bring you M3 and M4 support. We want to bring you Thunderbolt. We want
to bring you DisplayPort Alt Mode. We want to bring you Variable Refresh Rate, and
HDR, and hardware accelerated video playback, and better power management for the
Pro/Max/Ultra Macs. To do that, however, we must start reducing the amount of patches
we're carrying downstream. Most of what we're carrying is stable and has been
for years. So after a month of tireless effort, how are we doing?
We have submitted three new drivers upstream - the Image Signal Processor (ISP)
driver, which is necessary for webcam support, and drivers for the Touchbar's
display controller and input digitiser. These three drivers total to almost
8,000 lines of code, with the ISP driver being 6,000 of those. The good news is
that both Touchbar drivers have already been accepted! Thanks to chaos_princess
for taking on the responsibility of preparing and submitting all three.
Alyssa and Janne have been hard at work tidying up the GPU driver to prepare it for
submission. This has involved some changes to the uAPI, which should slightly
improve performance for some workloads.
Now that Rust for Linux abstractions are starting to be merged at a healthy
pace, we are faced with an emerging challenge. It is rare for
any kernel patch to survive the mailing list without at least a couple of
non-trivial changes, and Rust abstractions are no exception. Every time an
abstraction used by our driver is merged, we must drop our downstream version
and rebase the driver atop the version accepted upstream. This is gruelling, menial,
and unpleasant work, and Janne has our deepest gratitude for volunteering his
time to get through it.
We have also been working to clean up and upstream other parts of the kernel.
In addition to a number of miscellaneous fixes and changes for drivers already
upstreamed such as the NVMe and I<sup>2</sup>C controllers, we have also submitted
changes to the upstream Texas Instruments TAS2764 and TAS2770 speaker amplifier
drivers which extend them to support the Apple-specific variants found in
Apple Silicon Macs. Through this process, we found that the ASoC maintainers
had already been cherry-picking some commits from our development branches!
We're far from done, but we are committed to getting through this vital work.
More patches are being submitted all the time, so watch this space!
## Is this thing on?
By the time you're reading this, we will have enabled microphone support on
most laptops! This has been a long time coming, with Martin Povišer, Eileen
Yoon, and chaos_princess having reverse engineered and developed a driver
for the Always-On Processor (AOP) in Rust quite some time ago. This is Apple
though. Nothing is ever simple.
Before even getting to play with the mics in Linux, we hit a hurdle.
On certain machines, the Secure Enclave is in the path of the physical mic
data lines. If SEP is unhappy, you don't get mic access. chaos_princess
quickly reverse engineered the SEP endpoint responsible, and wrote a
stub driver to simply toggle the hardware mic switch on. With data now
coming in to ALSA on all machines, we can continue.
In all laptops released so far, Apple use three Pulse Density Modulation
(PDM) mics wired up to an ADC and decimator in the AOP. All three mics are
plumbed directly to userspace on separate channels, with no preamplification.
Having three mics enables Apple to use beamforming, which is a signal processing
technique to greatly enhance the directivity and sensitivity of an array of sensors.
Originally developed for RADAR and military communications, it's now mostly known
for being a marketing dot point for WiFi access points. It's also really, really,
really hard.
Unfortunately, PDM mics are very omnidirectional and very sensitive. We cannot
get by without some kind of beamforming. I initially tried
a very basic delay-and-sum beamformer, which involves no advanced signal
processing. However since the mics are only about 2cm apart and only sample at
48 kHz, we cannot achieve the temporal resolution required to make this
approach work. Signal processing it is, then.
The mysteries of signal processing in the acoustic domain are truly understood by
very few. After consulting the scant available literature on the matter and my high
school maths textbooks, I thought I had absolutely no hope of doing a good job of this.
I put out a call for help on Mastodon, however no one offered to step up. Fine, I'll
do it myself.
After reading a few more papers, I found an approach that looked familiar to me.
A Minimum Variance Distortionless Response beamformer works by taking your complex
sample data in the time domain and using optimisation techniques weighted in a
particular direction relative to a fixed point (usually some mic in the array).
At some point, it clicked that this is really just statistics!
After wrestling with Rust's immature scientific computing libraries for a few weeks,
and even more reading of my high school maths and university statistics textbooks,
the result was [Triforce](https://crates.io/crates/triforce-lv2) - an MVDR beamformer
for the mics found in Apple laptops.
Thanks to the groundwork laid in PipeWire and WirePlumber for speaker support,
wiring up a DSP chain including Triforce for the microphones was really simple.
We just had to update the config files, and let WirePlumber figure out the rest!
Did it work? It's Rust, so it worked on the first try! When properly dialled in,
the mic array is sensitive to signals coming from a "typical" seating position in
front of the laptop, and mostly rejects noise from any other direction. Try it
yourself - play some music out of your phone and move it around your laptop. It
should become suppressed when moved out to the sides or behind the machine.
Once again, a huge thanks to Martin, Eileen, and chaos_princess for their incredible
work reversing AOP and SEP.
## Fedora Asahi Remix 42 Beta
Thanks to Davide's work validating builds, we are pleased to announce that Fedora
Asahi Remix 42 is [now available](https://fedoramagazine.org/announcing-fedora-asahi-remix-42-beta/)
as a beta! The final release is expected in about a month, bringing us closer than
ever to releasing at the same time as Fedora. We hope that in the next cycle
Fedora Asahi Remix 43 will release on the same day as Fedora Linux 43.
## Dragon Linux @ SCaLE
While at [SCaLE](https://www.socallinuxexpo.org/scale/22x), Neal and Davide managed
to set up a demonstration of Dragon Linux running on an M2 Mac mini and an M1 Mac Studio
in the expo hall. Reception was extremely positive, and folks had a blast playing a whole
bunch of Steam games through muvm and FEX! We even managed to get kids involved by firing
up Nidhogg, which proved to be the most popular game by far.
## WoAoA
Some astute users have noticed that ARM64 Windows VMs now work with KVM on
Asahi! This is thanks to Oliver Upton, who submitted a rather large series of
patches upstream to enable Arm PMUv3 emulation on Apple SoCs. WoA requires
PMUv3, and until now we could not emulate it. We quietly cherry-picked those
patches, and they are now incorporated into our latest kernels. Interested
parties can try Windows on ARM on Asahi today!
## What does the dxdiag say about its Feature Level?
It's 12_0! Alyssa recently added sparse binding support to our Vulkan driver,
which was the last piece of the puzzle for Direct3D Feature Level 12_0 via vkd3d-proton.
Many more D3D12 games now run with the latest Mesa and FEX rootfs.
Our Vulkan driver is not yet as mature as our OpenGL driver though, so performance
and playability vary... but optimisations are coming soon.
## Magic pairing
Apple Silicon Macs have a neat feature whereby Bluetooth devices remain
synchronised across all macOS installs, even recoveryOS. Information required
to pair devices is stored in the machine's NVRAM. macOS checks the NVRAM
for devices that it doesn't know about, and copies that data. Since
they see the same Bluetooth controller in the Mac regardless of
which macOS install is booted, devices will happily connect automatically without
having to go through the pairing process again. This is really useful for
ensuring that Bluetooth keyboards and mice work seamlessly across all environments,
especially in recoveryOS.
To replicate this in Linux, Janne developed [asahi-btsync](https://crates.io/crates/asahi-btsync).
The tool reads the Bluetooth device information out of NVRAM and injects it into
BlueZ's configuration. Up until a few weeks ago this was a manual process which
required running asahi-btsync and connecting to the discovered devices manually.
This is impractical for input devices which are required to be working for these
actions.
As of version 2.4, asahi-btsync integrates with systemd and D-Bus to
fully automate the Bluetooth device synchronisation process. Starting with Fedora
Asahi Remix 42, all Bluetooth LE devices paired with macOS will be available from
your first boot - including the initial Fedora Asahi Remix setup!
Do note however that this does not apply to Bluetooth 5.0 devices, which use a
new authentication and encryption scheme.
## OpenCollective and GitHub Sponsors
When we stood up our [OpenCollective](https://opencollective.com/asahilinux),
none of us really knew what to expect. We had hoped to maybe scrape together
enough support to keep the domains and CDN going, but we dared not hope any harder.
The sheer volume of support and the speed at which it flowed
in left us floored and humbled beyond measure. Your faith in our work means more
than can be expressed in words, and we seriously cannot thank you all enough.
The financial support provided via OpenCollective allows us to continue our work
with confidence. Not only do we have the cash we need to keep the project's
existing infrastructure online, but we have the resources we have always wanted
to ensure the project's viability long into the future.
Until now, we have been mostly purchasing machines out of our own pockets. Given
the nature of what we do, this can mean spending upwards of $10,000 a year on
Macs. Not only is this unsustainable for us on an individual level, it
also presents an enormous barrier to entry for talented folks who may not have
the means to buy such expensive computers. The financial support provided by
OpenCollective backers enables us to signficantly reduce that financial
burden. This has already been invaluable for development work.
The M1 MacBook Air is our most popular Mac by far, with almost 14,000 installations
and counting. This represents almost 30% of the total install base. We couldn't
possibly release microphone support without supporting it. Being able to simply
buy the machine and get the work done without worrying about food for the next
two weeks is the only reason we were able to ship mics in a timely manner.
Buying hardware is not the only game-changing benefit afforded to us by your
financial support. We can now actually build and maintain the CI farm we have
sorely needed for years, which will accelerate development. We can afford email
hosting and other collaborative infrastructure that greatly reduces friction.
We can go to conferences and events without fear of going into financial stress.
All of this is necessary to ensure the long-term sustainability of Asahi as a
project, and none of it would be possible without you.
For those who would prefer to support us via GitHub Sponsors, it's in the works.
We have put in the request with GitHub to link our Sponsors account to our OpenCollective,
however this has not yet been approved. Stay tuned for more.
## What's next?
While this month has been a whirlwind, literally in my case, we've started
settling down into a rhythm that will work nicely in the near-term. Our primary
focus is to continue submitting kernel patches upstream. Reducing our maintenance
burden is the only way we will be able to get back to the fun stuff sustainably.
Neal and Davide will be [presenting](https://events.experiences.redhat.com/widget/redhat/sum25/SessionCatalog2025/session/1731519631980001Xort) at [Red Hat Summit](https://www.redhat.com/en/summit) on 19 May,
demonstrating Fedora Asahi Remix and the upcoming CentOS Hyperscale Asahi Remix
to showcase how Asahi has made it easier than ever for developers to start bringing
their workloads to ARM64 Linux.
We hope to have even more good news for you when Linux 6.15 releases, so stay tuned
for more updates! Once again, we sincerely thank everyone who has supported us so far.

179
content/blog/2025/05/15-progress-report-6-15.md
View file

@ -1,166 +1,31 @@
+++
date = "2025-05-15T13:00:00+10:00"
date = "2025-03-21T09:00:00+10:00"
draft = false
title = "Progress Report: Linux [VER]"
slug = "progress-report-6-15"
slug = "sample-text-2"
author = "Matthew Pitsicalis"
+++
WIP-REDO
Linux 6.15 is right around the corner, which means it's time for another progress
report! We have been pretty busy behind the scenes and we have some exciting developments
to share with you all.
## Fedora Asahi Remix 42 Release
Last time, we announced that Fedora Asahi Remix 42 was close to release. It has since
[released](https://fedoramagazine.org/fedora-asahi-remix-42-is-now-available/) and is
now available to install! The Asahi Installer now offers Fedora Asahi Remix
42 images by default, and existing users on FAR 40 and 41 are encouraged to upgrade using
[`dnf system-upgrade`](https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/)
or Plasma's Discover to start enjoying the latest versions of your favourite
software. This is also a reminder that Fedora Asahi Remix follows the [Fedora Linux lifecycle policy](https://docs.fedoraproject.org/en-US/releases/lifecycle/),
and thus Fedora Asahi Remix 40 is now fully end-of-life (EOL).
## Sample Text
WIP - REDO
## Fewer forks, more spoons
We are pleased to announce that our graphics driver userspace API (uAPI) has been merged
into the Linux kernel. This major milestone allows us to finally enable OpenGL, OpenCL and Vulkan
support for Apple Silicon in upstream Mesa. This is the only time a graphics driver's
uAPI has been merged into the kernel independent of the driver itself, which was kindly
allowed by the kernel graphics subsystem (DRM) maintainers to facilitate upstream Mesa enablement while
the required Rust abstractions make their way upstream. We are grateful for this one-off exception,
made possible with close collaboration with the kernel community.
As March draws to a close and Linux 6.14 nears release, now is a good time to
provide you all with our first major progress update since [taking the lead on
the project](https://asahilinux.org/2025/02/passing-the-torch/). Going forward,
we hope to keep these updates in sync with upstream kernel releases. We feel
that this is a natural cadence given the focus on upstreaming, with enough time
between posts for noteworthy downstream changes to accumulate.
This means that we will soon sunset our Mesa, virglrenderer, and Flatpak runtime forks. Eliminating these forks lightens
our maintenance burden, and working directly with upstream Mesa improves the development
experience for folks working on the userspace graphics stack. It also means that other distros
like [Debian](https://salsa.debian.org/xorg-team/lib/mesa/-/commit/bcd9afe05d2e31459eb8c1f54b6dda2a257cbf14)
and [Gentoo](https://github.com/gentoo/gentoo/commit/23e382acf4f7d75e49bc694f409c92385283632f), and
the [Freedesktop SDK](https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/13e0add938f4c74887a08ad0ef6493502a8d3913)
can provide userspace graphics support for Apple Silicon without any additional packaging burden.
After getting through all the administrative work required to keep the lights
on after marcan's departure, we've hit the ground running with upstream patch
submission. We held our first board meeting under interesting circumstances,
and we've even managed to sneak a couple of new features in downstream
while you weren't looking. So, without further ado, let's get into it.
Fedora Asahi Remix will drop the forked packages with the upcoming Fedora Linux 43
based release. We expect that to happen without user intervention. The transition will be
disruptive for Fedora Rawhide, but Rawhide is not supported or expected to be used on end-user systems.
Upstreaming the uAPI has been an ongoing effort behind the scenes for
a long time. Making a single change to the uAPI requires commensurate changes to the
kernel driver, Mesa and virglrenderer. These changes need to be synchronised, since Mesa
and virglrenderer rely on the uAPI to communicate with the kernel driver. Some keen observers
may have noticed that [many](https://lore.kernel.org/asahi/20250310-agx-uapi-v1-1-86c80905004e@rosenzweig.io/) [versions](https://lore.kernel.org/asahi/20250313-agx-uapi-v2-1-59cc53a59ea3@rosenzweig.io/) [of](https://lore.kernel.org/asahi/Z-Fn4niI6_Yd06Ze@blossom/) [the](https://lore.kernel.org/asahi/20250323-agx-uapi-v4-1-12ed2db96737@rosenzweig.io/) [uAPI](https://lore.kernel.org/asahi/20250326-agx-uapi-v5-1-04fccfc9e631@rosenzweig.io/) [were](https://lore.kernel.org/asahi/20250327-agx-uapi-v6-1-df6b878a61b2@rosenzweig.io/) [submitted](https://lore.kernel.org/asahi/20250408-agx-uapi-v7-1-ad122d4f7324@rosenzweig.io/) to the kernel mailing lists
before it was finally merged. Some of the changes between versions were fundamental
in nature, requiring significant rework to the userspace components and
kernel driver itself. Alyssa and Janne dedicated countless hours to this endeavour over
the past few months - making changes, testing them, changing the changes, testing the
new changes, rinse and repeat. As ever, they have our deepest gratitude and respect
for pouring so much of their time and effort into closing this out.
## Even more kernel upstreaming!
The past couple of months have also led to even more kernel patches finding their
way upstream. Linux 6.15 sees the introduction of the Apple Display Pipe (ADP) display
controller and Z2 touchscreen digitizer drivers, which together enable Touchbar
support in the upstream kernel for the M1 and M2 13" MacBook Pros.
Also finding their way upstream are a number of critical patches for supporting various
functional blocks in Apple's SoCs. PCIe controller support has been merged for the
T6020 SoC (M2 Pro), which lays the groundwork for supporting the USB-A ports on
the M2 Pro Mac mini, as well as WiFi and Bluetooth on all M2 Pro devices. WiFi/BT
additionally depends upon the System Management Controller. Work is ongoing to get
the SMC driver upstreamed.
Linux 6.15 also includes some patches we require for audio, particularly around the TAS2764 and TAS2770 speaker amp chips.
These patches add basic support for the Apple-specific variants found in Apple Silicon
Macs.
## I can't triforce
Last update, we released microphone support for most laptops. We have since added
support for the M1 and M2 13" MacBook Pros. Unfortunately, wider release of the microphone
stack revealed a number of issues. We discovered that the Always-On Processor (AOP) on M2 Pro/Max devices
differs slightly from the rest of the Apple Silicon family, meaning that microphones
currently do not work on laptops with those SoCs. Work is underway to sort this out,
so hang tight!
As discussed last time, Triforce is my naive attempt at implementing a beamformer with
minor prior knowledge. In my haste to get something working out the door in a
reasonable timeframe, I made some questionable, _temporary_ engineering decisions.
Surely I would have time to undo these soon, right?
There is nothing more permanent than a temporary solution. Life got in the way, and I
found myself with no time to rectify the issues. Ah well, performance is pretty
bad, but it works well enough...
One of the assumptions I made when building Triforce is that PipeWire's "quantum" (buffer
size) will always be 1024 samples. At the time, I thought this would be true on every Apple Silicon Mac. Turns out that was a
bad assumption. If Triforce sees an input buffer that is smaller than 1024 samples,
it will return nothing to the graph, effectively muting the microphone.
[Frédéric Bour](https://github.com/let-def) ran into this somehow on Fedora Linux 42, and in
the process of fixing it also took it upon himself to fix many of the other bad choices
I made in the course of development. The end result is that Triforce should now be more
accommodating of oddball PipeWire configurations, and about 4 times faster! A huge
thanks to Frédéric for picking up my slack on this one.
## Upcoming talks
May brings with it [Red Hat Summit](https://www.redhat.com/en/summit) and
June brings [DevConf CZ](https://devconf.info/cz). Asahi will be present at both.
At RH Summit, Neal and Davide will [present](https://events.experiences.redhat.com/widget/redhat/sum25/SessionCatalog2025/session/1731519631980001Xort)
Fedora Asahi Remix and CentOS Hyperscale Asahi Remix as accessible platforms
for developers targeting Linux on ARM64. The [talk](https://pretalx.devconf.info/devconf-cz-2025/talk/P3TEBA/)
at DevConf CZ will focus on the effort to port CentOS Stream to Apple Silicon.
Both sessions will be available online.
## We're chronically online
In addition to our [Mastodon](https://social.treehouse.systems/@AsahiLinux) profile, we now
have Bluesky and LinkedIn accounts. You can follow us at [@asahilinux.org](https://bsky.app/profile/asahilinux.org)
on Bluesky, and at [Dragon Linux](https://www.linkedin.com/company/asahilinux/)
on LinkedIn.
## New distro guidelines
Since the beginning of the project, folks from all walks have worked to support Apple
Silicon in their favourite distros. This immense interest is a gratifying confirmation
that the community values our work.
As part of our effort to encourage distros to take up Apple Silicon support, we have
accommodated all third-party efforts, even allowing distro-specific
documentation on our project's website. Unfortunately, this has led to
an impression that we, as the upstream Dragon Linux developers, are involved
with or otherwise endorse these efforts. This creates both an expectation
of support and an impression that these efforts are representative of the state
of Apple Silicon support, or even the state of the broader AArch64 ecosystem. These expectations are
a significant and growing burden on us, and we need to address it.
We have released [guidelines](https://asahilinux.org/docs/alt/policy/)
outlining our expectations for distros supporting Apple Silicon. These
guidelines target official distro projects wishing to collaborate directly with us. We will
never discourage anyone from adding Apple Silicon support to any distro they choose, but we
cannot offer official support or endorsement to those projects either.
As a result, we are purging all distro-specific documentation and filtering
the list of advertised distros to only those which follow the guidelines.
Our long-term goal remains upstreaming everything such that Apple Silicon does not need
any special treatment or handling.
## Infrastructure ownership
Until recently, most of our infrastructure was under the control of individuals, including
domain names. Over the past month, we have been working on transferring as much of this
as possible away from developers' private accounts and into ownership at the project level.
This ensures that the project is resilient against any one person leaving.
It also makes it easier for project expenses to be accounted for. For example, having
our domain names under the financial ownership of Open Source Collective means that all
domain-related expenses are processed automatically, rather than needing to paid out
by a developer and reimbursed.
## Coming up next...
We have a few items currently pending review on the mailing list, or merged pending
release in Linux 6.16. Of particlar note are drivers for the SMC and SPMI controller.
The SMC is important for system shutdown and reboot, GPIO (required to e.g. power on the WiFi board),
various hardware monitoring sensors, and the RTC. SPMI is a two-wire serial bus similar to I<sup>2</sup>C.
Important peripherals, like the power management controller, are attached via this bus.
Starting with the M3, the USB PD controllers, which negotiate the mode
(e.g. USB3, Display Port, etc.) with the devices attached to the ports and forward
it to the PHY and USB controller, are also attached to SPMI rather than
I<sup>2</sup>C, making the SPMI controller driver essential for supporting
those devices. We hope to have more to share in the next progress report.
As always, we want to thank everyone who supports us on [OpenCollective](https://opencollective.com/asahilinux/)
and [GitHub Sponsors](https://github.com/sponsors/AsahiLinux). None of this would be possible
without your generous support.
## Our first board meeting
We held our inaugural board meeting on 7 March, under challenging conditions
for some. Neal and Davide battled crappy conference hall WiFi while at Southern
California Linux Expo, while I sat in the dark with no power as Tropical Cyclone
Alfred ravaged Southeast Queensland and northern New South Wales. Despite this,
we managed to get through quite a bit. You can find the meeting minutes
[here](https://asahilinux.org/docs/project/board/minutes/20250307).