AMDのHDMI 2.1がLinux 7.4で本格有効化へ｜FRL標準ON、FreeSync・VRR・ALLM対応の意味【2026年9月更新】
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
AMDのAlex Deucher氏は2026年9月10日、Linux 7.4向けAMDGPU機能を含むpull requestをDRM-Nextへ送付しました。今回の更新には、HDMI 2.1の高帯域伝送に使うFRLを初期状態で有効にする変更に加え、HDMI接続のFreeSync、標準HDMI VRR、ALLMがまとめて含まれています。Linux 7.2にはFRLがすでに統合されていましたが、FRL経由のVRRが未完成だったためあえて無効化されていました。今回はその穴を埋めたうえでFRLを標準ONへ切り替える段階に進みます。あわせて、8月のALLM仕様変更、新機能Passive VRR、Bazzite 44の実機報告まで整理します。
Linux搭載のゲーミングPCをリビングの4Kテレビへ接続してプレイしていると、フレームレートが変動する場面で画面がカクついたり、ゲームを始めるたびにテレビのリモコンでゲームモードへ切り替えたりする必要があると感じたことがある人は少なくないはずです。RadeonのLinux向けドライバーはDisplayPort経由のVariable Refresh Rate（VRR）には以前から対応していましたが、多くのテレビが搭載するHDMI経由ではこの種の機能を十分に使い切れていませんでした。
高帯域な映像を転送するFixed Rate Link（FRL）の初期対応はLinuxカーネル7.2へすでに統合されていましたが、あえて初期状態では無効化されていました。理由は、FRL経由のVRR実装が完成していない状態でFRLを優先すると、それまでVRRを使えていたユーザーで機能が後退する可能性があったためです。2026年9月10日、AMDのAlex Deucher氏がLinux 7.4向けのAMDGPU機能を含むpull requestをDRM-Nextへ送付し、この「高帯域は使えるがVRRが揃っていない」という穴を埋めたうえでFRLを標準ONへ切り替える段階に進みました。
ただし、一般的なUbuntu、Fedora、Arch Linux、Bazziteなどで、4K・120Hz、VRR、ALLMをすべて標準設定のまま利用できる状態になったわけではありません。今回のpull requestはLinux 7.4向けの開発段階の変更で、マージウィンドウが実際に開くのは2026年10月後半の見込みです。本記事では、FRL・DSC・VRR・ALLMの違い、Linux 7.2とLinux 7.4で何が変わるのか、そしてBazzite 44の先行実装から見えてきた実機での注意点まで整理します。
目次
要点Linux 7.4向けpull requestにFRL標準ON・FreeSync・VRR・ALLMがまとめて入った
2026年9月10日、AMDのAlex Deucher氏がLinux 7.4向けのAMDGPU機能を含むpull requestをDRM-Nextへ送付しました。含まれるのはHDMI 2.1のFRLを初期状態で有効にする変更、HDMI接続のFreeSync対応、HDMI Forum規格に準拠した標準HDMI VRR対応、そしてALLM対応です。あわせてGFX12.1・DCN 6ディスプレイエンジン・SMU 15向けの更新も含まれています。マージウィンドウが実際に開くのは、Linux 7.3の正式リリース時期次第で2026年10月後半になる見込みで、2026年9月12日時点ではまだ確定していません。
出典：Phoronix「Patches Ready For AMDGPU HDMI 2.1 Enabled By Default With Linux 7.4」、VideoCardz、AMD Alex Deucher氏によるpull request原文（dri-devel）
2026年7月30日、Linuxカーネル開発者のTomasz Pakuła氏が進めてきたAMDGPUドライバー向けの拡張パッチシリーズの最新版が、amd-gfxメーリングリストへ投稿されました。HDMI 2.1のVRRとALLMをRadeonのLinux向けドライバーへ追加する内容で、当時のv1〜v3ではコンテンツタイプが「Game」に設定された場合、またはHDMI VRRが有効になった場合にALLMを自動的に有効化する仕組みが含まれていました（この設計は8月に変更されています。詳しくは後述します）。パッチはAMDのディスプレイエンジニアや他のカーネルグラフィックスメンテナーによるレビューを重ね、今回のLinux 7.4向けpull requestに統合される形で決着しました。
仕組みVRRに対応するとティアリングやカクつきを抑えられる理由
PCゲームのフレームレートは常に一定ではありません。軽い場面では120fps出ていても、敵やエフェクトが増える場面では90fps、さらに重い場面では70fps台まで落ち込むことがあります。一方、一般的なテレビやモニターは60Hzや120Hzといった固定のタイミングで画面を更新します。
GPUが映像を完成させるタイミングと、ディスプレイが画面を書き換えるタイミングがずれると、画面の上下に異なるフレームが混在して表示されるティアリングが発生します。V-Syncを有効にすればティアリングは抑えられますが、GPUが次のフレームを時間内に用意できなかった場合、同じフレームを長く表示することになり、動きが一瞬止まったように見えるスタッターや、余計な入力遅延が生じる場合があります。
VRRは、GPUがフレームを完成させるタイミングに合わせて、ディスプレイ側のリフレッシュレートを変化させる技術です。HDMI Licensing Administratorは、VRRによって遅延、スタッター、フレームティアリングを軽減または解消できると説明しています。
RadeonのLinux向けドライバーは、DisplayPort経由のFreeSync・Adaptive-Sync（VRR）には以前から対応していました。しかし、多くのテレビはDisplayPort端子を搭載しておらずHDMIしか選べないため、HDMI経由のVRRに対応していないことは、テレビへLinuxゲーミングPCを接続する場面での大きな制約になっていました。
留意点VRRを有効にしてもフレームレート自体は上がらない
VRRはゲームの描画性能を高める機能ではありません。VRRを有効にしても、GPUの処理能力やゲームの平均フレームレートが上がるわけではなく、70fpsしか出ていないゲームがVRRによって120fpsになることはありません。変化するのは、GPUが出力するフレームとディスプレイの表示タイミングの同期方法です。フレームレートが安定しない状況でも、画面の更新タイミングを合わせることで、ティアリングやスタッターを目立ちにくくします。今回のAMDGPUパッチが正式に利用可能になっても、Radeonの平均fpsやベンチマークスコアが直接向上するわけではない点には注意が必要です。
機能ALLMはゲーム開始時にテレビのゲームモードを自動的に切り替える
ALLMは「Auto Low Latency Mode」の略で、日本語では自動低遅延モードと呼ばれます。現在のテレビには、映像をきれいに見せるためのノイズ低減、フレーム補間、超解像、輪郭補正といった映像処理機能が数多く搭載されています。映画やテレビ番組を見る場合には効果的ですが、映像を受け取ってから実際に表示するまでの処理時間が増えるため、ゲームでは入力遅延の原因になります。
多くのテレビには映像処理を減らす「ゲームモード」が用意されていますが、従来はリモコンで入力設定や映像モードを手動で切り替える必要がありました。
HDMI Licensing Administratorは、ALLMをゲーム機やPCがディスプレイへ低遅延モードへの切り替えを要求し、その必要がなくなった際には信号を解除して通常モードへ戻す仕組みとして説明しています。ALLMに対応した機器はゲームを開始するとテレビへ低遅延モードを要求する信号を送信し、テレビ側がALLMに対応していれば自動的にゲームモードへ切り替わります。
動画配信サービスなどゲーム以外の用途へ戻ると、テレビは通常の映像モードへ復帰できます。ゲームのたびにテレビの設定を変更する必要がなくなるため、リビングのテレビへLinux PCやSteamOS系デバイスを接続する環境では特に恩恵が大きい機能です。
補足ALLMも処理速度そのものを上げる機能ではない
ALLMが減らすのは、主にテレビ内部で発生する映像処理の遅延です。GPUがゲームを描画する時間や、CPUがゲーム処理を行う時間、コントローラーからPCへ信号が届く時間が短くなるわけではありません。テレビの通常モードで重い映像補正が有効になっていた場合は、ゲームモードへの切り替えによって操作感が大きく改善する可能性があります。
一方、あらかじめテレビをゲームモードへ固定して使っている場合、ALLMを利用しても入力遅延自体はほとんど変わらず、設定を自動化できることが主なメリットになります。ゲームモードでは映像補間や一部の画質補正が無効になる場合があるため、低遅延を優先する代わりに動画視聴時の画質が変わる可能性がある点も踏まえると、ゲーム終了後に自動復帰できるALLMの実用性は高いといえます。
設定ALLMのトリガー条件は8月のv4で仕様変更された
ALLMをいつ有効にするかという条件は、パッチのレビューが進む過程で変わりました。2026年8月上旬に投稿されたv1〜v3では、VRRが有効になっている場合、またはHDMIの規格で規定されているコンテンツタイプヒントが「Game」に設定された場合のいずれかでALLMを自動的にトリガーする設計でした。
しかし2026年8月14日に投稿されたv4では、このcontent-typeによる判定が削除されています。パッチの説明には「content-typeベースのALLMヒューリスティックを削除する。ALLM_Modeは、HDMI 2.1の規定に従い、Gaming-VRRが必須となるケース（対応シンクがALLMを通知し、かつVRR_EN=1の場合）でのみ設定される」と明記されました。つまり最終的な実装では、「ゲームというジャンル指定」ではなく「実際にGaming-VRRが動作しているかどうか」だけがALLMの発動条件になっています。
あわせて、Windows環境でのFreeSyncデスクトップ動作を再現し、フルスクリーンのゲーム以外でも常時VRRを有効にしておく「HDMI VRRデスクトップモード」という設定も用意されています。デスクトップ環境で発生していた不要な画面の点滅や表示の乱れを避けるために用意された機能です。
出典：amd-gfxメーリングリスト「[PATCH v4 0/4] HDMI 2.1 VRR and ALLM support」にもとづきます。これらの設定項目は、パッチの初期版ではカーネルモジュールパラメータとして提案されていましたが、開発が進んだ後のバージョンではDRM（Direct Rendering Manager）の標準プロパティとして扱う方式へ変更されています。最終的にどのような操作方法でユーザーに提供されるかは、正式版での実装によって変わる可能性があります。
背景Linuxで長期間HDMI 2.1対応が制限されていた理由
RadeonのWindows向けドライバーでは、対応GPUと対応テレビを組み合わせることでHDMI 2.1の高帯域出力やVRRを利用できます。一方、Linuxで使用されるAMDGPUドライバーはオープンソースで開発されているため、HDMI 2.1の仕様を公開コードとして実装することが難しい状況が続いていました。
2024年、AMDはHDMI 2.1のオープンソース実装についてHDMI Forumへ承認を求めましたが、却下されています。AMD側は当時、この状況について「HDMI Forumは私たちの提案を却下しました。現時点では、HDMI Forumの要件に違反せずにオープンソースのHDMI 2.1実装を行うことはできません」と説明していました。この影響で、Linux版AMDGPUドライバーでは4K・120HzやHDMI経由の5K・240Hzが利用できないというバグ報告が3年近く未解決のまま残されていました。
ハードウェア上はHDMI 2.1に対応できるRadeonでも、Linuxのオープンソースドライバーでは機能を十分に利用できない状態が続いていたことになります。テレビの多くはDisplayPort端子を搭載していないため、LinuxユーザーがDisplayPort経由の高リフレッシュレートやVRRを利用したくても、リビング向けテレビではHDMIを使わざるを得ないケースが少なくありません。
今回、AMDGPUドライバーへFRL、DSC、VRR、ALLMのパッチが段階的に投稿されたことで、LinuxのオープンソースドライバーでもHDMI 2.1の主要機能が実用化へ近づいています。
出典：GamingOnLinux「The HDMI Forum rejected AMD’s open source HDMI 2.1 implementation」
経緯FRLとDSCから段階的に進んできたHDMI 2.1対応
AMDはHDMI 2.1のすべての機能を一度に追加したわけではありません。まず公開された重要な機能がFRLです。FRLは「Fixed Rate Link」の略で、HDMI 2.1で高い映像帯域を実現するための伝送方式です。従来のTMDSよりも多くのデータを転送でき、高解像度・高リフレッシュレート出力の基盤になります。
続いて対応が進められたのが、映像データを圧縮して限られた伝送帯域の中で高い解像度やリフレッシュレートを実現するDisplay Stream Compression（DSC）です。2026年5月、AMDはFRLとDSCの両方に対応するパッチをLinuxカーネルへ投稿しました。FRLとDSCがそろうことで、対応するGPU・テレビ・ケーブルの組み合わせでは、HDMI 2.1の高帯域を活用しやすくなります。
そのうえで今回、ゲーム時の表示を滑らかにするVRRと、テレビを自動的に低遅延モードへ切り替えるALLMが加わったことで、Linux版AMDGPUのHDMI 2.1対応は主要機能がひととおり出そろう段階に近づきました。
| 時期 | 出来事 | 内容 |
|---|---|---|
| 2024年2月 | HDMI Forumが拒否 | AMDのオープンソースHDMI 2.1実装提案が却下される |
| 2026年5月 | FRL・DSCパッチ | 高帯域伝送（FRL）と映像圧縮（DSC）のパッチをLinuxカーネルへ投稿 |
| 2026年7月30日 | VRR・ALLMパッチ | 可変リフレッシュレートと自動低遅延モードのパッチをamd-gfxへ投稿 |
出典：amd-gfxメーリングリスト「[PATCH RESEND v3 00/14] HDMI FRL and DSC Support for amdgpu」
前進初期のFRL対応がLinux 7.2へ正式にマージされた
2026年5月に投稿されたFRLのパッチは、その後もレビューが重ねられ、Linuxカーネルの次期メインラインであるv7.2のDRM-Nextへ、初期対応として正式にマージされました。
マージされたのはFRLの基礎的な配線部分で、対応するGPUとHDMI 2.1ディスプレイの組み合わせにおいて、より高い解像度・リフレッシュレートを扱うための土台が整った段階です。AMDGPUドライバーによるHDMI 2.1の完全な実装がLinux 7.2で完成するわけではなく、後述のとおりFRLは初期状態で無効のままです。
安定化2026年8月5日にHDMI FRLの接続不良を減らす修正が追加
AMDGPUのHDMI 2.1対応は、FRLの基本機能を実装しただけで完了したわけではありません。テレビやモニターとの接続状態が変化した場合や、スリープから復帰した場合などでも、FRL接続を正しく維持・再確立できる必要があります。
2026年8月5日に投稿されたAMDGPU Display Coreの更新には、HDMIリンクを完全に切断せずに接続状態を再確認した際、FRLの対応能力を正しく復元する修正が含まれています。従来の処理では、接続先がFRLへ対応していても、非破壊的なリンク確認の後に対応情報が適切に引き継がれず、HDMI 2.0相当のTMDS接続へ戻るような例外的な問題につながる可能性がありました。
FRLリンクトレーニングのタイムアウト処理も見直されています。リンクトレーニングとは、GPUとテレビやモニターが通信速度やレーン構成を調整し、安定して映像を転送できる状態を作る処理です。
この修正はHDMIの最大帯域をさらに引き上げるものではありません。4K・120Hzなどの高帯域モードで、接続の確立に失敗する、画面復帰後に低いリフレッシュレートへ戻る、ブラックアウトするといった問題を減らすための安定化が目的です。投稿時点(2026年8月6日)では開発パッチとして準備されている段階でした。
出典：Phoronix「AMD Preps HDMI FRL Fixes, New Knob For Disabling DCE Gating」
対応製品版Radeon Software for Linux 26.13では高帯域HDMIモードに対応
AMDは2026年7月20日、UbuntuとRHEL向けのRadeon Software for Linux 26.13を公開しました。
公式リリースノートでは、対応ディスプレイにおいて高い解像度やリフレッシュレートを利用するための、高帯域HDMIモードへ対応したと案内されています。Display Core、リンク制御、ハードウェアシーケンス、Display Mode Libraryを含む表示処理全体に対応が追加されています。この変更により、対応するRadeonとディスプレイの組み合わせでは、従来のHDMI 2.0相当の帯域を超える表示モードを利用できる可能性があります。
ただし、Radeon Software for Linux 26.13と、UbuntuやFedoraなどに最初から組み込まれているAMDGPUドライバーは、更新経路が異なります。Radeon Software for Linux 26.13は、AMDがUbuntu 24.04、Ubuntu 26.04、RHEL 9.8、RHEL 10.2向けに提供するインストーラーです。Fedora、Arch Linux、Bazziteなどへ、そのまま導入することは想定されていません。
AMD自身も、一般的な用途では各Linuxディストリビューションが提供するAMDGPUドライバーの利用を推奨しています。高帯域HDMIモードを試す目的だけで、BazziteやArch LinuxへUbuntu向けドライバーを強制的に導入するべきではありません。
また、26.13のリリースノートで案内されているのは、高解像度・高リフレッシュレートを実現する高帯域HDMIモードです。HDMI VRRやALLMが、すべての対応GPUとテレビで正式に利用可能になったとは記載されていません。4K・120Hzの表示が可能になることと、VRR・ALLMが利用可能になることは、分けて考える必要があります。
出典：AMD公式「Radeon Software for Linux 26.13 Release Notes」
整理4K・120Hzに対応してもVRRが使えるとは限らない
FRL、VRR、ALLMは、いずれもHDMI 2.1に関係する機能ですが、役割は異なります。
FRLは、GPUからテレビやモニターへ大量の映像データを転送するための仕組みです。4K・120HzのようにHDMI 2.0の帯域では不足する表示モードを利用するために必要になります。VRRは、ゲームのフレームレートに合わせてテレビやモニターのリフレッシュレートを変化させる機能です。ティアリングやスタッターを抑えますが、映像を転送できる最大帯域を増やす機能ではありません。ALLMは、ゲームを開始した際にテレビを低遅延なゲームモードへ自動的に切り替える機能です。解像度やリフレッシュレートには直接影響しません。
そのため、FRLによって4K・120Hzを選択できても、VRRが未対応ならリフレッシュレートは120Hz固定になります。反対に、HDMI 2.0相当の帯域内でVRRが動作しても、4K・120Hzを非圧縮で出力できるとは限りません。Linux版Radeonでテレビ接続をWindowsと同等に近づけるには、FRL、必要に応じたDSC、VRR、ALLMのそれぞれが正しく動作する必要があります。
制約FRLはVRR対応が整うまで初期状態で無効になっている
2026年5月に投稿されたFRLのパッチは、初期状態では無効になる設計でした。理由は、FRLを有効にした状態でHDMI VRRを利用できなければ、従来利用できていた一部のユーザーにとって機能低下になりかねないためです。FRL対応テレビを接続すると、ドライバーは高帯域なFRL接続を優先しますが、その接続経路でVRRが動作しなければ、高解像度や高リフレッシュレートを選べても可変リフレッシュレートを失う場合があります。
AMDはこの状況を避けるため、HDMI VRRへの対応が整うまではFRLをデフォルトで無効にする方針を取っていました。実験的に有効化する場合は、カーネルの起動オプションとしてamdgpu.dcfeaturemask=0x400を指定する仕組みが用意されていますが、一般ユーザーに推奨される設定ではありません。今回HDMI VRRのパッチが投稿されたことで、VRR対応が整い次第、AMDはFRLを初期状態で有効にする計画を明らかにしています。
続報FRLを標準で有効にするパッチが2026年8月27日に投稿された
前のセクションで触れた「VRR対応が整い次第、FRLを初期状態で有効にする」という計画が、具体的な形で動き出しました。2026年8月27日、AMDのFangzhi Zuo氏が、AMDGPUドライバーでHDMI FRLを標準で有効にするパッチ「Enable HDMI FRL by default」をamd-gfxメーリングリストへ投稿しています。
現在のAMDGPUドライバーでは、FRLは「DC_FRL_MASK」という機能フラグの後ろに置かれており、ユーザーがamdgpu.dcfeaturemaskモジュールパラメーターで明示的にオプトインしない限り無効のままという状態が続いています。今回のパッチは、この既定の挙動を変更し、通常のインストールでもFRLが標準で有効になることを目指す内容です。
投稿された初版は、DC_FRL_MASKフラグの意味そのものを反転させる実装でした。FRLの有効化フラグを既定でtrueにしたうえで、従来のマスクビットを「TMDSのみの信号方式へ戻したい場合のオプトアウト」として再利用する形です。これに対し、AMDのHarry Wentland氏から、既存のマスクの意味を変更するのではなく、ドライバーの既定値側を変更するべきだとするレビューコメントが入りました。
このレビューを受け、Fangzhi Zuo氏は同日中に第2版のパッチを投稿しています。第2版では、マスクビットの意味を変えないまま、既定のamdgpu_dc_feature_maskの値へDC_FRL_MASKを追加する形へ実装が修正され、Harry Wentland氏からレビュー承認(Reviewed-by)を受けました。
このFRL標準有効化パッチは、Linux 7.3のマージウィンドウには間に合いませんでした。その後、2026年9月10日にAMDのAlex Deucher氏が送付したLinux 7.4向けpull requestに、ここまで解説してきたVRR・ALLMのパッチ、そして次のセクションで解説する標準HDMI VRR対応とあわせて統合される形で決着しています。
出典：amd-gfxメーリングリスト「[PATCH] drm/amd/display: Enable HDMI FRL by default」・同「[PATCH v2] drm/amd/display: Enable HDMI FRL by default」
展望Linux 7.4へ向けたマージウィンドウは10月後半の見込み
VRR・ALLMパッチは2026年7月30日に投稿され、amd-gfxメーリングリストでレビューを受けてきました。パッチシリーズは2026年1月ごろから複数回にわたって版を重ねてきたもので、AMDのディスプレイエンジニアや他のカーネルグラフィックスメンテナーからのフィードバックを踏まえて改良が続けられ、8月14日のv4でALLMのトリガー条件が整理されています。
FRLの初期対応はLinux 7.2へ既に組み込まれ、VRR・ALLM・FRL標準有効化はいずれもLinux 7.3のマージウィンドウには間に合いませんでした。2026年9月10日、AMDのAlex Deucher氏がこれらをまとめたLinux 7.4向けのpull requestをDRM-Nextへ送付しています。
2026年9月12日時点のLinuxは、安定版が7.2系、開発中のメインラインがLinux 7.3-rc2（9月6日リリース）です。Linux 7.3の正式リリースは10月18日前後、遅れた場合でも10月25日前後が有力視されており、Linux 7.4のマージウィンドウはこの直後、2026年10月後半に開く見込みです。つまり、今回のpull requestが実際にLinuxカーネル本流へ統合されるのはLinux 7.3の正式リリース後になります。現在使用しているUbuntu、Fedora、Arch Linux、CachyOSなどを更新しても、今回の変更がすぐに有効になるわけではありません。なお、Linuxゲーミングではカーネルだけでなく、RADVを含むMesaの更新状況も確認しておきましょう。
| 時期 | 出来事 | 内容 |
|---|---|---|
| 2026年8月16日 | Linux 7.2正式リリース | FRLの初期対応を含む・標準では無効 |
| 2026年8月27日 | FRL標準有効化パッチ | v2をHarry Wentland氏がレビュー承認・7.3には間に合わず |
| 2026年9月6日 | Linux 7.3-rc2 | 本記事更新時点の開発版 |
| 2026年9月10日 | Linux 7.4向けpull request | FRL標準ON・FreeSync・標準HDMI VRR・ALLMを統合 |
| 2026年10月18日前後 | Linux 7.3正式リリース見込み | 遅延時は10月25日前後 |
| 2026年10月後半 | Linux 7.4マージウィンドウ | 7.3正式リリース直後に開く見込み |
| SteamOS安定版のカーネル | Linux 6.16 | 2026年6月に安定版へ昇格・本流より遅れて反映 |
現状SteamOSへの反映時期はまだ発表されていない
SteamOSはLinuxを基盤としており、Radeon向けのオープンソースドライバーを使用しています。そのため、AMDGPUのHDMI 2.1 VRR・ALLM対応は、将来のSteamOS搭載機や、SteamOS系ディストリビューションを導入したリビングPCにも恩恵をもたらす可能性があります。特にテレビへHDMI接続する機器では、DisplayPortよりHDMIを使用する場面が多くなります。
ただし、Linuxカーネルへパッチが統合されたからといって、SteamOSへ同時に反映されるわけではありません。ValveはLinuxカーネル、Mesa、Gamescope、SteamOSのシステム設定を組み合わせ、対象ハードウェアでの検証を経てからアップデートを配信しています。
現行の安定版SteamOSが採用しているカーネルはLinux 6.16で、2026年6月に安定版へ昇格した経緯があり、Linux本流の最新バージョンをそのまま即座に採用するわけではないスタイルであることが分かります。本記事の更新時点でも、SteamOSへの正式な反映時期や、どの機器がHDMI VRR・ALLMへ対応するかは発表されていません。
一方、Steam Machine向けには前向きな材料もあります。海外メディアの報道によれば、Valveは2026年6月の時点で、Steam MachineのAMDオープンソースグラフィックススタックにおけるHDMI 2.1 VRR対応の課題は「完全に解決した」と説明し、対応を確認しています。これはSteamOS本体への正式な反映発表そのものではありませんが、Valve自身が自社ハードウェア向けにこの問題を追いかけてきたことを示す材料です。今回のLinux 7.4向けpull requestは、AMDのオープンソースグラフィックススタックを利用するSteam Machineのような機器にとって特に恩恵が大きいアップデートになりそうです。
先行実装Bazzite 44でFRL・ALLM・VRRが実際に使えるようになった
2026年8月20日から21日にかけて、独立系のLinuxディストリビューション「Bazzite」がバージョン44のDeck系イメージ(携帯型ゲーミングPCやリビングPC向けのビルド)を本格展開しました。デスクトップ版のBazzite 44は同年4月から段階的に更新されてきましたが、今回はハンドヘルド機やHTPC向けの構成も足並みをそろえた大型アップデートで、700件を超えるコミットが含まれています。この一連の更新に、ここまで解説してきたAMD Radeon向けのHDMI 2.1新スタック(FRL・ALLM・VRR)が実際に組み込まれました。
有効化する方法は2通り用意されています。ひとつはBazzite Portalアプリの「Tweak Systems」から「Enable HDMI 2.1 for AMD Graphics Cards」をオンにする方法、もうひとつはターミナルでujust configure-amd-hdmi21コマンドを実行する方法です。どちらの方法でも、初期状態では無効のままになっている点に注意してください。Bazzite開発チームは、より幅広いハードウェアでの検証が済むまでは全ユーザー向けの初期設定を変更せず、有効化するかどうかを個々のユーザーの判断に委ねる方針を取っています。
ここで整理しておきたいのは、BazziteはSteamOSそのものではないという点です。BazziteはFedora Atomicをベースに、Universal Blueプロジェクトが開発している独立したLinuxディストリビューションで、SteamOSに近い操作感を目指していますが、Valveが開発・配布する公式SteamOSとは別物です。前述のとおり、公式SteamOSへのHDMI 2.1 VRR・ALLM対応がいつ反映されるかは本記事の更新時点でも発表されていません。Bazzite 44の対応は、SteamOS本体の対応とは別に、Bazziteチームが上流のAMDGPUドライバー・Linuxカーネルの成果を独自に取り込んで先行実装したものだと理解しておく必要があります。
Bazzite公式ドキュメントは、HDMI 2.1を有効にすると一部のディスプレイで「ちらつきや表示の不安定化が発生する可能性がある」と明記しています。原因はAMD製グラフィックスカードの電源状態切り替えに関する問題とされており、上流(Linuxカーネル側)への修正報告は済んでいるものの、本記事の更新時点ではまだ解決していません。症状が出た場合は、SteamゲーミングモードでVRRを常時オンに設定する、デスクトップモードでリフレッシュレートを60Hzに固定しAdaptive Syncを「Never」または「Always」に設定する、あるいはLACTでグラフィックスカードを最大電力プロファイルに固定する、といった回避策が案内されています。
Bazzite 44の開発期間中には、HDMI 2.1に関連する不具合報告も複数上がっていました。代表的な例が、Radeon RX 9070・RX 9070 XT環境で、2026年6月ごろのビルド(44.20260605〜44.20260709)にアップデートするとKDEの画面設定からVRR(Adaptive sync)の項目自体が消えてしまうという報告です。原因はディスプレイ側のEDID情報に含まれる水平走査範囲の扱いにあったとされ、2026年8月18日のテストビルド(44.20260818.3)で、Bazziteがamd-gfxメーリングリストで審査されてきた公式のAMD VRR実装(本記事で解説してきたVRR・ALLMパッチと同じ系統)に切り替えたことで解消したと報告されています。あわせて、RX 9070 XT環境でHDMI 2.1出力時に音声が数秒おきに途切れるという報告も上がっており、こちらは本記事の更新時点でBazziteのIssue Trackerに未解決のまま残っています。
本記事の更新時点で報告されている実機の状況としては、Radeon RX 7900 XTXをLG C2へ直接HDMI接続した環境で、3840×2160・約120Hz・VRR・RGB 12bit・FRLが動作したというユーザー報告がBazziteのGitHubに上がっています。一方、同じスレッドでは、DisplayPort-HDMI変換アダプター（Chrontel CH7218搭載のUGREEN製）をDenon製AVアンプ経由で接続した構成において、VRR情報がgamescope・GNOMEの設定画面から完全に消えるという問題も報告されました。原因はAVアンプがEDIDを中継する際にVRR/FreeSync情報を欠落させていたことで、テレビ本来のEDIDを直接キャプチャしてドライバーへ強制適用する回避策（`drm.edid_firmware`カーネルパラメーター経由）で解決したと報告されています。GPU・テレビ・カーネル側が対応していても、間に挟むAVアンプや変換アダプターによっては情報が正しく伝わらない場合がある点は覚えておいて損はありません。導入後に映像や音声の乱れを感じた場合は、いったん設定を無効化して様子を見るか、Bazziteの最新の安定版・テストビルドへの更新状況を確認することをおすすめします。なお、Bazzite 44ではHDMI 2.1対応とあわせて、VRAM不足時にフォアグラウンドのゲームを優先する新しいメモリ管理も導入されています。詳しくはBazzite 44のVRAM管理を解説した記事で扱っています。
出典：Bazzite公式ドキュメント「Steam Gaming Mode Quirks and Workarounds」、VideoCardz「Bazzite 44 released with HDMI 2.1 FRL, multi-GPU controls and new VRAM management」
出典：GitHub「ublue-os/bazzite Issue #5107：VRR (Adaptive sync) not working after upgrade to 44.20260608 (Stable)」、GitHub「ublue-os/bazzite Issue #5115：GPU audio issues」、GitHub「ublue-os/bazzite Issue #5673：CH7218 PCON: AVR strips VRR from EDID」
比較モニターよりテレビ接続で恩恵が大きい理由
標準HDMI VRRFreeSyncを前面に出さないテレビにも関係する対応
「FreeSync対応」と「HDMI Forum VRR対応」は完全に同じ意味ではありません。従来のAMDGPUは、ディスプレイのEDIDに含まれるAMD独自のVendor Specific Data Block（AMD VSDB）を主に確認してFreeSync対応を判断していました。ところがHDMI 2.1対応テレビの中には、AMD FreeSync用の情報を持たず、HDMI Forumが定義するHF-VSDBに標準HDMI VRRの対応範囲だけを記録している製品があります。このようなテレビではハードウェアとしてVRRへ対応していても、AMDGPU側からVRR非対応と判定されるケースがありました。
新しいパッチでは、まずAMD VSDBからFreeSync対応範囲の取得を試み、有効な範囲を取得できなかった場合にHF-VSDBに記録されたVRR範囲を読み取るフォールバック処理が追加されています。HF-VSDBが示す上限が「ベースリフレッシュレートまで」を意味する場合や、EDIDにモニターレンジの上限情報がない場合には、対応する最高リフレッシュレートのモードから有効なVRR範囲を導き出す実装です。開発者はSamsung S95B・LG C4に加え、AMD FreeSyncの情報を持たないSony Bravia 8でもこの処理を検証したと報告しています。特にリビング用テレビでは、HDMI VRRには対応していてもFreeSyncを前面に出していない製品があり、こうしたテレビをRadeon搭載Linux PCへ直接HDMI接続する場合、今回の標準HDMI VRR対応が実用上かなり重要になります。これまで「テレビはHDMI 2.1 VRR対応なのに、LinuxのKDEではAdaptive Syncが出てこない」という環境があった理由の一つが、ここにあります。
出典：linux-kernelメーリングリスト「[PATCH v2 3/4] drm/amd/display: Add HDMI 2.1 VRR support from HF-VSDB」、amd-gfxメーリングリスト「[PATCH v4 00/27] drm/amd: VRR fixes, HDMI Gaming Features」
高帯域なHDMI 2.1出力を利用するには、Radeon側のHDMI出力、テレビ側のHDMI入力、Linuxドライバー、カーネル、HDMIケーブルのすべてが対応している必要があります。古いHigh Speed HDMIケーブルでは、高解像度・高リフレッシュレート時に画面の点滅やブラックアウトが発生する可能性があるため、4K・120Hzなど高帯域の出力を利用する場合は、認証ラベルの付いたUltra High Speed HDMIケーブルを選ぶのが安全です。
また、どのRadeon世代で正式に4K・120HzやVRR・ALLMを利用できるかは、パッチが統合された後もGPU世代別・テレビ別の検証が必要です。ノートPCではHDMI端子が内蔵GPU側へ接続されている場合もあり、外付けGPUの構成によっても結果が変わります。開発中のパッチや起動パラメーターを使えば正式リリース前の機能を試せる場合がありますが、画面が映らない、リフレッシュレートを変更できない、HDRやVRRが不安定になるといった問題が起こる可能性があるため、日常的に使用しているゲーミングPCでの導入はおすすめできません。
別の開発項目Passive VRRは今回のpull requestとは別に考えた方がいい
AMDではもう一つ、「Passive VRR」と呼ばれる機能も並行して開発されています。これは今回のLinux 7.4向けpull requestで報じられている基本的なHDMI VRR対応とは目的が異なります。
HDMI接続のテレビやモニターでは、固定リフレッシュレートからVRRへ切り替わる瞬間に、画面が一瞬暗転したり明るさが変化したりすることがあります。DisplayPortやeDPではシームレスなVRR遷移が規格上求められていますが、HDMIでは同じとは限りません。Passive VRRは、デスクトップ表示中も対応ディスプレイをVRR状態へ維持しておき、ゲーム開始時にVRRへ出入りする処理そのものを減らすことで、この暗転や明るさ変化を避けることを狙った仕組みです。パッチの説明では、Passive VRRに対応すると通知したディスプレイに対して初期状態で有効になり、新設される「PASSIVE_VRR_DISABLED」というCRTCプロパティでオプトアウトできる設計になっています。シームレスな遷移が規格で保証されているDisplayPort／eDPには適用されません。
Passive VRRは2026年9月1日に別のパッチシリーズとして投稿されたばかりの機能です。今回の「Linux 7.4向けAMDGPU feature pullにFRL標準ON・FreeSync・VRR・ALLMが入った」というニュースと、Passive VRRが同じタイミングで確実にメインラインLinux 7.4へ入ることは分けて考えた方が安全です。基本的なHDMI VRR対応が進むことと、デスクトップからゲームへの切り替えまで完全に暗転しなくなることは同じ話ではありません。
出典：amd-gfxメーリングリスト「[PATCH v1 0/3] drm/amd/display: passive VRR」
判断今回のpull requestをどう受け止めるべきか
今回のpull requestは、Radeonのテレビ接続を今日から劇的に変えるものではありません。DRM-Nextへ送付された段階であり、マージウィンドウが実際に開くのは2026年10月後半の見込みです。
一方で、DisplayPort経由でしか使えなかったVRRをHDMI接続へ広げ、HDMI Forum規格に沿ったALLMの発動条件まで整理された今回の内容には、2024年にHDMI Forumから提案を拒否されて以来の技術的な積み重ねが表れています。FRL・DSCという土台が先に整えられ、そこへ標準HDMI VRR・ALLMが続いたことで、Linux版AMDGPUドライバーはHDMI 2.1の主要機能をひととおりカバーする段階に近づきました。
- DisplayPort限定だったRadeonのVRR対応がHDMI接続へ拡張される見込み
- AMD VSDBだけでなくHF-VSDBも読み取るため、FreeSyncを前面に出さないテレビにも対応
- FRL・DSC・標準HDMI VRR・ALLMと段階的にHDMI 2.1機能を積み上げてきた開発の継続性
- Bazzite 44がFRL・ALLM・VRRを独自に先行実装(既定は無効、オプトインで有効化)
- 本記事の更新時点ではまだLinux 7.4のマージウィンドウすら開いていない段階
- Passive VRRなど関連機能は別パッチ系列で開発中、同時にメインライン入りするとは限らない
- SteamOS本体への反映時期は発表されておらず、AVアンプ等の中間機器を挟む構成では動作報告にばらつきがある
FAQHDMI 2.1のVRR・ALLM対応についてよくある質問
ujust configure-amd-hdmi21を実行する必要があります。BazziteはSteamOSそのものではない独立したディストリビューションで、公式SteamOSへの反映時期は本記事の更新時点でも未発表です。有効化後にちらつきや音声の乱れが出る場合は、本文で紹介している回避策を確認してください。総括まとめ｜Linux 7.4は「FRLが使える」から「HDMI 2.1でゲームできる」へ進む更新
AMDのHDMI 2.1 FRLはLinux 7.2ですでにAMDGPUへ統合されていましたが、FRL経由のVRRが完成していなかったため、標準有効化すると機能後退が起きる可能性があり、初期状態では無効化されていました。2026年9月10日、AMDのAlex Deucher氏がLinux 7.4向けのAMDGPU機能を含むpull requestをDRM-Nextへ送付し、その穴を埋めるFreeSync・標準HDMI VRR・ALLMが揃い、FRLも初期状態で有効化される方向へ進んでいます。
中でも重要なのは、標準HDMI VRRへの対応です。新しいAMDGPUはAMD独自のFreeSync情報だけでなく、HDMI Forum VSDBに記録されたVRR範囲も読み取れるようになるため、「テレビはHDMI 2.1 VRR対応なのにLinuxではAdaptive Sync非対応と判定される」という問題を減らせる可能性があります。ALLMも、8月のv4パッチでcontent-type判定を外し、HDMI 2.1の規定通りGaming-VRR動作時にのみ発動する形へ整理されました。
一方、デスクトップ切り替え時の暗転を防ぐPassive VRRは別の開発項目であり、AVアンプや変換アダプターを挟んだHDMI環境では先行実装のBazzite 44ですでに相性問題も報告されています。そのためLinux 7.4を「RadeonのHDMI 2.1問題が完全にすべて解決するバージョン」と表現するのはまだ早いでしょう。それでも、Linux 7.2が「FRLという高帯域の土台を入れた更新」だったのに対し、Linux 7.4は「4K・高リフレッシュレートだけでなく、VRRと低遅延まで含めてHDMI接続でゲームするための機能を揃える更新」になりそうです。マージウィンドウが実際に開くのは2026年10月後半の見込みで、Linux 7.4本体のリリースはさらに先になります。SteamOSを含む多くの一般的な環境では、正式なカーネルとOSアップデートを待つのが安全です。特にRadeon搭載PCを4KテレビやSteam Machineのような機器へ直接接続しているユーザーにとっては、Linuxゲーミング環境の選択肢を大きく広げるアップデートになりそうです。
あわせて読みたい
