Asahi Linux 進捗レポート Linux 7.0
(asahilinux.org)- Apple Silicon向けLinuxサポートは、インストーラー自動化、電力管理、オーディオ、ディスプレイ、M3有効化まで複数の軸で同時に前進している
- Asahi Installer は、イメージマニフェストをコードベースから分離し、GitHub workflowデプロイを導入して、より頻繁に更新できるようになった。0.8.0では m1n1 stage 1 の更新、Mac Proインストール対応、ファームウェア更新モードを追加した
- ALS補正ファームウェア は macOS から抽出し、インストール後でも再更新できるようになった。Bluetoothオーディオの途切れは Broadcom coexistence コマンド対応で解消され、PMP対応は M1 Pro でアイドル時消費電力を約0.5W削減した
- VRR対応 は Apple DCP の制約により、まだ userspace に正常には公開されないが、pull request がマージされればカーネルモジュールパラメータで強制有効化できるようになる。オーディオスタックの upstream 作業により、bus keeper 汎用APIと CS42L84 の追加サンプルレート対応も入った
- M3対応範囲 は PCIe、入力デバイス、RTC、reboot controller、NVMe まで広がり、Fedora Asahi Remix 44 は新しい Plasma ベースのインストールフローとともに Fedora 44 の時期に合わせてリリースを維持する
インストーラー自動化とファームウェア更新
- 約2年間ほとんど更新されていなかった Asahi Installer は、手動リリース手順とCDN管理者権限への依存のため、更新周期が長くなっており、2024年6月タグ以降の変更蓄積も大きくなっていた
- UEFI専用インストールでは m1n1 stage 1、Devicetree、U-Boot だけをインストールするため、インストーラーバンドル内の Devicetree がカーネルの期待値と食い違うと、起動自体ができなくなる
- upstream 進行中に Devicetree バインディングが変更され、不一致が蓄積していたうえ、kernel 6.18 では Apple USB 関連の変更が多く、ライブメディアで 6.18 以降を起動できなくなった
- インストール可能なイメージマニフェストを
asahi-installer-dataに分離し、インストーラーのコードベースとは独立して更新できるように変わった asahi-installerの配布は、現在は GitHub workflow により自動化されているmainブランチへの push はhttps://alx.sh/devに自動ビルド・アップロードされる- GitHub タグの push は
https://alx.shに自動デプロイされる
- 最新の 0.8.0 は、同梱された m1n1 stage 1 を 1.5.2 に引き上げ、Mac Pro インストール対応とファームウェア更新モードを追加した
ALSとファームウェア抽出
- Apple の True Tone 環境では、周囲の明るさだけでなく照明の色特性まで測定する必要があるため、ALSデータ処理と補正精度が重要になる
- AOP と ALS ドライバー自体はすでに動作していたが、補正データ なしでは AOP が出す ALS 生データの精度が低くなる
- この補正データは実行時に AOP へ読み込ませる必要があるバイナリ blob であり、再配布できないため、インストール時に macOS から取得しなければならない
- Asahi Installer は Linux に必要なファームウェアを集めて EFI System Partition に保存し、Dracut モジュールがそれを
/lib/firmware/配下のサブディレクトリとしてマウントして、ドライバーが見つけられるようにしている - すでにインストール済みの後で追加ファームウェアが必要になる問題を防ぐため、インストーラーは vendor firmware package の自動更新 に対応するよう変更された
- ALS からは、macOS または macOS Recovery で起動した後にインストーラーを再実行し、プロンプトに従えば必要なファームウェアを更新できる
- ALS対応とその後のファームウェアアップグレードには、Asahi kernel 6.19 以上と
iio-sensor-proxyが必要となる
電力管理とPMP
- アイドル時電力消費は、特に Pro/Max/Ultra SoC で継続的な問題であり、このプラットフォームの電力管理は PMGR と PMP が複雑に絡み合う構造になっている
- PMGR は SoC 電力ドメインのオン・オフを担当し、PMP は SoC ブロックとアプリケーションコアが共有メモリで渡す 電力状態レポート を受け取って処理する
- PMP が起動していないとこのレポートを読めず、一部の電力管理機能も動作しなくなる
- chaos_princess が作成した PMP 対応ドライバーは、SoC ブロックと PMGR のレポートを PMP が受け取れるようにし、14インチ M1 Pro MacBook Pro のアイドル状態で 約0.5W削減 を達成した
- これはアイドル時電力を約20%削減したことに相当する
- macOS 水準のアイドル・スリープ時間に到達するにはまだ追加作業が必要だが、今回の変更は大きな前進に近い
- ベースの M1 は後続世代と互換性のない 旧型PMPバリアント を使っており、dd-dreams がその対応を進めている
- PMP はまだすべての対応デバイスで検証されておらず、upstream にマージされるまではデフォルト有効化する予定もない
- Devicetree を修正できるユーザーは、デバイス DTS に
APPLE_USE_PMPを定義して有効化できる
- Devicetree を修正できるユーザーは、デバイス DTS に
Bluetoothオーディオ途切れの修正
- Bluetooth と WiFi は同じ 2.4GHz帯 を共有するため干渉が起きやすく、オーディオストリームのように遅延と連続性が重要な接続には、より高い優先度が必要になる
- Broadcom の coexistence 設定は Bluetooth HCI の vendor-specific 拡張コマンド で処理されるが、upstream Linux カーネルはこれをサポートしておらず、Bluetooth スキャン時にオーディオパケット損失が発生していた
- KDE Connect が Bluetooth スキャンを引き起こすと、音声ドロップが起きることがあった
- chaos_princess がこのコマンド対応をカーネルの Bluetooth スタックに追加し、BlueZ はすべてのオーディオストリームを high priority として扱うため、ストリーミング中に必要なコマンドが自動的にトリガーされる
- その結果、Bluetooth オーディオのドロップアウトは発生しなくなった
DCPとVRR
- DCP ファームウェアインターフェースは非常に大きく、バージョンごとに不安定で、これまで基本的なディスプレイ対応の後はほかのハードウェア作業が優先されてきたため、VRR のような機能は残されたままだった
- VRR 対応には、ディスプレイコントローラーとディスプレイ間の特殊パケット交換、フレーム表示タイミングに応じた vertical blanking 調整、ディスプレイ側の VRR capability 広告、そして KMS 連携がすべて必要となる
- 追跡の過程で、外部ディスプレイの電源投入時に 0 に設定していた DCP パラメータが、VRR on/off 時には
0x300000と0x0の間で切り替わることが判明した- テスト用ディスプレイの最小リフレッシュレートは 48Hz で、DCP 固定小数点形式では 48 は
0x300000だった - このパラメータは電源シーケンス用ではなく、VRR最小リフレッシュレートのトグル であり、modeset 前に 0 を入れると VRR 無効化につながっていた
- テスト用ディスプレイの最小リフレッシュレートは 48Hz で、DCP 固定小数点形式では 48 は
- MacBook Pro の ProMotion 内蔵ディスプレイも同じ方法で有効化されるが、内蔵パネルは EDID/DisplayID を広告しないため、Linux ドライバーが内部 LCD かどうかを判断して必要な属性を 静的に設定 することになる
- VESA DisplayPort Adaptive Sync と KMS API は VRR 状態切り替え時の modeset 要求を許容しないが、Apple DCP はこれを回避できない
- この制約により、VRR を userspace に正常に公開できず、KWin もそのようなインターフェースを無視する
- 現在は pull request がマージされれば、
appledrm.force_vrrカーネルモジュールパラメータで VRR強制有効化 ができるようになる- ディスプレイが VRR をサポートしていれば、DCP は KMS や compositor に通知せず VRR を使用する
- KWin ではうまく動作したが、ほかの compositor では体験が異なる可能性がある
- HDMI 側では VRR 切り替え間の modeset を禁止しておらず、Intel などほかのディスプレイコントローラーも同様に動作する
- upstream では VRR モードを常時オンにする方式、または切り替え中の modeset を許可する方式について議論が進んでおり、方向性が定まれば期待される形で VRR を公開する予定だ
オーディオスタックのupstream化とサンプルレート拡張
- オーディオスタック全体の upstream 作業は継続しており、Cirrus Logic と Texas Instruments 関連のヘッドホンジャック・スピーカーアンプドライバー、I2S 周辺機器、Apple DMA コントローラー変更はすでにマージされている
- このプラットフォームのスピーカー保護は、TI アンプが I2S で電圧・電流を SoC に送り、スピーカーの Thiele/Small Parameters と組み合わせてボイスコイル温度を計算する構造になっている
- macOS では CoreAudio が、Linux では
speakersafetydがこれを担当する
- macOS では CoreAudio が、Linux では
- 複数のアンプの data transmit ピンが直列接続され、左右ラインが OR 結合される構造では、片側が送信しているときにもう片側が logic low を保証する必要があるため、bus keeper 設定が必要になる
- これまではアンプチップドライバーと専用 Devicetree バインディングで bus keeper を扱っていたが、upstream には制約が強すぎたため、汎用APIに変更された
- これにより、どの ASoC コンポーネントでも設定可能な bus keeper の存在を公開でき、platform ドライバーが実行時に必要な設定を適用できる
- このパッチセットは Linux 7.1 にマージされた
- Apple 専用バリアントチップのサポートも引き続き広がっている
- TI スピーカーアンプは TAS2764、TAS2770 upstream ドライバーに比較的無理なく Apple バリアント対応を追加した
- CS42L84 は CS42L42 との差異が大きく、専用の Linux ドライバーが必要だったが、すでに upstream に取り込まれている
- macOS トレースだけを基準にすると、macOS が使う機能しか公開されないという限界があり、CS42L84 も当初は 48kHz と 96kHz のみのサポートになっていた
- この制約により、PipeWire がほかのストリームをリサンプリングする必要が生じ、CPU とバッテリー消費が増え、音質も低下していた
- CS42L42 データシートにあるほかの一般的なサンプルレート値を CS42L84 ドライバーに適用した結果、ヘッドホンジャックの入力・出力の両方で 44.1、88.2、176.4、192kHz のハードウェアサポートが動作した
- このパッチは upstream に提出され、Linux 7.1 にマージされ、Asahi kernel 6.19.9 にもバックポートされた
M3対応拡大
- Asahi カーネルツリーには、M3デバイス 向けの追加ハードウェア有効化パッチも入ってきている
- 対応範囲は PCIe、MacBook キーボードとトラックパッド、SMC ベースの RTC と reboot controller、NVMe controller まで拡大した
- Michael Reeves と Alyssa Milburn の作業により、M3 の Linux 対応水準は、最初の Asahi Linux alpha for M1 と おおむね同程度の段階 まで引き上げられた
- Asahi Installer で M3 インストールをただちに開放する準備はまだ完了しておらず、引き続き進行中である
Fedora Asahi Remix 44
- Fedora Asahi Remix 43 の遅延にもかかわらず、Fedora Asahi Remix 44 は 4月28日の Fedora Linux 44 と同日、または数日以内の時期にリリースする計画を維持している
- 新しい KDE Plasma ベースのインストールは、Plasma 6.6 の新機能を活用する
- Plasma Setup が既存の Calamares ベース設定ウィザードを置き換え、Plasma ネイティブのアカウント作成・システム設定フローを提供する
- Plasma Login Manager がデフォルトの greeter と session manager になり、SDDM を置き換える
- この変更は 新規インストールのみに 適用され、以前の Fedora Asahi Remix からアップグレードしたユーザーの設定は変わらない
- Fedora Asahi Remix 44 は vendored Mesa と virglrenderer パッケージを終了する
- まだ手動で切り替えていないユーザーは、upstream Fedora リポジトリの Mesa と virglrenderer パッケージへ自動移行される
支援とインフラサポート
- 支援は OpenCollective と GitHub Sponsors で引き続き受け付けている
- Bunny はプロジェクト初期から 無料のCDNとホスティングサービス を提供している
1件のコメント
Hacker Newsの反応
CS42L84 は macOS では 48/96 kHz のみを使う設定になっていたが、CS42L42 のデータシートにある別のサンプルレート値をドライバに入れてみたところ、そのまま動作したとのこと
ヘッドホンジャックの入出力で 44.1/88.2/176.4/192 kHz をサポートするパッチが upstream に入り、7.1 にマージされ、Asahi kernel 6.19.9 にもバックポートされてすぐ使えるようになった
チップの追跡とリバースエンジニアリングが本当に впечат象的だ
Apple は電力効率にこだわる会社なのに、なぜ今もこうしているのか気になる
Asahi チームの技術記事と成果は本当にすごいが、いまだにこれが独立したプロジェクトとして残っており、kernel mainline や Ubuntu、Debian、Fedora のような主流ディストリビューションの中で継続される形ではない点は少し心配
リバースエンジニアリングのプロジェクトは 80% までは有用な結果を出しやすくても、一般ユーザーに十分磨き込まれた95% の完成度まで行くには、ほぼ同じレベルの骨の折れる細かな作業がさらに必要になる
最近進展が遅くなった大きな理由も diff の数を減らすことに集中したためで、かなり多くの作業がすでに mainline kernel に入っている
Asahi は新機能を試す場の役割もしている
Apple は Asahi Linux のために安定性やサポートを提供する気がまったくなく、PC 業界のように長期互換性を合わせる理由もないので、今後も Asahi を困らせる変更をしても気にしないだろう
M1 MacBook Air で Asahi をメイン OS として使っていてかなり満足しており、スリープ中にバッテリーが 1 時間あたり 1% 減るような惜しい点があっても、100% 機能完成していないという理由で何もないよりは、今の形のほうがずっとよい
わざわざ一般大衆向けに完璧に磨かれている必要もあまり感じない
Asahi が特別に見えるのは、変わった専用ハードウェアが多く特殊ドライバがたくさん必要だからであって、誰も Linus のツリーで直接開発しているわけではない
結局の目標は、Linux が Apple Silicon をネイティブサポートするようにすること
このプロジェクトがこのまま勢いを保ってほしい
Apple ハードウェア + Linux の組み合わせは、最高のハードウェア上で動く最も壊れていない OS のように感じられ、macOS はバグやバージョンごとにひっくり返る変更のせいでどんどん混乱している
体験はとてもスムーズで、もうすぐ出る Framework 13 Pro はバッテリーやトラックパッドも macOS 級、あるいはバッテリーはむしろそれ以上になるのではと期待している
Linux ではいつもオーディオや画面の互換性のために妙なパッチを当てることになり、Windows はバッテリー問題が深刻だった
Linux のチューニングが好きな人の多くは、結局もっとカスタマイズできるMac 的な体験を求めているようにも見える
ディスク I/O がいまひとつで OS にもバグはあっても、少なくとも最新 OS で ML がコンパイルされて動く
一方 rocm はほとんどできていそうなのに、事前ビルド済みパッケージや 2 年以上前の Ubuntu が必要で、もどかしい
https://github.com/ROCm/TheRock/issues/3477
5 ユーロ使うだけでもっとよいキーボードが手に入りそうだ
Apple がなぜこの取り組みに協力せず、文書を公開しないのかよく分からない
競争優位や秘密といった伝統的な理由は、もう説得力が弱いように見える
Apple はハードウェアの利益率が高いので、Linux ユーザーに MacBook を売るだけでも利益になるが、公式にLinux サポートを認めた瞬間、それがそのままサポート責任になる
kernel panic のたびに Genius Bar 訪問が発生し、ドライババグのたびに @AppleSupport が呼ばれるだろうから、今のように非公式のままにしておくのが Apple にとってはハードウェア販売を確保しつつサポート負担を避ける最善のシナリオかもしれない
いちばん騒がしく批判的なユーザー層でありながら規模は小さいという点も、Apple には魅力的でないだろう
社内でも優先順位と無関係な議論を呼び込み続けるのを避けられる
ノートパソコンは複数のハードウェア部品とそれを動かすドライバでできているが、自分が買ったのがハードウェアとドライバが切り離せないパッケージなのか、それとも片方が壊れたときにもう片方を自分で救えるようマニュアルを受け取るべきなのか、という問いになる
ドライバはギアやモーターのように摩耗しないと Apple は主張できるかもしれないが、だからといって仕組みを知る権利まで消えるわけではないと思う
いつか /System/Trackpad.kext が宇宙船に撃ち抜かれて自分でドライバを書くしかなくなったとして、法廷で文書を求めるテストケースが出てきても不思議ではない
Apple にとってこれを支援するのは簡単なことのはずで、コミュニティから得られる好意もかなり大きいだろう
Mac のようなデフォルト体験に焦点を当てた Asahi Remix スピンがあれば興味があるか気になる
cmd を主修飾キーとして使い、Mac 風のショートカットやテーマ、ジェスチャをデフォルトで合わせるようなもの
どのディストリでも手を入れればできるが、よくキュレーションされたデフォルトには別の価値がある
一般的な X/Wayland 環境では、すでに DE 機能側は Cmd が中心で、アプリレベルでは Ctrl が中心なので、そこを変えると重なる部分が多くなる
Claude Code に実装してもらったら、Web 検索して設定ファイルまで作ってくれた
何度も試したが、結局 Ctrl の生活を受け入れ、最後の MacBook も売った
MacBook Pro + Linux という夢の開発マシンを先に現実にするのがハードウェア側なのかソフトウェア側なのか気になる
Asahi がソフトウェア側で先に到達するのか、Framework がハードウェア側で先に到達するのか、見守ることになりそうだ
MacBook Neo + Asahi の組み合わせが出たら本当に強力そう
M3 サポートが upstream のバックログを処理し、ツール類を改善しながら着実に進んでいるのはうれしい
PCIe、MacBook のキーボードとトラックパッド、SMC ベースの RTC と reboot controller、NVMe controller のサポートパッチが Asahi kernel tree に入っており、これによって M3 の Linux サポート水準はおおむねM1 向け最初の Asahi Linux alphaと同じ段階まで上がっている
こうしたプロジェクト報告で継続して突破口が出てきて、実際のユーザーがどこで不便を感じるのかを正確に押さえているのは、Asahi チームが本当に熟練している証拠に見える
近いうちに Asahi に完全に戻りたくなる
M3 alpha が近いという知らせは本当にすばらしく、今後は M4 にも期待したい
一方で、Apple が今年や来年の macOS にまた何をしてくるのかについてはまったく期待していない