Asahi Linux 在 4 月 26 日发布了 Linux 7.0 进展报告。

这里容易误读：这不是 Asahi Linux 发布了一个叫 7.0 的完整发行版。它讲的是 Apple Silicon 上 Linux 适配的底层进展，包括安装器、环境光传感器固件、电源管理、蓝牙共存，以及 DCP 显示控制器。

有意思的地方不在版本号，而在问题变了。

早期 Asahi Linux 最难的是让 M 系列 Mac 启动 Linux。现在更麻烦的是另一批问题：待机耗电、蓝牙耳机掉音、自动亮度、可变刷新率。这些听起来不炫，但决定一台机器能不能长期当主力机。

我的判断是：Asahi Linux 正在靠近“日用可用”，但还卡在两个现实约束上。一个是 Apple 二进制固件必须从本机 macOS 提取；另一个是 DCP 这类私有接口还没有完全吃透。

安装器自动化：少一点手工，少一点断链

Asahi Installer 0.8.0 的核心变化，是把安装器构建和发布改成 GitHub workflow 自动完成。

main 分支推送到开发地址，打 tag 后发布到正式地址。过去发布一次，要手动打包 Python、m1n1 stage 1、安装器，再上传 CDN。旧版安装器标签甚至停在 2024 年 6 月。

这不是普通用户每天都会感知的变化，但对替代发行版维护者很关键。

UEFI-only 安装依赖安装器内置的 Devicetree。上游内核 6.18 之后，Apple USB 子系统绑定发生变化，旧安装器提供的 Devicetree 可能拖住 live media 启动。Gentoo Asahi LiveCD 这类项目，最怕的就是启动链和内核版本错位。

变化具体内容对谁影响最大
安装器 0.8.0自动构建、自动发布发行版维护者少等手工更新
m1n1 stage 1升至 1.5.2降低启动组件错配风险
设备支持新增 Mac Pro 支持Apple Silicon 桌面机用户
固件模式新增 firmware update 模式需要重建固件包的用户

这一步的价值，是把“能不能装上”变得更可维护。

对开发者来说，动作很明确：不要只盯内核版本，也要跟安装器、m1n1 和 Devicetree 的组合。对普通用户来说，如果你用的是非官方 LiveCD 或替代发行版，安装器版本可能比你想的更重要。

固件、电源和蓝牙：日用体验补上来，但不能绕开 macOS

环境光传感器 ALS 已经有 AOP+ALS 驱动基础，但 True Tone 相关校准数据属于 Apple 二进制固件。Asahi 不能随系统直接分发。

这意味着用户不能指望一次 Linux 安装解决所有固件问题。需要时，用户要进入 macOS 或 Recovery，重跑安装器，选择 “Rebuild vendor firmware package”，从本机提取并重建 vendor firmware package。

这是 Apple Silicon Linux 和普通 PC Linux 很不一样的地方。

在普通 PC 上，很多固件可以通过发行版包管理器获得。到了 Asahi 这里，驱动可以写，接口可以逆向，但 Apple 的二进制固件不能由项目替你分发。用户最好保留 macOS 分区，至少保留能进 Recovery 的路径。

电源管理也有进展。chaos_princess 为 PMP 写了驱动，让 SoC 模块和 PMGR 向 Power Management Processor 报告状态。

在 14 英寸 M1 Pro MacBook Pro 上，空闲功耗约下降 0.5W，约等于降低 20% 空闲功耗。这个数字不大，但很实在。空闲功耗少一点，笔记本合盖、待机、轻办公时的体验都会更接近 macOS。

限制也要说清楚：PMP 还没有在所有机型验证，也尚未默认启用。基础 M1 使用较老的 PMP 变体，还需要单独适配。不能把这次结果理解成“所有 Apple Silicon 机器都已经省电 20%”。

蓝牙修复更贴近日常。

修复来自 Broadcom HCI 厂商扩展进入内核蓝牙栈，并配合 BlueZ 把音频流标成高优先级。目标是减少 Wi-Fi 和蓝牙共用 2.4GHz 频段时的音频掉包。

如果你只是跑 Linux benchmark，这件事不显眼。但如果你把 MacBook 接蓝牙耳机开会、写代码、听音频，它就是主力机体验的一部分。

所以，最现实的建议是：想在 Apple Silicon Mac 上长期用 Linux，可以继续跟进；但如果这台机器是唯一主力机，且依赖蓝牙耳机、自动亮度、长续航，仍应观望默认启用和发行版集成情况。现在更像接近可用，不是无脑替换。

DCP 和 VRR：入口找到了，离稳定支持还差一段

显示栈是这次最有技术含量的部分。

Asahi 团队在追踪 DCP 参数时发现，过去被当作外接显示上电流程的一项参数，其实对应最小刷新率和 Adaptive Sync 开关。测试里，把参数设为 0x300000 后，DCP 日志识别出 48Hz 到 165Hz 的 AdaptiveSync 范围。

这说明 VRR 的入口找到了。MacBook Pro 的 ProMotion 内屏也可以用类似方式激活。

但这还不是“VRR 已经成熟”。DCP 固件接口很大，版本也不稳定。Linux 驱动还要把能力暴露到 KMS API，并处理外接屏、内屏、EDID/DisplayID 缺失等差异。

这里的对比很关键：

进展已经看到什么还没解决什么
VRR 参数最小刷新率和 Adaptive Sync 开关含义被识别DCP 接口仍未完全理解
ProMotion 内屏可用类似方式激活还要进入可维护驱动路径
外接显示日志能识别 AdaptiveSync 范围不同屏幕信息缺失时仍要处理
Linux 图形栈方向是接入 KMS API不是简单打开一个开关

对开发者来说，接下来要看的不是“有没有 VRR 截图”，而是代码能否进到可维护状态：参数解释是否稳定，KMS API 暴露是否干净，外接屏和内屏路径是否能统一处理。

对用户来说，判断条件也很清楚：PMP 默认启用、ALS 固件重建流程稳定、VRR 从测试代码进入常规驱动。三件事落地得越多，Apple Silicon 上的 Linux 才越像一台能长期使用的电脑。

回到开头那个问题：Asahi Linux 这次不是靠版本号刷存在感。它在补那些最不容易被截图展示、但每天都会影响体验的短板。

能启动，是破门而入。能省电、不断音、会调光、能稳住显示，才算真正坐下来用。