2026/04/26 19:50
朝日リニクス プログレス リンックス 7.0
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Asahi Linux プロジェクトは、6.x シリーズを 3 年間開発し続けた後、Linux カーネル 7.0 のリリースにより重要なマイルストーンに到達しました。このアップデートでは、PCIe コントローラー、NVMe ストレージ、キーボード、トラックパッド、SMC ベースのリブートコントローラーにおける長年の問題が解消され、Apple M3 Mac 向けの包括的なサポートが実装されました。初期モデルに対する重要な改善点としては、Broadcom の共存拡張機能による Bluetooth オーディオの断続現象への修正、環境光センサーに対する ALS ドライバーのサポート強化、新規 PMP ドライバーによって M1 Pro/Max/Ultra チップでのアイドル時の電力消費を 20% 削減した点が挙げられます。プロジェクトは、以前 DeviceTree の同期不良により引き起こされていた起動失敗の原因となった手動アップロードから、自動化された GitHub ワークフローへ移行しました。追加のハードウェアサポートには、Texas Instruments のスピーカーアンプやヘッドフォンジャックのオーディオレートの改善が含まれます。今後の展望として、Fedora Asahi Remix 44 は 4 月末にリリースされる予定で、KDE Plasma 6.6 ユーザー向けに専用設定ツールの提供を目指しています。これらの進展は、公式 macOS ドライバーに依存することなく、Apple Silicon にとって Linux が信頼できるデスクトップ選択肢であることを確立し、オープンソースのハードウェアエコシステムを拡大するものとなっています。
本文
Linux 7.0 の登場と Asahi プロジェクトの進捗報告
安定化された Linux カーネルシリーズ「6.x」から約三年間が経った後いよいよ、Linux カーネル 7.0 が登場しました。つまり、Asahi プロジェクトでも再び進捗レポートを出す時期が来たことになります！
「全てを自動化する」
代替系ディストリビューションの利用者や鋭い眼光を持つ方々は、Asahi インストーラの変化に気づいたかもしれません。実に二年間にわたり更新を延期してきた末、ついにインストーラの更新版を CDN（コンテンツ配信ネットワーク）へ展開しました。二度年に亘る長期間の放置となりましたが、一体何がこれほど長い時間を要したのでしょうか？
当社のアップストリームインストーラパッケージは、ある種「ルーブ・ゴールドベルグ機構」のようです。インストーラの本体は Python で書かれており、その起動（bootstrap）のために一部のバッシュスクリプトが使われています。「
curl | sh以前までは、インストーラーのリリースを組むためには以下のような手順を踏む必要があり、それは非常に時間のかかる作業でした。
- インストーラーのレポジトリをタグ付けする
- macOS用のPythonビルド版をダウンロードする
- 認証済みコミットから m1n1 を構築する
- Python、m1n1、およびインストーラーをバンドル化する
- インストーラーバンドルを CDN へアップロードする
- CDN のバージョンフラグファイルを更新する
このプロセスには管理者アクセス権限の CDN へのアクセスが必要でした。その結果、私たちは比較的長らくインストーラの更新を押しておくことになり、前回のインストーラータグは 2024年6月のものでした！アップストリーム作業が進み、Device Tree バインディングも変化したため、ディストリビューションを維持する仲間たちにとってはかなり問題となりました。
Asahi インストーラーは UEFI だけのインストールオプションを提供しています。このオプションでは macOS のサイズを縮小し、UEFI エグゼキュータを実行するために必要なもののみをインストールします（m1n1 ステージ 1、Device Trees、U-Boot）。これにより、Gentoo Asahi LiveCD イメージのような特殊な Gentoo Asahi ライブメディアから起動することが可能になります。
fresh な UEFI だけのインストールにある Device Trees はインストーラーバンドル自体から来るため、カーネルはインストーラバンドルに含まれる Device Trees がそのカーネルが expects するものと一致する場合のみ、正常に起動します。Device Tree バインディングがアップストリーム化プロセスの結果として変化するにつれ、時とともに両者は徐々に同期を失い始めました。この状況は kernel 6.18 で頂点に達しました。このバージョンでは m1n1 と Apple USB サブシステム用の Device Tree バインディングの両方に多数の変更が必要となりました。これにより、ライブメディアから kernel 6.18 およびそれ以上のカーネルを起動することが不可能になりました。おっと。
手動で別の更新をリリースする手間をかける代わりに、この問題を恒久解決するために自動化ツールを構築する機会を得ました。
インストール可能なイメージのマニフェストを
asahi-installer-dataasahi-installer最新版であるバージョン 0.8.0 では、バンドルされる m1n1 ステージ 1 バイナリをバージョン 1.5.2 に更新し、Mac Pro 用のインストーラーサポートを導入するとともに、…とつなぐ形でファームウェアアップデートモードを追加しました。
「光センサーを過剰設計するにはどうすればよいのか？」
基本的にスクリーンを搭載した全ての機器には何らかの光センサーが備わっています。これは主に周囲環境に応じた自動的な明るさ調整を可能にするためです。スマートフォンなどのデバイスにおいて、ユーザーが屋外に出ると画面が見づらくなるのを防ぐなど、非常に便利な機能です。最も安価な実装では単純な光抵抗器を使いますが、単に明るさを変えるだけならこれで十分ですが、周囲の照明条件によって影響を受けるのは明るさだけではありません。色再現性はどうかという問題も残りますか？
Apple のデバイスは比較的古くから True Tone ディスプレイ機能を持っています。これは環境の周囲照明の明るさと色特性を測定し、そのデータを基にディスプレイに明るさおよび色変換を適用することで、常に可能な限り正確な内容を表示することを可能にします。これは、蛍光灯管や安価なコールドホワイト LED などの低 Color Rendering Index (CRI) を有する照明器具が存在する環境で特に顕著です。この機能を有効にするには、システムに I2C または他の産業標準バス経由で接続される小型の IC（光センサー）が必要となります。これは基本的なアプリケーションでは十分ですが、Apple が扱う領域においてはいくつか他の考慮事項があります：
- 画面がオンしている間は光センサーが動作しており、その出力の処理は可能に限り効率的であるべきです。
- 最大精度のために光センサーを校正する機能を持たなければなりません。
- 複数の種類の光センサーモデルが使われており、OS はそれらについてあまり気にする必要はありません。
- このプラットフォーム上の他のハードウェア部品と同様に、光センサーにも三文字の接頭辞（ALS）が必要です。
当然のことながら、これらは常時オンプロセッサ (AOP)1 の仕事に適しているように見えます。
chaos_princess に多大なる貢献もあり、動作する AOP+ALS ドライバセットを長年持ってきましたが、AOP が ALS から返す生データは校正なしではかなり不正確です。その校正はバイナリブロッブであり、実行時までに AOP へアップロードする必要があります。それは本質的にファームウェアです。Apple のバイナリを再配布することはできないため、インストール時に macOS から取得し、ドライバが検索する場所として保存しておく必要があります。
これを実現するために、Asahi インストーラーは Linux で必要になるであろう全てのファームウェアを集め、自身が作成する EFI システムパーティション上に格納します。Dracut モジュールはこのパーティションを
/lib/firmware/ALS サポートを有効にする（将来のファームウェアアップグレードのため）には、以下の手順に従ってください：
- Asahi カーネルバージョン 6.19 またはそれより高版本を起動していることを確認してください。
- あなたのディストリビューションが DE の依存関係として
を供給していることを確認してください（Fedora Asahi Remix はこれを満たします）。iio-sensor-proxy - Macをシャットダウンしてください。
- ディスプレイに "Loading startup options" が表示されるまで電源ボタンを押して持ち続けてください（MacBook の場合）か、デスクトップマシンの場合は 5〜7 秒ほどです。
- Apple ブートメニューから「オプション」を選択してください。
- macOS クレデンシャルでログインし、コマンド + シフト + T を押してターミナルを開いてください。
を実行して Asahi インストーラを起動してください。curl https://alx.sh | sh- プロンプトが表示されたら、「Rebuild vendor firmware package」オプションを選択してください。
- インストーラーを終了し、完了したら再起動してください。
「エネルギー危機への対処」
アイドル時の電力消費は、特に Pro/Max/Ultra 系 SoC を搭載したデバイスにおいて継続的な問題です。このプラットフォームの電力管理アーキテクチャは非常に複雑であり、その動作を正常にさせるために多くの動く部品が関わっています。Power Manager (PMGR) が SoC のパワードメインを担当していますが、それに加えて Power Management Processor (PMP) も存在し、…何かやっています？
SoC 全体での電力管理の詳細な低レベル実装は非常に不透明です。PMGR は SoC リージョンのパワーオン/パワーオフを担当しており、動作時にも再設定可能ですが、これは起動時に SoC の一部をパワーオンさせたり、サスペンド/リゾーム時にそれらをパワーオン/オフしたりするために必要です。一方、PMP はより興味深い役割を持っています。多くの SoC ブロックは共有メモリ領域を通じて PMP 直接向けてそのパワー状態を伝えます。また、PMP は PMGR パワードメインがパワーオン/オフされた際にアプリケーションコアからのレポートも受けます。PMP がブートされていない場合、これらのレポートは読み取らず、特定の電力管理機能は動作しません。私たちはこの情報が具体的にどう扱われるかについては正確にわかりませんが、Apple Fabric の電力制御やクロック制御などを含む可能性があります。
PMP をサポートするために chaos_princess は SoC ブロックおよび PMGR からレポートを受け入れるためのドライバを書きました。それだけで、14 インチの M1 Pro MacBook Pro のアイドル時消費電力を約半分（20%）削減することに貢献します！もちろん macOS 水準のアイドル時間とサスペンド時間に達するにはまだ作業が必要ですが、これは大きな前進です。
ベースモデルの M1 SoC を搭載したマシンの PMP は、M1 Pro とそれ以降の SoC に見られるバリアントとは互換性のない古いバリアントを持っています。dd-dreams がこれらのマシンでの PMP サポートを有効化する作業を行っていますので、お楽しみに！
PMP サポートはまだサポートしている全てのマシーンで検証されておらず、アップストリームへマージされるまでデフォルトで有効化することはありません予定です。Devicetree の変更を行うのに慣れたユーザーは、デバイスの Devicetree（例：
t8112-j415.dtsAPPLE_USE_PMP「ブルートゥースの修復！」
ブルートゥースと Wi-Fi は長年にわたり干渉や競合の問題を抱えてきました。両者はほぼ同じ 2.4 GHz帯域を周波数で使用し、通常は一つのデバイス内に同時搭載されています。適切に対処しないと、パケットロスや切断が発生します。この問題に対処するいくつかの戦略が存在します。現代のシステムでは、Wi-Fi とブルートゥースは通常同一コントローラに統合されており、コントローラがアクティブな 2.4 GHz Wi-Fi とブルートゥース接続を同時に監視できます。デフォルトでは、各接続は利用可能なエアタイムの「公平な」シェアを割り当てられますが、レイテンシが重要になる場合や一部の接続で最小限の中断が必要になるときに問題を引き起こす可能性があります。アクティブにオーディオをストリーミングしている接続は、キーボードや 2.4 GHz Wi-Fi ブロードキャストのスキャンよりも優先権を与えなければなりません。
不幸にも Broadcom では何もかも簡単にはいきません。共存構成は Bluetooth Host Controller Interface (HCI) のベンダー固有拡張機能を使用して行われます。これらは以前アップストリーム Linux カーネルでサポートされておらず、その結果、私たちのブルートゥースコントローラが KDE Connect がブルートゥーススキャンをトリガーするとオーディオパケットをドロップしていました。chaos_princess は最近、これらのコマンドに対するカーネル側のブルートゥーススタックへのサポートを追加しました。BlueZ（ユーザスペースのブルートゥースデーモン）が全てのオーディオストリームを高優先度としてマークするため、これらコマンドは接続がオーディオをストリーミングしている際にトリガーされます。これでブルートゥースオーディオの切断問題は過去のものになりました！
「目の前で隠れる」
ディスプレイコントローラ（DCP）との葛藤については、この時点で十分に文書化されています。ファームウェアインターフェースは膨大で、バージョン間で不安定であり、理不尽な形で奇妙に制限されています。基本的なディスプレイサポートを得る程度には十分機能するようになった後、他のハードウェア部品への注目が向き、さらに DCP 作業のための時間を投資することは誰一人として行われませんでした。しかし依然として多くの機能が欠けており、常に質問されるのが可変リフレッシュレート（VRR）です。
VRR サポートは少し複雑なものです。ディスプレイコントローラとディスプレイ間には特別なパケットを使用して通信する必要があり、これは HDMI と DisplayPort で異なります。また、フレームの実現状況に基づいてではなく、セットタイミングモードの公称リフレッシュレートに基づいて垂直空白間隔を「ストレッチ」するようにディスプレイコントローラを構成する必要があります。また、ディスプレイも VRR を機能としてアドバンテイス（発表）し、このすべてが KMS API にワイヤーアップされてユーザースペースがそれらを知っている必要があります。
DCP のファームウェアインターフェースは非常に階層化されています。他のほぼ全ての Apple コプロセッサと同様に RTKit を実行しますが、RTKitの上に Endpoint Interface Client (EPIC) が配置されています。EPIC はそれぞれが独自のアピアースを公開する「サービス」を提供し、これは関数とコールバックから構成されています。各サービスもまたパラメータを持っており、これは様々な動作時の振る舞いを制御するノブのキーバリューストアにほかなりません。これらは「パラメータ設定」API を呼び出すことで変更されます。
初期の DCP ブリッジアップ作業が行われていた際の一つのパラメータは、外部ディスプレイ用に DCP がパワーオンされた際に 0 に設定されていたことが注目されました。これは起動シーケンスの一部であると仮定されました。Linux ドライバープローブシーケンスも同様に、そのパラメータを電源投入ごとに設定するように書かれました。
トレシング中に VRR をオン/オフで切り替えると、同じパラメータが
0x3000000x00x300000Linux DCP ドライバーにコードをハッキングしてこのパラメータを設定しモードセットをトリガーすると、まさに私が望んでいたものが表示されました！
RTKit: syslog message: FramebufferDCP.cpp:5931: IOMFBParameter_adaptive_sync Req minRR = 0x300000, mediaTargetRate = 0x0, Fractional Rate = 0 ... RTKit: syslog message: PPipeDCP_H13P.cpp:12251: IOMFB: AdaptiveSync Range [48Hz, 165Hz]
我々がこの間ずっと設定していたパラメータは電源シーケンスとは全く関係なく、VRR の最小リフレッシュレートのトグルでした。モードセット前にこれを 0 に設定することは、単に DCP に VRR を無効化させるだけです。数百行にも及ぶドライバコードを本質的に二つの関数呼び出しに変えるのも、DCP のような巨大なファームウェアブロッブを持つことの利点の一つです。
ProMotion ディスプレイを搭載した MacBook Pro でもこのテストを行い、同様にアクティブ化するのを確認しました。これは驚きでした。なぜなら、MacBook の内部ディスプレイは DCP が解析するための EDID/DisplayID をアドバンテイスしておらず、通常私たちが表示の VRR 機能を取得・設定する通常の手段です。DCP ファームウェアが完全に理解されていなくても、ノートブックディスプレイには特別な扱いを受けていると疑っています。これを回避するために、Linux ドライバーは接続されたディスプレイが内部 MacBook Pro LCD かどうかを判断し、必要に応じて静的に必要なプロパティを設定します（非存在の EDID から引き出す試みではなく）。
この全てのプロダクション化は少し苦労しました。VESA DisplayPort 規格における Adaptive Sync と KMS API コントラクトは、VRR ステータスの移行のためにモードセットを必要とすることを明確に禁止しています。不幸にも Apple は VESA 規格には無関心か、または DCP がモードセットなしで VRR ステータスを移行できないためでした。このため、私たちは VRR をユーザースペースに公開できませんし、仮に公開しても Kwin などコンポジターはそれがモードセットを必要とするため単に無視します。現時点では、プルリクエストがマージされる際に
appledrm.force_vrrもしあなたのディスプレイが VRR サポートしている場合、DCP は KMS やコンポジターに知らされないままそれを有効化・使用します。Kwin はこれを適切に取り扱うことができますが、他のコンポジターとの経験は異なる可能性があります。また、我々のコンポジターの開発者に対してこの問題についてバグを提起することもしないでください。これはコンポジターが円滑に許容することを強制されていないハックだからです。
しかしそれもすぐに変わるでしょう。HDMI 規格は VRR 遷移間のモードセットを禁止しておらず、他のディスプレイコントローラ（例：Intel など）もこの点で DCP と似た振る舞いを見せています。アップストリームではどのように最善に対処すべきかについて議論が進行中です。ドライバーが無条件に VRR モードを有効化する必要があるか、または遷移間のモードセットを許容するか。前向きな方法がアップストリームで明確になると、私たちは通常の方法で VRR を公開し、コンポジターがこれをいつ有効にするかを判断できるようにします。
「さらに埋め込みオーディオの怪癖」
オーディオスタック全体をアップストリーム化する作業は進行中です。既にこのプラットフォームで使用されるヘッドホンジャックおよびスピーカーアンプチップ用の Cirrus Logic と Texas Instruments ドライバー、I2S パーフェラルと Apple DMA コントローラ用のドライバーの変更がマージされています。
このプラットフォームが特別である理由の一つは、スピーカー自身を破壊しない方法にあります。Apple が使用する Texas Instruments アンプは接続されたスピーカーの電圧と電流を I2S を介して SoC へ返すことができます。これらの値を用いて、接続されたスピーカー（Thiele/Small パラメータ）の文書化された特性セットと共に、コイル温度をその瞬間に算出できます。macOS では CoreAudio がこれを行います。Linux 上では speakersafetyd の役目です。他のデスクトップクラスプラットフォームではこれは行われません。通常は全く行われないか、完全にハードウェアで処理するか、または Sound Open Firmware で OS からほとんど隠されます。
しかしそれだけではありません！アンプチップのデータ送信ピンは他のアンプと直列に接続されています。「左」スピーカーアンプはグループ化され、「右」アンプも同様です。これらのラインはすべて受信側で一つのデータストリームとして結合される必要があるため、ラインは OR されます。これは一方のアンプがデータを伝送しようとしている際に他方のアンプが論理ローグであることが保証されている場合にのみ機能します。これは珍しくなく、Apple が使用するアンプチップにはこのためにバスキーパー（bus keeper）が含まれています。これらはバスが常に特定の状態にあることを保証するために設計された小さな回路です。通常はグラウンドに結ばれています。
もともとこれらの設定は完全にアンプチップのドライバーで行われており、特定の Device Tree バインディングを使用してバスキーパー構成を指定しました。しかしこれはアップストリームに対してあまりにも限定的で柔軟性に欠けていました。代わりに、任意の ASoC 成分が構成可能なバスキーパーを持っていることを公開する汎用 API を作成し、消費側ドライバー（通常は「プラットフォーム」ドライバーであり、物理的なオーディオコンポーネントを統合した一貫性のある「サウンドカード」に結合する）が動作時に必要なようにバスキーパーを設定できるようにしました。バスキーパーは珍しいものではなく、この機能が他の埋め込みスタイルプラットフォームでも有用である可能性があります。この実装を実行したパッチセットは 7.1 でマージされています。
「macOS を越えて」
完全に未文書化されたプラットフォームを起動させる際の課題の一つは、ハードウェアの機能について参照枠がないことです。可能な限り知る限り、ハードウェアは macOS がそれを行うことができると言うか何もできないだけです。ほぼ全ての m1n1 と Linux ドライバーコードは、特定のハードウェアブロックに対して macOS が送信するコマンドを観察し、それを再生することに基づいています。しかし常にそうとは限りません…
Apple は第三パーティのチップベンダーから正確に欲しいものを得るために購買力を惜しまないです。特定のボードレベル修理と Right to Repair インターネットパーソナリティの追跡者は、Apple が Texas Instruments から CD321x シリーズチップを取得する方法を知っています。これらは TI の他の USB-C マキップチップの不適合バリアントであり、公開されたデータシートがなく、大規模に Apple 専売されます。Apple は使用するスピーカーアンプチップに対しても同様の契約を持っている（TI の TAS2764 と TAS2770 のバリアント）。CS42L84 も同様であり、これは Cirrus Logic CS42L42 ヘッドホンジャックチップの Apple 特定バリアントです。ベンダーはこれらのバリアントの存在さえ認めることができません。公開された同様のものとの接続はリークやインターネット探偵仕事を通じてのみ推測できます。
これらのバリアントは公開された対応物と十分似ているため、データシートやドライバー上の情報が有用な参考文献になります。不整合は通常は登録レイアウトがわずかに異なるか、チップの動作全体に影響しない離散機能に限られています。TI スピーカーアンプの場合、アップストリームの TAS2764 と TAS2770 ドライバーに Apple バリアントのサポートを追加し最小の手間でした。
さて、追跡 macOS から始めることは常に有益であり、それらのトレーサを唯一の真実として扱うことをお勧めします。CS42L84 は CS42L42 と十分異なるため、独自の Linux ドライバーが必要で、以来アップストリーム化されました。前述のように、このアプローチは macOS が使用している機能のみを公開することを可能にするという制限を持っています。macOS は CS42L84 を 48 または 96 kHz で動作させるためにプログラムするだけだからです。Linux ドライバーにその二つのサンプルレートをサポートするしかない。これは非常に制限的であり、PipeWire が 48 または 96 kHz以外のオーディオストリームをリサンプリングするために CPU サイクル（そしてそれによりバッテリー寿命）を無駄にするように強制します。これを行うと音質も劣化します。しかし CS42L42 は他の一般的なサンプルレートをサポートしており、登録レイアウトとプログラミングシーケンスは異なりますが、48 kHz と 96 kHz にプログラムされる実際の値はこの二つのチップ間で同じです。CS42L42 データシートのすべての他のサンプルレートの値を取り出して CS42L84 ドライバーに追加したらどうなるでしょうか？なんと、それらのサンプルレートのサポートが得られます！
ヘッドホンジャックの入出力両方の 44.1、88.2、176.4 および 192 kHz サンプルレートへのハードウェアサポートを有効にするパッチは直接アップストリームに提出され、7.1 でマージされました。またこれを Asahi カーネル 6.19.9 にバックポートし、ユーザーが直ちに恩恵を受けることができます。
「さらに M3！」
Asahi カーネルツリーへのパッチも M3 マシンのより多くのハードウェアを有効化するものがあります。これには PCIe、MacBook キーボードとトラックパッドのサポート、SMC ベースの RTC と再起動コントローラー、そして NVMe コントローラーが含まれ、Michael Reeves と Alyssa Milburn による貢献です。これで M3 に対する Linux サポートは M1 の最初の Asahi Linux アルファとほぼ同等のレベルに達しました。
Asahi インストーラー経由での M3 マシンでのインストールを有効にするにはまだ準備できていませんが、進捗があります。お楽しみに！
Fedora Asahi Remix 44
Fedora Asahi Remix 43 を皆様に届ける際の遅延にもかかわらず、2026年4月28日の Fedora Linux 44 と同日または数日以内に Fedora Asahi Remix 44 をリリースする計画は維持されています。今後、新しい KDE Plasma ベースのインストールでは、Plasma 6.6 で搭載された多数の新機能を利用します。
- Plasma Setup は以前の Calamares ベースのセットアップウィザードに取って代わり、ユーザーアカウント作成やシステムセットアップのためのネイティブな Plasma体験を提供します。
- さらに、Plasma Login Manager は現在デフォルトのグリーターとセッションマネージャーとなり、SDDM に取って代わります。これは新しいインストールのみ適用され、以前のバージョンの Fedora Asahi Remix からアップグレードするユーザーの設定は変更されません。
Fedora Asahi Remix 44 では、我々の vendored Mesa および virglrenderer パッケージも廃止されます。既に手動で移行していないユーザーは自動的に、アップストリーム Fedora リポジトリから提供されるアップストリーム Mesa と virglrenderer パッケージへ移行されます。
「次回まで！」
いつも通り、OpenCollective および GitHub Sponsors を通じて我々の仕事をサポートしていただいている皆様に感謝申し上げます。
また、プロジェクトが始まった日からフリー CDN およびホスティングサービスを提供してくださった Bunny にも感謝いたします。
James Calligeros · 2026-4月26日