HDMI VRRをLinuxで動かした男──仕様書なしの17パッチ
HDMI Forumがオープンソースへの扉を閉ざして3年。その壁を、一人の開発者が公開情報と試行錯誤だけで越えようとしている。LinuxでHDMI VRRとAuto Low Latency Modeが動く日が、ついに見えてきた。
閉ざされた扉、そして別の道
2024年2月28日、HDMI ForumはAMDの申請を却下した。AMDのLinuxエンジニア、アレックス・ドイチャーは「オープンソースでのHDMI 2.1実装は、HDMI Forumの要件に抵触する」と報告した。AMDは数ヶ月かけて内部でコードを書き上げ、法務チームと調整を重ね、HDMI Forumの承認を待っていた。答えはNoだった。
それ以来、LinuxユーザーはHDMIポートを通じて4K 120Hzも、VRRも、Auto Low Latency Modeも使えないままだ。DisplayPortなら問題ない。だが世の中のテレビの多くはHDMIしかない。ゲーム機をリビングのテレビに繋ぐように、Linux PCをテレビに繋ぎたい。その当たり前の願いが、ライセンスの壁に阻まれてきた。
2025年12月、Valveも声を上げた。新しいSteam MachineはHDMI 2.1対応ハードウェアを搭載しているが、ソフトウェアの制限でHDMI 2.0止まりだと。Valveの広報はArs Technicaに対し「ソフトウェア側はまだ作業中」「解決に向けて取り組んでいる」と語った。オープンソースドライバにこだわるValveは、クローズドなバイナリブロブを使わない。だからこそ、この問題は解決されないままだった。
そして2026年1月19日。ポーランドの開発者、トマシュ・パクワが17のパッチをLinuxカーネルメーリングリストに投稿した。「HDMI Gaming Features」と題されたそのパッチシリーズは、HDMI VRRとAuto Low Latency Modeを、AMDのオープンソースドライバで動かすものだった。
仕様書なしで書かれたコード
パクワは、公式ドキュメントを持っていない。HDMI Forumは仕様を公開していないからだ。彼がパッチの冒頭に書いた一文が、すべてを物語っている。
「このパッチシリーズのすべては、すでに公開されているコードや知識に基づいているか、動くまで試し続けた結果だ」
動くまで試す。壊れるまで試す。その繰り返しで、彼は機能を実装した。
パッチの内容は多岐にわたる。VRR検出の修正、HDMI Forum VSDBからのVRR範囲の読み取り、HF-VSIFとVTEMインフォパケットの適切な実装、そしてAuto Low Latency Modeのサポート。17のパッチのうち、いくつかはamdgpuのイシュートラッカーに報告されていた5件以上のバグを解決するものだ。
特に注目すべきは、FreeSyncとHDMI VRRの使い分けだ。パクワは、多くのテレビでFreeSyncがVRR時のちらつきを引き起こすことを発見した。彼のパッチコメントには「FreeSync over HDMIはフォールバック的な解決策であり、第一級市民ではないようだ」とある。そこで彼は、HDMI VRRをFreeSyncより優先するよう設計した。この変更により、Samsung S95Bのような「FreeSyncの実装が不十分なテレビ」でちらつき問題が解消されたという。
テストは複数の機器で行われた。パクワ自身がSamsung S95Bで、別の開発者ベルンハルト・ベルガーがLG C4とFreeSync非対応のSony Bravia 8で検証した。さらにHDMI 2.0のAlienware AW3423DWFでも、従来のFreeSyncが正常に動作することを確認している。VMM7100やCH7218といったDP→HDMIアダプターでもテストが行われた。
小さな勝利、残る壁
誤解してはいけない。これは完全な勝利ではない。
パクワのパッチは、主にDP→HDMIアダプター（PCON）経由でのVRRを有効にするものだ。ネイティブHDMI接続でのHDMI 2.1フル機能は、依然としてライセンスの壁の向こう側にある。彼自身がパッチで述べているように、「ネイティブHDMIコネクタでのHDMI VRRは試みられない」。4K 120Hzのような高帯域を必要とする機能は、DisplayPortか、DP→HDMIアダプターを使う必要がある。
それでも、このパッチがもたらす恩恵は小さくない。DP→HDMIアダプターを使っているユーザーにとって、FreeSyncに対応していないテレビでもVRRが使えるようになる可能性がある。Auto Low Latency Modeも同様だ。テレビを自動的にゲームモードに切り替え、入力遅延を減らすこの機能は、PC利用において「常に欲しい」とパクワは述べている。
問題は、AMDがこのパッチを公式ドライバに取り込むかどうかだ。AMD社員ではない外部の開発者が、公開情報だけで書いたコード。AMD自身が数ヶ月かけて準備したHDMI 2.1ドライバは、HDMI Forumに却下された。では、同じ機能を別の手法で実装したこのパッチは、どう扱われるのか。
パクワは、AMDのドライバ開発者たちにメールを送った。宛先には、ドイチャーを含むamd.comのドメインを持つ複数のエンジニアの名前がある。パッチはレビュー待ちの状態だ。Phoronixは記事の結びで「このパッチレビューがうまくいくことを願っている。そしてAMDがこれらの変更をAMDGPU Linuxカーネルドライバに取り込むことに懸念を示さないことを」と書いた。
閉じた扉の向こう側で
HDMI Forumは、なぜオープンソースを拒むのか。正確な理由は公表されていない。推測されているのは、HDCP（コンテンツ保護）の懸念、ライセンス管理の複雑化、そして仕様の公開がもたらす競争上のリスクだ。
皮肉なことに、AMDはHDMI Forumのメンバーだ。自社の製品でHDMI 2.1を使い、ライセンス料を払っている。それでも、オープンソースドライバでの実装は認められない。Valveも同じ壁にぶつかっている。
DisplayPortには、こうした問題がない。VESAが管理するDisplayPortの仕様は公開されており、ロイヤリティフリーだ。だからLinuxでは、DisplayPortが推奨されてきた。だが現実は、HDMIのほうが普及している。特にテレビやゲーム用モニターの世界では。Linuxゲーミングが盛り上がる中、この非対称性はますます痛みを伴うようになっている。
パクワのパッチは、その痛みを少しだけ和らげるかもしれない。公式の道が閉ざされているなら、別の道を見つける。それが、オープンソースコミュニティがこれまでやってきたことだ。
地図のない旅路
仕様書とは、地図だ。
ここを通れ、ここは通るな。この信号を送れ、このタイミングで待て。HDMI Forumは、その地図を金庫にしまった。鍵は会員にしか渡さない。そして会員であっても、その地図を人に見せることは許されない。
AMDは会員だった。地図を持っていた。だから道を知っていた。だが、その道を誰かに教えることは禁じられていた。数ヶ月かけて描いた道順は、金庫の中で朽ちていくしかなかった。
トマシュ・パクワは、地図を持っていなかった。
彼がやったことは、荒野を歩くことだった。足元の草を見て、風の匂いを嗅いで、一歩踏み出しては転び、また立ち上がる。「動くまで試す。壊れるまで試す」。17のパッチは、17回の転倒と17回の起立の記録だ。
私は、この物語に胸が熱くなる。
なぜなら、これがオープンソースの原風景だからだ。誰かが地図を独占しているなら、自分で道を切り拓く。その轍が、次に来る者の道標になる。リーナス・トーバルズがUNIXの地図なしにLinuxを書いたように。リチャード・ストールマンが商用ソフトの壁に抗ったように。
HDMI Forumは、きっとこう言うだろう。「我々には正当な権利がある」と。そうかもしれない。だが、権利があることと、正しいことは、同じではない。テレビにPCを繋ぐ。ただそれだけのことに、なぜこれほどの壁が必要なのか。
パクワのパッチが採用されるかは分からない。だが、たとえ却下されても、彼が歩いた道は消えない。コードは公開されている。誰でも読める。誰でも学べる。誰でも、その先を歩ける。
地図がなくても、人は歩ける。
その事実を、一人のポーランド人が、17のパッチで証明した。
参照元
いいなと思ったら応援しよう！
記事が役に立ったと感じていただけたら、チップで応援いただけると嬉しいです。いただいた支援は、より深い調査と分析のための時間に充てさせていただきます。灯台を灯し続けるための燃料になります。