Intel muscle son CMRR dans Linux 7.4, mais pas pour Lunar Lake
Une série de correctifs Intel en route vers Linux 7.4 réveille le Content Match Refresh Rate, resté éteint près de deux ans. La fonction promet une lecture vidéo sans saccade, mais pas sur les machines qui l'ont inaugurée.

Depuis 2023, Intel promène dans son pilote graphique libre une fonction au nom de spécification technique : le Content Match Refresh Rate. Le 3 septembre 2026, Phoronix a repéré la série de correctifs qui la sort enfin du placard, en route pour le noyau Linux 7.4.
Caler l’écran sur la vidéo, pas sur le GPU
Le VRR — l’Adaptive-Sync que vous connaissez — fait suivre à l’écran la cadence que la carte graphique arrive à produire. C’est pensé pour le jeu, où le débit d’images est irrégulier par nature. Le CMRR, arrivé avec le matériel graphique Xe2 de Lunar Lake, vise autre chose : coller à la cadence du contenu lui-même, plus précisément que le VRR classique. L’objectif affiché est la lecture vidéo sans saccade ni image perdue.
Le degré de précision se lit dans l’interface de contrôle : la fréquence cible s’exprime en milli-hertz, et on peut lui adjoindre un dénominateur pour le timing vidéo. Traduction : les cadences vidéo ne tombent pas sur des nombres ronds, et arrondir est exactement ce qui produit le micro-à-coup toutes les quelques secondes.
Deux ans de code présent mais éteint
Phoronix suivait le sujet dès 2023, avant même la sortie de Lunar Lake. Depuis, Panther Lake et Wildcat Lake sont arrivés, les correctifs CMRR ont vécu près de deux ans dans le pilote — et la fonction n’a jamais été réellement exploitée sous Linux. L’ingénieur Intel Mitul Golani dresse l’inventaire dans sa série : le code de timing fractionnaire était désactivé en permanence, limité à l’eDP (la dalle interne des portables), et reposait sur une heuristique pour deviner quand il fallait emprunter ce chemin. Une fonction éteinte, cantonnée à un seul type de connexion, et qui devine. Les nouveaux correctifs s’attaquent aux trois.
Le réglage se fait dans DebugFS
En attendant la vraie API côté espace utilisateur, annoncée mais pas encore là, le contrôle prend la forme d’un fichier DebugFS par CRTC : on y écrit la fréquence de rafraîchissement visée et l’exigence de mode vidéo. C’est une interface spécifique au pilote Intel, pratique pour tester, pas pour que votre lecteur vidéo s’en serve tout seul demain matin.
Le matériel qui en profite n’est pas celui qu’on croit
Voilà le détail qui change la lecture de l’annonce : l’activation par défaut ne vaut que dans les cas où le timing VRR est produit par le générateur de timing par défaut, ce qui aujourd’hui signifie Display IP version 30 et plus — soit Xe3, Panther Lake et au-delà. La génération qui a inauguré le CMRR n’est donc pas celle qui l’obtient activé d’office. Et le sujet de l’autonomie n’apparaît nulle part : on parle de fluidité de lecture, pas de watts économisés.
Le même pull request drm-intel-next embarque au passage l’adaptation du code PLL multi-protocole de DG2 au framework DPLL, des corrections sur la compression de flux d’affichage pour les PCON DP-HDMI, et un lot de nettoyages. La fenêtre de merge de Linux 7.4 s’ouvre fin octobre : Intel a encore plusieurs semaines pour y glisser autre chose.
Deux ans pour rallumer une fonction, et elle se rallume sur la génération suivante. Le CMRR aura au moins réussi une synchronisation parfaite : celle du calendrier avec le renouvellement de gamme.
Sources (1)
Article rédigé avec l'assistance d'une IA à partir des sources citées, puis relu et validé avant publication par Sébastien Soulier.


