【海外記事】 Fedora Asahi Remixの新機能
Fedora Linux 39 + Apple Silicon = Fedora Asahi Remix
Fedora Asahi Remixは、Asahi LinuxプロジェクトとFedoraプロジェクトとの複数年にわたる緊密なコラボレーションの成果です。私たちは、完全に統合されたディストロをお届けするために、改善やバグフィックスをできるだけ早くユーザーにお届けするために緊密に協力し、努力してきました。私たちのAsahiプラットフォーム固有のパッケージはすべてアップストリームのFedoraにあり、Fedora Linux 39で完全にサポートされています。
Fedoraの優れた64-bit ARMサポートと成熟した開発プロセスにより、不要なサプライズのないソリッドで高品質なエクスペリエンスが期待できます。Fedora Asahi Remixは、最新のFedora LinuxリリースであるFedora Linux 39をベースにしています。すべてのM1、M2シリーズのMacBook、Mac Mini、Mac Studio、iMacに対応しています。
Fedora Asahi Remix ❤️ KDE Plasma
私たちは、KDE Plasmaをフラッグシップデスクトップ環境として提供できることを誇りに思っています。最先端のWaylandサポートと高度なカスタマイズ性、Appleハードウェア機能の幅広いサポートにより、KDE PlasmaはApple Siliconで使う喜びを感じさせてくれます。
Night Colorを使って、あなたの睡眠サイクルを妨げないようにしませんか？心配はいりません。トラックパッドの設定を微調整して、より快適に使いたい？すべてシステム設定にあります。画面上のものが大きすぎたり小さすぎたりしていませんか？ディスプレイのスケールを5%刻みで調整できます。私たちはKDEプロジェクトと協力して、プラットフォームサポートを改善するためのバグフィックスと改良を提供し、Calamaresベースのカスタム初期セットアップウィザードも構築しました。
Fedora Linux 39には、最新のパッチと改良が加えられたKDE Plasma 5.27が付属しています。しかし、それだけではありません： さらに改善された KDE Plasma 6 をお届けします。
GNOMEを使いたい？ご心配なく、GNOME 45でカバーできます。また、独自のデスクトップ設定を行いたい場合やヘッドレス・サーバーをセットアップしたい場合は、私たちのServerとMinimalイメージを使えば、思い通りにセットアップを行うことができます。
100% Wayland Experience
KDE愛好家であれGNOME愛好家であれ、Fedora Asahi Remixは100%Wayland環境で、Appleハードウェアに完璧にマッチする最新のデスクトップとディスプレイサーバーのテクノロジーを提供します。macOSのように、ティアリングやグリッチの全くない、バターのように滑らかなデスクトップが得られます。KDE Plasmaビルドでは、ディスプレイのスケールが異なる複数のディスプレイでも、シームレスなHiDPIサポートを体験できます。
また、Waylandエコシステムの今後の改善により、HDRやディスプレイノッチなどの新技術や、適切なディスプレイキャリブレーションをサポートできるようになります。実行するX11アプリがありますか？ご心配なく。XWaylandはレガシー・アプリケーションのブリッジとして利用可能で、完全にサポートされています。
OpenGL, deprecated? Not here
Fedora Asahi Remixは、Apple Silicon用のOpenGL 4.6とOpenGL ES 3.2に準拠した世界初で唯一の認証済みOpenGLを搭載しています。
私たちはオープンなグラフィックス標準をサポートし、公式の業界標準テストスイートに対してテストを行っています。つまり、あなたのアプリやゲームが正しく動作し、意図したとおりにレンダリングされることを確信できるのです。さらに、Vulkanのサポートも準備中です。私たちは、Metalのようなベンダー独自のAPIの上に重ねることで可能になることをはるかに超えて、Apple Siliconグラフィックスの可能性を最大限に引き出すことを目指しています。
最高のLinuxラップトップオーディオ
過去2年間、私たちはデスクトップLinuxエコシステムのための世界初の完全に統合されたDSPソリューションを開拓するために努力してきました。Fedora Asahi Remixをインストールするだけで、セットアップ不要で、すぐに高品質なオーディオを楽しむことができます。PipeWireおよびWirePlumberプロジェクトと協力し、完全自動かつ透過的なDSPコンフィギュレーションのサポートを追加し、8つ以上の異なる機種を個別に測定・校正し、それぞれにカスタマイズされたDSPフィルター構成を設計しました。
社内のBankstown低音ブースト・テクノロジーと、ラウドネスとダイナミック・レンジをフルに安全に提供するためのオープンソースのSmart Amp実装により、Linuxラップトップで聴いたことのない最高のオーディオを実現しました。さらに、DSP処理のスケジューリングと消費電力も最適化されているため、オーディオ再生中のバッテリー寿命も抜群です。
元記事
少し前に Fedora Asahi Remix の最初の安定版リリースをリリースできたことをとても誇りに思います。ここ数ヶ月の沈黙は何だったのかと思われたかもしれません。その答えは、今回のリリースにできるだけ多くの機能を詰め込むことに忙しかったからだ。当初の見積もり時間をかなりオーバーしてしまいましたが（よく言われるように、最後の20％の作業に80％の時間がかかるのです）、新機能に文句を言う人はいません。これがFedora Asahi Remixの新機能です。長いのでスナックでも食べてください。
HDMI - ラインナップの完成（ほぼ！）。
Fedora Asahi Remixのリリースにより、Pro/Max/Ultraの全バリエーションを含むM1とM2世代までのアップルのラインアップに新たに追いついた。新しいチップとマシンのリリースに対応し続けるのは面倒なことで、すべてのチップとプラットフォームを明示的に立ち上げてサポートする必要がある（すべての癖とマジックナンバーを含めて）。さらに、コードの再利用とコンポーザビリティに焦点を当てたアサヒの高いドライバコード標準は、新しいマシンを立ち上げるプロセスを容易にする。
しかし、時には大きな変更もある。M2シリーズのデスクトップ機器のサポートに時間がかかった理由は、ディスプレイ出力だ。はっきり言って、2022年夏にリリースされたM2ラップトップは数週間後にサポートされた。M2 Pro/Maxラップトップのディスプレイ・サポートは、デバイスが使用するDCPファームウェア・バージョン（当初は13.2/13.3、最終的には13.5）のサポートを追加する程度で済んだ。これで、M2 / M2 Pro Mac MinisとM2 Max/Ultra Mac Studios（M2+s）のサポートが残りました。iBootがHDMIを表示しなくなったので、Linuxがロードされる前にデスクトップにディスプレイを表示させるために、ブートローダーm1n1にDisplay Controller Processor (DCP) コードが必要になりました（例：m1n1、u-boot、grub screen）。しかし、M1とは異なり、M2+sのHDMI出力はもはやDCPファームウェアによって管理されておらず、特にDCPはもはや完全なeDP -> DP2HDMIセットアップを処理しない。例えば、M2 Mac MiniのDCPはUSB-C/Thunderboltポートにルーティングできるようになりました。これにより、M2 Mac MiniはThunderbolt 4の認証を受けています。しかし、私たちのベアメタルm1n1でこれをすべて行うと、かなり複雑さが増します。
m1n1 の既存の DCP iBoot エンドポイント/プロトコル・サポートに加えて、AP <=> DCP eDP セットアップおよびルーティング用の dptx-port エンドポイントと、冗長な syslog メッセージ用のシステム・エンドポイントの 2 つの新しいエンドポイントを実装する必要があります。さらに、(lp)dptx-phyはdptx-portエンドポイントを介して交換されるメッセージに基づいてプログラムされなければならない。最後に、アップルのデバイス・ツリーとマルチダイ・パワー・マネージメントに一貫性がないため、少し複雑になったDPコンフィギュレーションをすべて処理します。
ちょっとした副作用として、HDMI出力が14/16インチのMacbook Proでも動作するようになった！(物理的なHDMIポート、USB-CからHDMIへのケーブルやアダプターは、すべてDPからHDMIへのコンバーターしかありません）。DCPドライバのメンテナであるJanne Grunauは、ブートローダ、デバイスツリー、DCPドライバにおいて、HDMI出力を有効にするためのたゆまぬ作業を行いました。HDMI出力は、M1 Pro/Maxシリーズのラップトップ以来、TODOでした。M2+のデスクトップHDMI出力サポートは、Sven Peterによるリバースエンジニアリングと初期コードに基づいています。特に14/16インチMacbook ProのHDMI出力は、atcphyの既存のDP phyサポートを使用しています。これは基本的に、USBとUSB-CコントローラーのないUSB-Cポート上のDP-altmodeです。この作業の大部分は、今後リリースされるType-C DisplayPort出力サポートに再利用され、オリジナルのM1を含むすべてのチップをカバーする予定です。M2デバイスとラップトップでのHDMIサポートには13.5ファームウェアが必要であることに留意されたい。M2+sのデスクトップとラップトップのHDMI出力は、s2idleの後に確実に電源が入らない（HDMIリプラグで解決できるかもしれない）、4k 60Hzを超える解像度/リフレッシュレートはサポートされていない、HDMIオーディオのサポートは最終化され、すべてのデバイス/SoCでテストされなければならない。
まだサポートされていない唯一のプラットフォームはMac Proだが、おそらくもうあまり残っていないだろう。MacBook Pro」ではなく、「Mac Pro」である。その名前を聞いたことがある人さえほとんどいないだろう。Mac Proは、私たちにとって圧倒的に人気のないMacモデルであり、私たちはもっと緊急にハードウェアを改良する必要がありました。M3はどうなるのでしょう？今年のニュースをお楽しみに
GPU - OpenGL ES 3.1に準拠。
同様に、OpenGL ES 2.0のサポートはOpenGL ES 3.0に引き上げられました。わずか2ヵ月後の2023年8月、M1ファミリーとM2ファミリーのグラフィックス・ハードウェア向けに、世界で唯一の準拠したOpenGL ES 3.1実装であるOpenGL ES 3.1ドライバを出荷しました。
次のステップは？ジオメトリ・シェーダは OpenGL 3.2 と OpenGL ES 3.2 で導入されました。ジオメトリ・シェーダは、1つのプリミティブ（点または三角形など）を形成する頂点のセットを入力として受け取り、次のシェーダ・ステージに送る前に、これらの頂点を適切と思われるように変換します。ジオメトリシェーダが面白いのは、元のプリミティブ（頂点の集合）をまったく異なるプリミティブに変換でき、おそらく最初に与えられたよりも多くの頂点を生成できることです。最新のFedoraリリースでは、OpenGL 3.3という新しいバージョンがあります。3.2 と 3.3 は、ジオメトリーシェーダーのような大きなチケット機能を追加しています。ジオメトリーシェーダーはApple GPUではネイティブにサポートされていないため、それらを正しく実装するにはドライバに工夫が必要です。これは、ジオメトリーシェーダーが、トランスフォームフィードバック、プリミティブのリスタート、間接描画、テッセレーションなどの他の機能と相互作用することによって大きくなります。我々は、コンフォーマンスに含まれる約束である正しさにこだわる。正しい方法で実装することが最も重要であり、それは簡単な方法ではありません。
ジオメトリ・シェーダをハードウェアでサポートしていない場合、どのようにジオメトリ・シェーダを実装するのでしょうか？高度なレベルでは、ジオメトリシェーダをコンピュートシェーダ、プリフィックスサム、間接描画などのプリミティブに変換します。変換フィードバックは、ジオメトリに変換されたコンピュートシェーダ内で処理されます。間接ジオメトリ描画はジオメトリ計算シェーダの間接ディスパッチに変わります。プリミティブのリスタートは、コンピュート・プリパスを使用して GPU 上で展開されます。テッセレーションは（それが解放されたとき）、仕様で要求されているようにジオメトリ・シェーダーに供給されます。しかし、これは速いのでしょうか？場合による。ジオメトリー・シェーダーは、AMDやNVIDIAのデスクトップ・ハードウェアでさえも比較的遅いため、アプリケーション開発者はジオメトリー・シェーダーを避けることをお勧めします。というのも、実際のアプリケーションでは時折ジオメトリ・シェーダを使用することがあり、アプリケーションを壊したくないからだ。しかし、一般的なGPUでも遅いことが知られているため、通常はホットスポットにはなりません。十分な速度が必要なのだ。そして、そうなのだ。
その結果、我々は現在進行中のOpenGL 3.3を、準拠したOpenGL ES 3.1と一緒に出荷しており、これにより、より多くのOpenGLアプリケーションやゲームがAsahi Linux上で動作するようになりました。そして、私たちはここで立ち止まるつもりはありません;-)
Bluetooth - 不具合の修正とM2のサポート
数回のカーネル・マージの後、何人かのユーザーがロジクールのBluetoothマウスが自動的にペアリングしなくなったことに気づいた。私たちの何人かはLinuxではそういうものだと受け入れて、bluetoothctlを使って手動でペアリングを始めたが、Janne Grunnauはそれを何とかしようと決めた。m1n1の超高速、10秒からデスクトップまでのカーネルテストサイクルによって可能になった、パッチを1つ1つ適用してテストする手作業のgit bisectに従って、Janneはカーネルv6.4のBluetooth Low Energy (BLE)ベースのペアリング（Logitechデバイスによって使用される）を後退させる正確なコミットを見つけた。小さなローペースのLinuxサブシステムはいいものだ。
一方、新しいM2 Pro/Max以降のマシンでは、新しいBluetooth/Wi-Fiチップを使用しているため、Bluetoothをサポートするための微調整も必要だった。通常のチップ固有のマジックナンバーはさておき、アップルがBluetoothファームウェアに暗号署名を始めたことが判明した。この問題を解決するのに非常に時間がかかったが、修正は簡単だった。
Wi-Fi - M2/M3のサポートと新機能
Apple MacにはBroadcomのWi-Fiハードウェアが搭載されていますが、Broadcomは（控えめに言っても）オープンソースコミュニティと密接な関係を持っていません。アップストリームのbrcmfmacドライバはありますが、過去数年間は最小限の開発しか行われておらず、ほとんどのメンテナーは活動しておらず、外部からの貢献もほとんどありませんでした。これまで、このドライバに関する私たちの作業のほとんどは、より新しいチップのサポートを可能にすることに限られていた（新しいチップは、しばしば新しいファームウェア・バージョンやサポートが必要なインターフェイスをもたらすため、それ自体が非常に面倒だった）。直近では、最新のアップルM2（およびM3）シリーズマシンで使用されている新しいWi-Fiチップ（BCM4388）をサポートしました。暗号署名されたファームウェアといくつかの新しいプロトコルのサポートが含まれます。さらに、Sonoma (14.x)に同梱されている新しいApple Wi-Fi ファームウェアをサポートするためのバグも修正しました。また、スリープ中にBluetoothがクラッシュする不具合も修正しました（Wi-FiドライバがBluetoothをクラッシュさせるのです。 Broadcomだけに...）。
しかし、新しいチップを導入するだけでは、新しいWi-Fi規格のサポート不足から奇妙なバグや電力／スループットの制限に至るまで、brcmfmacドライバーの残りの問題点を解決することはできない。ありがたいことに、Daniel Berlinはこれらの長年の問題のいくつかを修正し、Asahi LinuxのWi-FiエクスペリエンスとみんなのWi-Fiエクスペリエンスを向上させることを自ら引き受けてくれた。最近、Wifi6と6Eのサポートが追加されました。また、より高速なアクセスポイントに接続した場合、スループットが最大約80Mbpsから最大1200Mbpsに改善された。最後に、低電力スキャンのサポートやその他の機能により、Wi-Fiチップの電力使用量が大幅に削減されました。
トラックパッド - 正しいサイズのレポート
これは簡単だ。すべてのトラックパッドのサイズが14インチMacBook Proのものとして報告されていた長年のバグを修正したのだ。トラックパッドのサポートが追加された当時、私たちはドライバーに単一の寸法をハードコーディングすることから始めました。しかし、それはlibinputに微妙な問題を引き起こすので、最終的にファームウェアから直接トラックパッドの寸法をフェッチするサポートを実装することになった。これで、現在も将来も、すべてのトラックパッドが正しいサイズを報告するようになった。
タッチバー
アップルは過去にも、入力/HIDに関して疑問のある決定を下しています(ᦋ / )。13インチMacbook Proユーザーの皆さんは、彼らのファンクションローが真っ黒で、レンガのように反応しないことに強い感情を抱いていたことでしょう。キーボード・バックライト・ドライバ」で人気の ChaosPrincess が、Apple Z2 タッチスクリーン・ドライバで私たちの Mac に新たな光を与えてくれる。T2マシンでは、T2自体がタッチバーに対応し、通常のキーボード機能列をエミュレートすることができたが、Apple Siliconデバイスではそのような贅沢はできない。タッチバーを点灯させるために、ChaosPrincessはタッチスクリーン・コントローラとディスプレイ出力コントローラ（これはメイン・ディスプレイとは全く別のディスプレイ・コントローラだ...）をリバース・エンジニアリングし、すべてのハードウェアを一緒に動かすためのユーザーランド・デーモンを書かなければならなかった。余談だが、タッチスクリーン・コントローラとディスプレイ・コントローラは、ある種のモバイルiDevicesに搭載されているのと同じIPブロックなので、もし誰かがcheckra1nを使ってiPhoneにフルLinuxを載せたいなら、その作業の一部はこれで完了だ ;)
私たちのRustユーザーランド・タッチバー・デーモンはtiny-dfrです。タッチバーのエコシステムとサードパーティー・アプリの統合に専念する開発者チームがないのは明らかですが、tiny-dfrは最も重要な機能を備えています：F{n}行とメディア・コントロール・キー（明るさ、音量、バックライト、再生など）を表示します。また、これらのキーレイヤーの正確な内容は設定可能なので、お気軽に
NVRAM
パーティションを切り替えた後にBluetoothのペアリングに失敗したり、デフォルト以外のブートパーティションを選択するために電源ボタンを押し続けなければならないのが単に嫌なだけかもしれません。ブートピッカーはどのようにしてMacを特定のボリュームで起動させるのでしょうか？NORフラッシュの内部には不揮発性ランダムアクセスメモリ（NVRAM）セクションがあり、様々なブート関連の環境変数が格納されています。ボリュームを選択すると、ブートピッカーはNVRAMのブートパーティションキーを選択されたボリュームとして設定し、Macは次回の起動時にそこからブートオプションを取得します。NVRAMには、BluetoothのペアリングキーやWiFiの設定も保存されるので、リカバリーモードでも入力デバイスやネットワークがシームレスに接続されます！ChaosPrincessは、Apple Siliconマシンに搭載されているNVRAMチップを操作するツールを開発しました。NVRAMツール群(dnf install asahi-nvram)は、LinuxとmacOSを頻繁に切り替える人には特に興味深いだろう。
asahi-bless： デフォルトと次のブートOSを選択できるようにします。選択したOSを「祝福」します。
asahi-btsync： Bluetoothのペアリング・キーを抽出し、bluezコンフィグを作成します。
asahi-wifisync： WiFiパスワードを抽出し、iwdコンフィグを作成する。
asahi-nvram： nvramコンテンツへの生アクセス。これには注意。いくつかのキーに触れると、DFU Cityへの切符を手に入れることになる。
NVRAMをいじることは危険であり、このツールスイートはまだアクティブに開発中だが、asahi-blessは実戦テスト済みで非常に安全に使え、Macのブートボリュームを変更するのに非常に便利だ。Davide Cavalcaはasahi-blessのGUIフロントエンド（WIP）であるStartup Diskに取り組んでおり、macOSのようなきれいなブートピッカーインターフェースを提供してくれます。さらに、asahi-btsyncはBluetoothのクロスOSペアリング問題を解決するのに非常に便利です。将来的には、BluetoothとWi-Fiの同期がシームレスに双方向で実行されるように、NVRAMがシステムの他の部分とより緊密に統合されることを期待しています。
繰り返しますが、ブート・コンポーネントとディスク・コンポーネントは常に注意深く扱われるべきですが、Apple Siliconの揺るぎないブート・セキュリティ・プラットフォーム設計のおかげで、asahi-nvramを使ってシステムを壊そうと頑張ったとしても、起こりうる絶対的な最悪のケースは、マシンが起動不能になり、別のマシンでリセット（DFU）する必要があるということです。
カメラ
予断を許さないが、優れたDSPがあれば、アップルは数十年前のiPhoneセンサーをピカピカの新型Macに搭載することも可能だ。カメラブロック全体（DisplayPortに接続されたCMOSセンサー、緑色のセキュリティLED、arm64コプロセッサから、生のセンサー出力をフィルタリングするための専用の自社製画像DSPブロックまで）は、内部でまとめて「Image Signal Processor」（ISP）と呼ばれている。明らかに最後の1つ（DSPブロック）だけが "ISP "の説明に当てはまるのに、なぜカメラブロック全体が "ISP "と呼ばれているのか？この名称は、実はかなり理解しやすい。アップルは、10年以上にわたってソニーからイメージセンサーを忠実にアウトソーシングしてきただけでなく、キャプチャー作業の多くをハードウェア（センサー）からソフトウェア（後処理）に委ねてきた。言い換えれば、センサー（デバイスツリーでは720pの2020 M1 MacBook ProはS5l8960xで、iPhone 5Sとしても知られている）をケチって、後処理に頼っているのだ。カメラの正体は、たまたまセンサーを搭載したDSPブロックなのだ。しかし、アップルの画像DSPがいかに優れているか（アップルはカメラが得意なだけに仕方がないのだが......）、あなたは知らなかったに違いない。
作業をハードウェアからソフトウェアに移すことで、複雑さがドライバに移る。12MBのISP RTOSファームウェアの塊と友達になり、3桁に相当するデバイス固有のDSPコマンドと、それらが呼び出されるフィルター・グラフを苦労してリバース・エンジニアリングすれば、LinuxでもAppleの世界トップクラスのイメージDSPを利用して、同じように優れたキャプチャ出力を得ることができる。短くまとめると、5K行以上のカーネルコード、120のオペコード、47のセンサー（全部は使わないけど）、18のパワードメイン（史上最悪のシーケンス）、7つの割り込みチャンネル、2つのグロスバッファハック、そして1つのテディベア。アイリーン、ありがとう。
もし誰かがLinuxを特定のハンドヘルドiDeviceに移植することになり、マルチメディア周辺機器を気にする余裕があれば、ISPドライバがあなたをカバーする。アップルは、アップルのエコシステム全体で同じカメラ・ドライバを使用しているため、これは単なるウェブカメラかもしれないが、我々のドライバは、iPhone 15 Maxに搭載されているSony IMX913までの互換性のあるセンサーをリストアップしている。ISPドライバは、あなたの側で少し追加作業をするだけで、最新かつ最高のiPhoneカメラを駆動できるはずです（ストロボ／フラッシュの処理、フロント／リアの区別、複数のリアチャンネルの同期をお任せします。）
追伸：おそらく現存するLinuxデスクトップで唯一、縦型（FaceTime）ビデオをサポートしているが、そこからいくつかの面白いユーザー空間のバグを発見した。まず、一部のアプリはデフォルトで最も高い垂直解像度になるため、垂直ビデオが提供された場合、予期しない動作になる。さらに、ウェブカメラアプリに緑色の斜線がある場合は、解像度をチェックしてください。アプリがデフォルトで垂直モードに設定されている可能性があり、いくつかのアプリは、ドライバが宣伝している64バイトのストライド（ISPハードウェアが動作する）を尊重していないことがわかりました。スキップされたデータはYUVゼロに初期化され、RGBイコールグリーンに変換されます。私たちのアップストリーム・ファーストのポリシーに従って、アプリを自由に報告してください (GNOME Cheese には現在問題があることが知られています)。
スピーカー
アップルはオーディオの音質を気にする。macOSはあなたのMacに1組のステレオスピーカーが搭載されていると説明しますが、実際にはあなたのMacには6つものスピーカーが搭載されている可能性があります。例えば、14インチと16インチのMacBook Proには、各チャンネルに低音と中音用の2つのウーファーと高音用のツイーターがあり、他のほとんどのラップトップよりも最新のHiFiスピーカーに近い配置になっています。
それでも、物理法則は、小さなスピーカーがどれだけ良い音を出せるかに上限を設けている。アップルは、この限界を克服するためにDSP技術を駆使し、macOSのユーザースペース・オーディオスタック用のプラグインとして実装している。これらのプラグインはLinuxと互換性がないため、私たちはひどいスピーカー音質で我慢するか、アップルのプラグイン・チェインを独自に構築するしかない。私たちは、これを制限と考えるのではなく、Asahi Linuxの実行時にApple Silicon Macの音を良くするという高い目標を設定するチャンスだと考えました。我々は成功したと思っている。
大音量でダイナミックな音を出すために最も重要なのはパワーです。マイクロスピーカーを許容できる音量でまともな音を出すには、かなりハードに駆動する必要がある。これは、マイクロスピーカーが非常にデリケートであるという事実によって複雑になっており、ほんの少しでも大きなパワーをほんの少しでも長い時間押し込むと、永久的な損傷を与えるのに十分なのです。speakersafetydは、世界初（そして唯一）のフリー・オープンソース・ソフトウェアによるスピーカー保護アルゴリズムの実装です。各スピーカーを駆動するアンプICは、スピーカーを通過する電圧と電流をOSに通信します。speakersafetydは、この情報と、マシン内の各スピーカーについて既知のいくつかの電気的および熱的パラメータを使用して、各スピーカーの温度を概算し、追跡します。speakersafetydとその背後にあるカーネルのメカニズムは信じられないほど堅牢で、安全チェーンのどこかが何らかの理由で失敗した場合、カーネルはメルトダウンを防ぐためにフェールセーフになり、スピーカーへのすべての電力をカットする。
安全性？チェックだ！さあ、楽しもう。我々の測定によると、Apple Silicon Macのスピーカーは約200Hzで底をついている。これはおかしい...macOSの下では、アップルは筐体に本格的なサブウーファーを詰め込んでいるようだ！どうしてこうなるのか？結論から言うと、人間の脳は基本的にドロドロしている。脳は、倍音を弄ることで実際には存在しない周波数が聞こえるように騙すことができ、アップルがMacBookの低音域のレスポンスを拡張するために行っているのは、まさにこれなのだ。James Calligerosは、これらのスピーカーが生み出す周波数特性をフラットにする標準的なEQフィルターに加えて、Bankstownという低音エクステンダーを開発した！
最後に、PipewireとWireplumberの開発者と協力して、カスタムEQとDSPコンフィギュレーションを自動的にロードし、他のアプリケーションから "生 "出力を隠すソリューションを開発しました。この作業は非常に重要でした。デフォルトのデスクトップ体験が、不具合やハックの脆弱なコレクションになることは避けたかったからです。ログインするだけで、スピーカーは意図したとおりに動作します！手作業は必要ありません。私たちが設計し、アップストリームしたメカニズムは一般的なもので、同様の複雑な処理を必要とするあらゆるデバイスの駆動に使用できる。
これは氷山の一角です。スピーカー・サポートまでの道のりをより詳しく紹介する予定ですので、ご期待ください！
エネルギーを考慮したスケジューリング
アップル・シリコンは、電力効率では文句なしのチャンピオンだ。macOSを搭載したMacBook Airのバッテリー駆動時間が12～15時間というのは珍しくない。アップルは、ARM64コアから信じられないような数値を引き出すために、秘伝のソースを使った魔法でも使っているのだろうか？そうではない。彼らは、Linuxがかなり以前から可能であったにもかかわらず、これまで誰も利用しなかったトリックを使っているのだ。
ほとんどのx86マルチコアプロセッサは、同一のCPUコアをn回コピーペーストして構成されている。アップル・シリコンはもちろん、パフォーマンス重視のPコアと効率重視のEコアからなるヘテロジニアスシステムだ。Apple Silicon上でタスクをスケジューリングしてみよう。タスクAには10個の「パフォーマンス」が必要だと知らされました（実際の指標は重要ではありません）。デバイスツリーを調べると、パフォーマンスコアは1.2GHzで10のパフォーマンスを提供できるのに対し、効率コアは最大動作ポイントである2.4GHzでしかそれを発揮できないことがわかります。そのため、スケジューラはタスクAをパフォーマンスコアに配置します。パフォーマンスコアは低い動作ポイントで性能要件を満たすことができるからです。
しかし、我々は重大なミスを犯した。Pコアは1.2GHzで3.7Wを消費するのに対し、Eコアは2.4GHzで1.6Wしか消費しないのだ（これが効率という名前の由来である）。スケジューラーはEコアにタスクを配置すべきだったのだ！エネルギー・アウェア・スケジューリングは、スケジューラに各コアが与えられた動作ポイントでどれだけの電力を消費するかを伝えることで、エネルギー消費を最小限に抑えるより良いスケジューリング選択を可能にします。この機能は、スケジューラがタスクの性能要件について正確な予測をしているときには効果的ですが、それができないときにはどうなるでしょうか？
スピーカーのサポートに取り組んでいたとき、PipewireとWireplumberが常にPコアにミススケジューリングされていることがわかりました。デフォルトでは、カーネルはリアルタイムのスレッドに対して、他の何よりも "レイト "にならないことを優先するため、オーディオ処理は、そのリアルタイムの性質上、常にフルパフォーマンスが与えられていた。計算してみたところ、DSPコードを実行するのにフルパフォーマンスに近い性能は必要ないことがわかった。この問題を解決するために、PipewireとWireplumberに、アプリケーションの性能要件を一定の範囲に固定するスケジューラ機能である利用クランピングを使用する機能を与えました。PipewireとWireplumberの最大性能を極端に低く設定し、スケジューラが最低動作時の効率コアを制限するようにした。どちらもまだ完璧に機能し、ユーザーのバッテリー寿命を大幅に節約できる！この素晴らしい機能はあまり活用されていないため、数週間前に私たちが要求するまで、標準のFedoraカーネルでは有効化されていませんでした（CONFIG_UCLAMP_TASK）。この機能は、カーネルのスケジューラがデフォルトで適切な決定をしない場合に、パフォーマンスを最適化するために別の方向にも使用することができます。
EASとユーティライゼーション・クランピングを組み合わせることで、15インチM2 MacBook Airのバッテリー駆動時間は、デスクトップに座っているだけで約6時間だったのが、1080p30のYouTubeで約8～10時間、デスクトップで12～15時間、スクリーンオフのアイドルタイムで25～28時間という驚異的な長さになりました。私たちは、バッテリー駆動時間をさらに延ばすために、まだまだたくさんの裏技を用意しています。ご期待ください！
ユーザースペースとディストロ
kernel-16k - Fedora に群がる
A-for-Alpha Arch Linux ARM (ALARM)の時代には、Asahiカーネルパッケージには2つのフレーバーがありました：Apple SiliconハードウェアがLinuxを実行するために必要な機能を有効にしたベースラインフレーバーと、より実験的な作業を含む "edge "フレーバーです。edgeパッケージは、DCPバックライト/輝度コントロール、システムワイドスリープ、GPUドライバのような魅力的なオファーを予告していたからだ。面白いことに、"edge "はずっと同じgitブランチで、カーネル設定によっていくつかの危険なドライバを無効にしていただけなのだ。しかし、ALARMの終わりには、これらのドライバは成熟しており、十分にテストされていたため、-edgeをインストールするようにみんなに勧めていました。実際、Xorg+ALARMには、GPUドライバがインストールされていない場合、カーソルが数ピクセル上に浮くバグが残っています（-edgeをインストールすると魔法のように消えます）。これらのエッジと非エッジの不一致は、開発者とユーザーを苦しめるだけでした...。
私たちはこのディストロ移行の機会を利用して（fedoraに群がる！）、-edgeを完全に削除しました。edgeフレーバーで提供されていたすべてのコードは安定化され、メインのカーネルフレーバーにリリースされました。Neal Gompa氏によってメンテナンスされている統一Linuxカーネルパッケージは、単一のkernel-16kパッケージの下で以前持っていたすべてを可能にします！さらに、彼はkernel-16kフレーバーのフレームワークをFedora kernelパッケージに寄贈しており、カーネル作業がアップストリームに上陸すれば、将来的に有効になります。
カーネルからユーザーランド、そしてディストロへ...
ワイドバイン - ネットフリックスとスポティファイをアサヒで
NetflixやSpotifyが動かなければ、デスクトップは意味がない？メディア配信サービスでは、保護されたプレミアム・コンテンツを配信するためにデジタル著作権管理（DRM）システムを必要とすることが多い。アップルはNetflixと直接協力し、"FairPlay "と呼ばれるカスタムDRMソリューションを導入しているが、FairPlayはLinux上には存在せず、ハードウェアの制限により、修正されていないmacOSのインストールに限られている。それでも、多くの人がSpotifyを必要としている。WidevineはGoogle独自の「クロスプラットフォーム」コンテンツ保護ソリューションなので、Widevine blobをインストールするだけで、NetflixとSpotifyは動作するはずだ。残念ながら、グーグルが公式にサポートしていないプラットフォームにWidevineを単純に「インストール」することはできない。
ごく最近、Widevineを搭載したARM64 Linuxっぽいプラットフォームが登場した。残念ながら、ChromeOSは「Linuxっぽい」だけであり、ChromeOSのバイナリは、標準的なARM64デスクトップLinux上でそのままでは実行できない。Widevineのブロブは、メモリページのアライメントの問題とglibcの非互換性の両方を回避するために、手作業でパッチを当てなければならなかった。恐ろしいハックであるにもかかわらず、我々はそれを信頼できるユーザーフレンドリーなインストーラーにパッケージ化することができた。全プロセスをmeme形式で要約することができますが、David Buchananのオリジナルの文章をこちらでチェックすることもできます。すべての人にNetflixとSpotifyを。
OpenH264 - 弁護士はこのH.264のトリックが大好きです。
marcanはAsahiのシームレスなアウトオブボックスエクスペリエンスに誇りを持っており、H.264はビデオのJPEGまたは「フォールバックコーデック」であるため、アウトオブボックスのH.264サポートは必須でした。Fedoraは、シスコのOpenH264経由でH.264をサポートしています。これは、コンパイル済みのバイナリとして配布されるオープンソースのH.264実装です。シスコシステムズは、バイナリが彼らのリポジトリから直接ダウンロードされインストールされる限り、適切なライセンス使用料をカバーします。従来、これは、ユーザーが Fedora Linux をインストールした後、手動で OpenH264 をインストールしなければならなかったことを意味します。
私たちのAsahi Linuxインストーラーは、とにかくインターネットから直接インストールするので、私たちは、インストールプロセスの一部として、これらのコーデック・パッケージをCiscoのサーバーから直接事前ダウンロードするサポートを追加しました。その結果、Fedora Asahi Remixは、箱から出してすぐにH.264を搭載し、完全に弁護士の承認を得て出荷される最初のFedoraスピンとなりました。
他の特許コーデックを自己責任で使用したい場合は、RPM Fusionのlibavcodec-freeworldパッケージなどのサードパーティリポジトリからインストールしてください。RPM FusionはFedoraやAsahi Linuxとは関係ありません。
進行中の仕事
では、私たちが用意しているいくつかのトリックを紹介しよう。これらは2024年のいつかに届くかもしれないし、届かないかもしれない。
ハードウェアビデオデコード
OpenH264は定義上H.264をデコードするかもしれないが、H.265/HEVCをデコードすることはできない。OpenH264は、もっと速くなる可能性もある。SIMDコードはほとんどないし、ARM64 SIMDはもっと少ない（Janneなら知っているだろう...）。スピーカーのサポートがリリースされたことで、高速、高品質、省電力なビデオデコードの必要性が高まっている。Mシリーズコアのソフトウェアデコードは、いくつかのハードウェアデコーダーよりも高速ですが、ラップトップのバッテリーが放出する熱に変換される速度がmacOSよりも明らかに速いと報告するユーザーもいます。私たちは、少なくともmacOSの効率に匹敵する数字を出したいと考えています。
Apple Video Decoderは、ビデオのデコードに特化したカスタム命令セットによって駆動されるマルチフォーマット・プログラマブル・ハードウェアである。AVDは、その複雑さにもかかわらず、奇妙なことに、低レベルのデコードロジックを処理するファームウェアがないため、文字通りすべてのビットを自分たちでREしなければならない（副作用として、ドライバ／ファームウェアスタック全体が完全にオープンソースになる）。ビデオコーデック規格は880ページのマニュアルの化け物であり、それは最も簡単な努力ではない。Eileenのavdレポは現在、H.264 High Profile、High 4:2:2 Profile、High 10 Profile、High 10 4:2:2 Profileを誇っており、機能だけならopenh264に勝る。HEVCはコンフォーマンスに近づいている。VP9の概念実証が存在する。
もう一つのハードルは、Linuxのビデオ・ハードウェア・アクセラレーションAPIである。現在のオプションでは、デコード・ロジックのかなりの部分を処理するファームウェアを持たないビデオ・デコーダ・ドライバの要求をすべて処理することはまだできない。V4L2？VA-API？Vulkan？2024年に答えが出るだろう。
"スチームを走らせられるか？"
アップル・シリコンのデバイスは16Kページを使用しているが、それ以外の（x86）世界は4Kで動作している。アップル・シリコンを4Kカーネルで実行することは技術的には可能ですが、侵襲的で議論の余地のあるアップストリームの変更を数多く必要とし、パフォーマンスに大きな影響を及ぼします。より良いアプローチは、ホストをネイティブの16Kカーネルで実行し、問題のあるワークロードにはVMで4Kカーネルを使用することだろう。
しかし、VMの3D性能はそれほど良くありません。そうだろうか？XDC 2022でロブ・クラークは、"DRMネイティブ・コンテキスト "と呼ばれる技術により、VM内の3Dアクセラレーションでネイティブに近い性能を達成できることを実証した。DRMネイティブ・コンテキストは、DRMドライバごとに個別に実装する必要がある。これは非常に重要なプロジェクトであり、複数のコンポーネントの変更を伴う。Mesaとvirglrendererの両方で、asahi/agxドライバ用のfreedrenoに関するRob Clarkの仕事と同等のものを実装する必要があります。また、virtio-gpu+rutabaga をサポートするために libkrun (VM の起動と駆動に使われる軽量 VMM) を拡張する必要があります。）
この記事を書いている時点では、virglrendererのMRとlibkrunのPRが必要な部分を追加している。また、ダウンストリームパッチを使って試してみるための手順が書かれたブログポストもある。Sergio Lopezは、今後数ヶ月のうちに、すべてをアップストリームにマージし、Fedora Asahiですぐに使えるように出荷したいと考えています
DP Alt Mode & Thunderbolt
17:30 <sven>: dp altmodeとthunderboltが現在進行中で、2024年に登場する予定であることにも触れてください。
今日インストールする！
私たちが取り組んできたことのいくつかを楽しんでいただけたなら幸いです。Fedora Asahi Remixのアナウンスページや、新しいユーザーガイドのチェックもお忘れなく。ご自分の目で確かめてください。今すぐインストール
curl https://alx.sh | sh
アイリーン・ユン - 2024-01-12
この記事が気に入ったらサポートをしてみませんか？