Le 10 septembre 2026, AMD a envoyé à DRM-Next, l’antichambre du sous-système graphique du noyau Linux, sa dernière demande d’intégration de nouveautés pour le pilote AMDGPU en vue de la version 7.4. Elle contient trois ajouts qui portent le même préfixe : la prise en charge du FreeSync sur HDMI 2.1, celle du VRR HDMI 2.1 et celle de l’Auto Low Latency Mode. Et elle contient surtout une ligne qui, pour beaucoup de joueurs sous Linux, vaut tout le reste : le Fixed Rate Link, la couche de transport qui permet au HDMI de dépasser ses anciens débits, passe en activé par défaut. Autrement dit, à partir de Linux 7.4, une carte Radeon branchée en HDMI sur un téléviseur ou un moniteur compatible utilisera enfin le HDMI 2.1 sans que l’utilisateur ait à forcer quoi que ce soit.

Il faut mesurer le temps que cela a pris. Le rapport de bogue à l’origine de toute cette affaire, celui qui constatait que le 4K à 120 Hz était indisponible en HDMI sur le pilote Linux d’AMD, avait déjà trois ans d’existence lorsque la presse s’en est emparée début 2024 : il remonte donc à environ 2021. Si Linux 7.4 sort comme prévu, la correction arrivera dans le noyau principal cinq ans plus tard.

Ce qui était cassé n’était pas un transistor, c’était un contrat

C’est le point que l’on perd de vue quand on lit ce genre de nouvelle, et c’est pourtant le seul qui compte pour comprendre pourquoi elle a mis si longtemps à arriver. Les cartes Radeon concernées savaient faire du HDMI 2.1 depuis le premier jour. Leurs sorties sont certifiées, leur silicium est capable, et sous Windows, avec le pilote fermé d’AMD, le 4K 120 Hz fonctionnait. Ce qui manquait, c’était l’autorisation d’écrire le code correspondant dans un pilote dont le code source est public.

En 2021, le HDMI Forum, le consortium qui gère la norme, a restreint l’accès public à ses spécifications : seuls les fabricants et développeurs agréés peuvent désormais consulter les détails techniques nécessaires pour implémenter les fonctions HDMI. Or un pilote en source ouverte publie, par définition, son implémentation. AMD et la fondation X.Org ont passé des mois à chercher une issue, les ingénieurs Linux d’AMD travaillant avec leur service juridique pour déterminer quelles fonctions HDMI pouvaient être exposées et comment. La réponse est tombée en février 2024, formulée par l’ingénieur Linux d’AMD Alex Deucher : « Le HDMI Forum a rejeté notre proposition, malheureusement. À l’heure actuelle, une implémentation HDMI 2.1 en source ouverte n’est pas possible sans enfreindre les exigences du HDMI Forum. »

La conséquence a été brutale et parfaitement absurde pour l’utilisateur final : sur une même machine, un même écran et un même câble, le HDMI 2.1 fonctionnait ou non selon le système d’exploitation. Ce n’était pas un défaut de pilote que quelqu’un aurait pu corriger en s’y mettant : c’était un refus. Précisons, parce que la confusion est fréquente, que la situation de NVIDIA était différente pour une raison de licence et non de mérite technique : son pilote principal étant fermé, il n’expose pas son implémentation et ne se heurte pas au même obstacle. Cet article ne compare aucune performance entre les cartes des deux constructeurs.

Ce qui a débloqué la situation, et ce que Phoronix en dit avec prudence

Quelque chose a changé au début de l’année 2026. Phoronix, qui suit ce dossier depuis le début, l’écrit avec les pincettes qui s’imposent : après le refus du HDMI Forum « pendant des années », quelque chose a bougé plus tôt cette année, « ce qui est largement supposé être lié à l’implication de Valve », et des correctifs HDMI 2.1 ont commencé à apparaître pour le pilote AMDGPU. Nous reprenons cette formulation telle quelle, avec son conditionnel : ni AMD, ni Valve, ni le HDMI Forum n’ont publiquement expliqué ce qui s’est débloqué ni pourquoi.

La suite est documentée, elle. AMD a publié en mai 2026 des correctifs FRL pour AMDGPU, puis confirmé qu’elle travaillait à une implémentation complète. Le support du Display Stream Compression, la compression de flux d’affichage, a été ajouté dans la foulée : c’est lui qui rend possibles des modes comme le 4K à 240 Hz quand la carte et l’écran le permettent. Le FRL a atteint le noyau Linux 7.2, mais désactivé par défaut : AMD voulait terminer le VRR et les fonctions associées avant de l’activer pour tout le monde, afin d’éviter que des utilisateurs ne perdent des fonctionnalités qui marchaient auparavant. Le 27 août 2026, Phoronix signalait qu’AMD se préparait à l’activer par défaut. La demande d’intégration du 10 septembre referme la boucle.

Un détail de cette demande mérite d’être relevé au passage, parce qu’il montre à quel point ce cycle est chargé : le même envoi apporte aussi les mises à jour pour le moteur graphique GFX12.1, pour le moteur d’affichage DCN 6 et pour le bloc SMU 15. DCN 6, nous en avons déjà parlé : c’est le moteur d’affichage des Radeon de 2027, dont AMD avait publié les premiers pilotes Linux début août. La demande d’intégration qui solde un litige ouvert en 2021 transporte donc, dans le même paquet, le matériel de l’année prochaine.

Pour qui cela change réellement quelque chose : le salon

Il faut être précis sur la population concernée, parce que beaucoup de joueurs sous Linux n’ont jamais rencontré ce problème et se demanderont de quoi il s’agit. Le DisplayPort n’a jamais été affecté : sa spécification est accessible, son implémentation libre n’a jamais posé de difficulté, et un moniteur de jeu relié en DisplayPort à une Radeon sous Linux affiche depuis longtemps ses hautes fréquences avec la synchronisation adaptative. Tous ceux qui jouent sur un moniteur PC relié en DisplayPort peuvent donc considérer que cette nouvelle ne les concerne pas.

Elle concerne en revanche, entièrement, ceux qui jouent sur un téléviseur. Un téléviseur n’a pas de DisplayPort. Il n’a que des ports HDMI. Un PC Radeon sous Linux relié à un téléviseur OLED récent se retrouvait donc plafonné aux débits du HDMI 2.0, sans VRR HDMI, c’est-à-dire sans la synchronisation adaptative qui supprime les déchirures et les à-coups quand la cadence d’images varie. Sur la machine la plus performante, dans la pièce la mieux équipée, on se retrouvait avec la pire configuration d’affichage. C’est précisément le scénario du salon, et c’est précisément le marché dans lequel Valve vient d’entrer.

L’ALLM, l’Auto Low Latency Mode, mérite un mot parce que c’est la fonction que personne ne réclame par son nom tout en la voulant. C’est elle qui fait qu’un téléviseur, lorsqu’il détecte une source de jeu, bascule automatiquement dans son mode jeu et coupe les traitements d’image qui ajoutent de la latence. Sans elle, il faut aller le faire à la main dans les menus du téléviseur, et se souvenir de le défaire pour regarder un film. Sa prise en charge dans le noyau signifie que ce va-et-vient devient automatique, comme sur une console.

Deux horloges : la Steam Machine a la fonction, votre PC devra attendre

C’est l’inversion la plus intéressante de cette histoire, et elle est rarement soulignée. La Steam Machine de Valve, sortie le 29 juin 2026, est livrée depuis avec une pile logicielle qui prend déjà en charge le VRR HDMI 2.1, et pas seulement dans sa variante AMD FreeSync : également dans la variante VRR du HDMI Forum, celle qu’utilisent les téléviseurs. En juin 2026, l’architecte de SteamOS Pierre-Loup Griffais déclarait à Digital Foundry que le problème était « entièrement résolu ». Valve précisait alors que la sortie restait limitée au 4K à 120 Hz, et qu’une mise à jour FRL ultérieure apporterait le 4K à 144 Hz sans compression et le 4K à 240 Hz avec le Display Stream Compression.

Comment Valve peut-elle livrer en juin ce que le noyau principal n’aura qu’en fin d’année ? Parce que SteamOS embarque son propre noyau et ses propres rétroportages : Valve n’attend pas la version officielle, elle prend les correctifs et les intègre. Le résultat est une inversion de l’ordre habituel. Le joueur qui a acheté la boîte de Valve a la fonction depuis bientôt trois mois ; le joueur qui a monté son PC et installé une distribution classique l’aura quand Linux 7.4 sortira, puis quand sa distribution l’aura reprise. Or la fenêtre de fusion de Linux 7.4 ne s’ouvrira que dans la seconde moitié d’octobre, selon la date à laquelle Linux 7.3 sera stabilisé, et la version finale pourrait n’arriver qu’à la toute fin de 2026, voire en janvier 2027. Pour une distribution à support long terme, qui ne change pas de noyau à chaque version, l’attente se compte en mois supplémentaires. Autrement dit : la console reçoit la fonction du noyau avant le PC.

Cette asymétrie rappelle, sur un autre terrain, ce que nous observions quand GeForce Now est sorti de bêta sur Linux : les briques qui débloquent le jeu sous Linux arrivent de plus en plus par des acteurs qui vendent du matériel ou du service, pas par la dynamique communautaire seule.

Ce que cela ne règle pas : le HDMI 2.2 arrive avec le même problème

Il serait confortable de conclure que le dossier est clos. Il ne l’est pas, pour une raison de structure. Le HDMI Forum n’a rien publié, n’a rien annoncé et n’a modifié aucune de ses règles publiquement. Ses spécifications restent fermées. Ce qui s’est passé, quelle qu’en soit la cause exacte, est qu’un chemin a été trouvé pour ce cas précis. AMD a contourné l’obstacle ; elle ne l’a pas fait disparaître.

Le commentateur Linux Brodie Robertson le résumait en mai 2026 avec l’ironie qui convient : on approche enfin d’un HDMI 2.1 pleinement fonctionnel sous Linux avec les cartes AMD, « juste à temps pour que le HDMI 2.2 soit prêt et que le même problème recommence exactement à l’identique ». La norme suivante est en effet déjà spécifiée, et rien n’indique que son régime de confidentialité soit différent. Si aucune des parties ne change de doctrine, la prochaine génération de téléviseurs à très haute fréquence rouvrira le même dossier, avec les mêmes acteurs et probablement la même durée. Sur ce site, nous avons déjà vu ce genre de dépendance jouer sur un autre terrain, avec des moniteurs 1000 Hz dont les notes de bas de page imposent Windows 11, le DisplayPort 2.1 et une liste fermée de cartes graphiques, puis avec la réponse d’Acer.

Reste une question d’échelle, qui explique probablement la lenteur autant que le déblocage. Dans l’enquête matérielle Steam d’août 2026, Linux représentait 3,90 pour cent des machines, en léger recul, avec SteamOS comme première distribution, à environ 21 pour cent des machines Linux, devant CachyOS à 15,4 pour cent. Trois virgule neuf pour cent, c’est assez peu pour qu’un consortium ignore le problème pendant cinq ans. Mais le jour où une part significative de ces machines devient du matériel vendu en boîte par une entreprise qui a besoin que la sortie HDMI fonctionne sur un téléviseur, l’arithmétique change. Il aura fallu qu’un fabricant ait un intérêt commercial direct pour qu’un bogue de 2021 trouve une issue. C’est peut-être la leçon la moins réjouissante de cette affaire, et c’est sans doute la plus utile.

Ce que cet article n’établit pas

Des correctifs contenus dans une demande d’intégration ne sont pas un noyau publié : la demande adressée à DRM-Next le 10 septembre 2026 doit encore être fusionnée, et son contenu peut être modifié ou partiellement retenu d’ici la sortie de Linux 7.4. Le calendrier donné, ouverture de la fenêtre de fusion dans la seconde moitié d’octobre et sortie fin 2026 ou début 2027, est une estimation de Phoronix qui dépend du cycle de Linux 7.3. L’implication de Valve dans le déblocage est présentée par Phoronix comme une supposition largement partagée, pas comme un fait confirmé ; aucune des trois parties ne l’a établie publiquement. Nous n’avons effectué aucune mesure : cet article ne teste ni débit, ni latence, ni comportement de synchronisation, et ne compare les performances d’aucune carte graphique. Les fonctions décrites dépendent aussi de l’écran ou du téléviseur utilisé, qui doit lui-même prendre en charge le VRR HDMI, l’ALLM et les modes concernés. Les déclarations de Valve sur la Steam Machine datent de juin 2026 et concernent sa propre pile logicielle, pas le noyau principal. Enfin, rien dans cette annonce ne concerne le HDMI 2.2, dont le régime de spécification n’a pas été rendu public. Nous mettrons cet article à jour lorsque Linux 7.4 sera effectivement publié.

Questions fréquentes

À partir de quand le HDMI 2.1 fonctionnera-t-il par défaut sur ma Radeon sous Linux ?

À partir du noyau Linux 7.4, dont la fenêtre de fusion doit s’ouvrir dans la seconde moitié d’octobre 2026 et dont la sortie est attendue à la toute fin de 2026 ou en janvier 2027, selon Phoronix. Il faudra ensuite que votre distribution adopte ce noyau, ce qui peut prendre de quelques semaines à plusieurs mois selon qu’elle suit les versions récentes ou un support long terme.

Qu’est-ce que le FRL et pourquoi fallait-il l’activer ?

Le Fixed Rate Link est le mode de transmission introduit avec le HDMI 2.1, qui permet de dépasser les débits de l’ancien mode et donc d’atteindre des résolutions et des fréquences plus élevées. Son code était déjà présent dans Linux 7.2 mais désactivé par défaut : AMD attendait que le VRR et les fonctions associées soient prêts, pour éviter que des utilisateurs ne perdent au passage des fonctionnalités qui marchaient.

Suis-je concerné si je joue sur un moniteur en DisplayPort ?

Non. Le DisplayPort n’a jamais été touché par ce blocage, dont l’origine est la fermeture des spécifications HDMI au public en 2021. Cette annonce concerne les configurations reliées en HDMI, au premier rang desquelles les PC branchés sur un téléviseur, qui ne dispose pas de sortie DisplayPort.

À quoi sert l’Auto Low Latency Mode ?

Il permet à la source, ici le PC, de signaler au téléviseur qu’elle diffuse du jeu, afin que celui-ci bascule seul dans son mode jeu et désactive les traitements d’image qui ajoutent de la latence. Sans lui, il faut effectuer cette bascule manuellement dans les menus du téléviseur, puis la défaire pour regarder autre chose.

La Steam Machine est-elle concernée par cette mise à jour ?

Elle l’est moins que les autres, car Valve n’a pas attendu le noyau principal. Sa pile logicielle prend déjà en charge le VRR HDMI 2.1, en FreeSync comme en VRR du HDMI Forum, et l’architecte de SteamOS déclarait en juin 2026 que le problème était entièrement résolu. La sortie restait alors limitée au 4K à 120 Hz, Valve annonçant le 4K à 144 Hz sans compression et le 4K à 240 Hz avec compression pour une mise à jour ultérieure.

Sources : Phoronix, Michael Larabel, « Patches Ready For AMDGPU HDMI 2.1 Enabled By Default With Linux 7.4 With FreeSync, VRR & ALLM », 11 septembre 2026, et « AMD Preparing To Enable HDMI 2.1 FRL Support By Default For Linux », 27 août 2026 ; VideoCardz, « AMD HDMI 2.1 support set to be enabled by default in Linux 7.4 with FreeSync, VRR and ALLM », 11 septembre 2026 ; Phoronix, « HDMI Forum Rejects Open-Source HDMI 2.1 Driver Support Sought By AMD », février 2024, pour la citation d’Alex Deucher ; déclarations de Pierre-Loup Griffais à Digital Foundry, juin 2026, relayées par VideoCardz et TechPowerUp ; vidéos Brodie Robertson du 12 mai 2026 et RTBF iXPé du 4 septembre 2026, vérifiées le 13 septembre 2026 ; nos articles sur les pilotes Linux du moteur d’affichage DCN 6, sur la Steam Machine, sur GeForce Now sous Linux, sur les moniteurs 1000 Hz de LG et d’Acer et sur l’enquête matérielle Steam d’août 2026.