AMD a publié le 1er septembre 2026 une nouvelle série de correctifs pour le VRR passif en HDMI dans le pilote noyau AMDGPU, et l'élément intéressant tient moins à la fonction qu'à la séparation. Le VRR passif voyageait jusqu'ici dans la grande série HDMI 2.1 dite de jeu, aux côtés du taux de rafraîchissement variable et du mode faible latence automatique, une série qui rate les fenêtres de fusion depuis longtemps. Il fait désormais l'objet d'une soumission distincte, activée par défaut avec possibilité de refus, visant Linux 7.4. Si votre bureau s'est déjà éteint une fraction de seconde au lancement d'un jeu, c'est le correctif concerné.
The short answer
Jerry Zuo, chez AMD, a publié le 1er septembre 2026 une série de correctifs actualisée ajoutant le VRR passif HDMI au pilote graphique noyau AMDGPU. Le VRR passif maintient l'écran HDMI dans son état de rafraîchissement variable pendant l'usage du bureau à taux fixe, ce qui supprime l'extinction ou la variation de luminosité que beaucoup de dalles affichent quand une sortie entre ou sort du mode VRR. Le code voyageait auparavant dans la grande série HDMI 2.1 de jeu, aux côtés du VRR et du mode faible latence automatique, et fait désormais l'objet d'une soumission distincte. Elle vise Linux 7.4, dont la fenêtre de fusion est attendue fin octobre, et elle est activée par défaut avec une option de refus.
Il existe un clignotement précis que les utilisateurs de Radeon en HDMI connaissent bien. Un jeu passe en plein écran, l'écran s'éteint une fraction de seconde ou la luminosité saute, puis tout rentre dans l'ordre. La même chose se produit au retour vers le bureau. Ce n'est le défaut d'aucun composant en particulier, c'est ce que font beaucoup de dalles quand on leur demande d'entrer ou de sortir du mode de rafraîchissement variable.
La réponse d'AMD, publiée à nouveau le 1er septembre 2026, consiste à cesser de le leur demander.
Ne jamais quitter l'état, ne jamais payer la transition
Le VRR passif maintient l'écran HDMI dans son état de rafraîchissement variable même lorsque le bureau tourne à taux fixe. L'écran reste où il est. Comme c'est le changement de mode qui produit l'extinction et le saut de luminosité, supprimer le changement de mode supprime l'artefact.
Cette formulation mérite d'être retenue, car elle explique le mot passif. Rien n'est fait varier au bénéfice du bureau. L'écran est simplement maintenu dans l'état où il se trouverait pendant un jeu, de sorte qu'entrer dans un jeu ou en sortir ne coûte rien visuellement. La partie active du rafraîchissement variable, l'alignement du rafraîchissement de la dalle sur la livraison des images, ne change pas et reste pilotée par l'application.
La série a été publiée par Jerry Zuo, chez AMD, et elle est activée par défaut, avec un moyen documenté de la refuser pour qui préfère l'ancien comportement. Ce choix se défend : l'extinction de transition est visible et agaçante, tandis qu'une dalle au comportement correct maintenue en rafraîchissement variable ne montre absolument rien.
La séparation, voilà la nouvelle
Le VRR passif n'est pas du code neuf. Il circulait dans la série HDMI 2.1 dite de jeu d'AMD, avec le taux de rafraîchissement variable et le mode faible latence automatique, et cette série a un historique de reprises, de resoumissions et de fenêtres de fusion manquées. Elle a raté Linux 7.3.
Extraire le VRR passif dans une série autonome change nettement ses chances, et la raison relève de la mécanique amont ordinaire plutôt que de quoi que ce soit de propre au code d'affichage. Une grande série regroupant plusieurs fonctions doit franchir la relecture sur toutes en même temps. Une seule question ouverte dans un seul correctif bloque l'ensemble. Une série ciblée qui fait une chose bien décrite est relue plus vite, reçoit des objections exploitables, et peut être intégrée pendant que le reste du paquet se discute encore.
C'est le même schéma que l'on observe ailleurs dans le noyau ce cycle. La MMU de KVM a été découpée en trois parties pour Linux 7.3 pour des raisons de maintenabilité et non pour une nouvelle capacité, et le travail eSPI d'AMD a été proposé comme un nouveau type de bus plutôt que greffé sur un sous-système existant. Les soumissions plus petites et plus claires avancent.
L'option de refus n'est pas décorative
Il faut être honnête sur la raison d'être de cette échappatoire.
Maintenir une dalle en permanence dans son état de rafraîchissement variable n'est pas gratuit sur tous les écrans. Le comportement à bas taux de rafraîchissement varie, et certains exemplaires montrent des variations de luminosité ou un scintillement visible quand le taux reste bas de façon prolongée plutôt que brève. Sur une telle dalle, une extinction nette au moment d'entrer dans un jeu peut être réellement préférable à un artefact permanent pendant que vous lisez une page web.
C'est aussi pour cela que les retours de tests sont la contribution la plus utile en ce moment. Le code se relit à partir du code. Savoir si un moniteur donné supporte huit heures en rafraîchissement variable, non, et aucun mainteneur ne possède votre écran. Si vous utilisez une Radeon en HDMI, tester la série sur votre affichage et publier le résultat pèse réellement sur la survie du réglage par défaut lors de la relecture.
Ce qu'il faut attendre, et quand
La fenêtre de fusion de Linux 7.4 devrait s'ouvrir fin octobre 2026. Viser n'est pas fusionner, et cette famille de correctifs a déjà glissé, donc la posture réaliste est l'intérêt plutôt que l'attente. Si l'intégration a lieu, le résultat visible sera l'absence de quelque chose : le clignotement auquel vous étiez habitué à chaque passage en plein écran cesse simplement de se produire, sur du matériel qui prenait déjà le VRR en charge depuis le début.
Rien à faire aujourd'hui, sauf si vous compilez vos propres noyaux. Dans ce cas, c'est une série courte, autonome, au changement de comportement clairement annoncé et à l'effet facilement observable, ce qui en fait un objet de test particulièrement agréable.
Sources et pour aller plus loin
- AMDGPU Linux Driver's Latest Patches For HDMI Passive VRR Support, Phoronix, 1er septembre 2026
- drm/amd: VRR fixes, HDMI Gaming Features, LWN.net
- AMD Updates HDMI 2.1 VRR and ALLM Patches But Will Miss Out On Linux 7.3, fil Linux.org
Questions fréquentes
Qu'est-ce que le VRR passif et quel problème résout-il ?
Le VRR passif maintient un écran HDMI dans son état de rafraîchissement variable pendant l'usage ordinaire du bureau à taux fixe, au lieu de le faire entrer et sortir du mode VRR au gré des applications. Le problème résolu est la transition elle-même. Faire entrer ou sortir un écran du mode VRR provoque sur de nombreuses dalles une extinction brève ou une variation de luminosité, ce fameux clignotement que l'on remarque quand un jeu passe en plein écran ou quand on revient au bureau. Si l'écran ne quitte jamais l'état de rafraîchissement variable, il n'y a plus de transition, donc plus de clignotement.
Quelle version du noyau est visée ?
Linux 7.4, dont la fenêtre de fusion devrait s'ouvrir fin octobre 2026. Le code a manqué Linux 7.3. Il faut le dire clairement, car la grande série HDMI 2.1 dont ce travail est extrait a un long historique de reports, et viser n'est pas fusionner. Ce qui améliore les chances ici, c'est précisément la séparation : une série ciblée qui fait une seule chose se relit plus facilement et s'accepte plus facilement qu'un gros ensemble regroupant plusieurs fonctions d'affichage, chacune avec ses questions en suspens.
Pourquoi AMD l'a-t-elle séparée de la série HDMI 2.1 de jeu ?
Le travail HDMI 2.1 de jeu regroupe le taux de rafraîchissement variable, le mode faible latence automatique et le VRR passif dans une soumission unique, et cet ensemble a été retravaillé et resoumis plusieurs fois sans être intégré. Isoler le VRR passif permet de le relire sur ses propres mérites et de le fusionner à son propre rythme. C'est une tactique amont normale et sensée : quand une série s'enlise, les parties prêtes cessent d'attendre celles qui ne le sont pas. Les autres fonctions HDMI 2.1 poursuivent leur chemin séparément.
Est-ce activé par défaut et peut-on le désactiver ?
C'est activé par défaut dans la série publiée, avec une option de refus pour qui préfère l'ancien comportement. Ce choix par défaut est le bon pour la plupart des gens, car l'extinction à la transition est une gêne visible tandis que rester en rafraîchissement variable est invisible quand cela fonctionne. L'option de refus compte parce que le comportement des dalles maintenues en permanence en rafraîchissement variable n'est pas uniforme. Certains écrans présentent des variations de luminosité ou un scintillement à bas taux de rafraîchissement, et sur une telle dalle une extinction unique à la transition est peut-être préférable à un artefact permanent.
Que faut-il faire concrètement aujourd'hui ?
Rien d'urgent, et une chose si vous testez déjà des noyaux. Il s'agit d'une série de correctifs publiée, pas d'une fonction livrée : aucun noyau stable actuel ne l'embarque. Si vous utilisez une carte Radeon en HDMI et que le clignotement de transition vous dérange, la contribution utile consiste à tester la série sur votre dalle précise et à rapporter le résultat, car le comportement des écrans est exactement la variable que la relecture de code ne peut pas trancher. Les autres peuvent noter la cible Linux 7.4, attendre la fenêtre de fusion fin octobre et consulter les notes d'AMDGPU à ce moment-là.