Asahi Linux 项目已经走到第五个年头了。
说实话，从最初只能通过串口看个 Hello World，
到如今成为 Linux 生态里体验最好的 AArch64 桌面平台，这群极客确实干得漂亮。
但这五年里，有一个问题像幽灵一样缠着他们。
IRC 频道里每周都要问，Matrix 上天天有人催，甚至邮件里都不放过：
“USB-C 投屏到底什么时候支持？”
“我的 MacBook Air 能接 HDMI 吗？”
项目组的人甚至开玩笑说，要把预计日期推迟到宇宙热寂之后。
那句经典的“Done when it's done”（做好了就好）成了标准挡箭牌。
但现在，挡箭牌可以扔掉了。
USB-C 投屏终于来了，但带点“魔法”
它完成了。嗯，算是完成吧。
去年 12 月，Sven 在 39C3 大会上做演示时，现场的大屏幕上跑的正是 Asahi Linux，
而那台 M1 MacBook Air，就是通过一根 USB-C 转 HDMI 线连着 AV 系统。
与此同时，他们悄悄往下游 Linux 树里推了一个叫 fairydust（仙尘）的分支。这名字起得挺有诗意，但背后的工作全是硬骨头。
要让 Apple Silicon 的 USB-C 口吐出图像信号，得伺候好四个硬件块：DCP（显示协处理器）、DPXBAR（显示交叉开关）、ATCPHY（Type-C 物理层）和 ACE（USB-C 电源控制器）。
每一个都需要逆向工程，每一个都要写驱动，还得哄着它们别打架。这绝对是工程奇迹。
但也别急着冲去更新，这东西目前是“裸奔”状态。
现在的 fairydust 分支只能“祝福”机器上的某一个 USB-C 口，想多屏显示？没门。
冷插拔、热插拔也全是坑，颜色不对、模式缺失更是家常便饭。
所以，这版本目前只给那些愿意自己编译内核的开发者，或者胆子特别大的极客。普通用户得再等等。
M3 跑起来了，但全靠 CPU 死撑
如果说 USB-C 投屏是“虽迟但到”，那 M3 的支持现状就是“看着热闹，实则心酸”。
好消息是，M3 系列终于有戏了。
Alyssa Milburn、Michael Reeves 和 Shiz 三位新贡献者冲了进来，在 Janne 的帮助下搞定了初步的设备树。
更有意思的是，他们发现大部分硬件居然不用改代码就能跑！
Michael 甚至已经在 M3 MacBook Air 上成功启动到了 Plasma 桌面。
键盘、触控板、WiFi、硬盘、USB3，全都能用。这听起来是不是像极了当年 M1 刚发布 Beta 版时的样子？是不是觉得正式版马上就要来了？
想多了。
我个人觉得，Asahi 团队在这点上有点“轴”，甚至有点“强迫症”。
他们现在的口碑是“最完整、最精致的 AArch64 桌面体验”，他们绝不打算为了赶进度发一个半成品。
如果你现在强行上 M3，你会遇到什么？
图形环境完全是软件渲染。
这体验有多酸爽？极其慢，极其费电，光是滚动终端里的文字都可能卡顿。
为什么会这样？
因为 M3 的 GPU 架构变了，不仅加了硬件光追和网格着色器，还搞了个动态缓存。
这变化太大了，Alyssa 和 Michael 虽然已经开始逆向 GPU ISA，但这活儿一时半会儿完不了。
更糟糕的是，他们现在还得靠 iBoot 来初始化 DCP，而不是自己直接驱动。这就像借别人的手吃饭，既慢又别扭。
所以，M3 的正式发布？还得等。别问 ETA，问就是“不知道”。
120 Hz 强制开启：有时候“笨”办法才好用
14 和 16 英寸的 MacBook Pro 屏幕很爽，支持 120 Hz。
但在 macOS 上，Apple 把这玩意儿藏在了“ProMotion”这个营销词汇后面，其实就是标准的可变刷新率（VRR）。
你以为在 Linux 里直接选个 120 Hz 的时序就能搞定？
天真。
Apple 的 DCP 非常矫情，除非你在表面交换请求结构里填上三个特定字段，否则它死活只跑 60 Hz。这三个字段看起来像是时间戳，但具体是啥，一直没人搞得清。
这时候，新贡献者 Oliver Bestmann 上场了。
他的思路特别清奇：既然不知道这时间戳具体咋算，那我就随便填个静态值试试。
这听起来很蠢，对吧？
但结果是——它居然真的工作了！
从内核 6.18.4 开始，只要你是 14 或 16 寸 MacBook Pro 用户，就能强制开启 120 Hz。
当然，这方案肯定不是“正统”的。用静态值肯定搞不定真正的 VRR，但这不重要。
重要的是，我们现在有了丝滑的 120 Hz，哪怕它是用一种很“Janky”（粗糙）的方式实现的。
有时候，这种“野路子”反而比正经推导更管用。
性能狂飙：从慢如蜗牛到 355 GB/s
搞定了显示输出，还得回头看性能。
之前 Asahi 的 OpenGL 驱动在处理内存拷贝时，慢得让人怀疑人生。比 Vulkan 慢得多，
慢到什么程度？跑个微基准测试要花一个小时。
原因也很尴尬：OpenGL 居然把活儿丢给了 CPU，而不是像 Vulkan 那样用 GPU 算。
Janne 看不下去了，写了个着色器来处理这个。结果OpenGL 拷贝直接跑满了内存带宽。
但这还不够。
缓冲区的清理操作也是个大头。原来的代码用的是 Mesa 的通用助手，根本没发挥硬件优势。
换成 AGX 优化的函数后，效果炸裂：M1 Ultra 在清理 16 字节对齐的缓冲区时，速度达到了 355 GB/s。
这还没完，
Vulkan 的拷贝虽然本来就快，但也还有挖掘空间。用上优化例程后，小缓冲快了 30%，大缓冲直接翻倍。
这才是我们想看到的性能提升，实打实的硬功夫。
参考链接：
https://asahilinux.org/2026/02/progress-report-6-19/
