Skip to content
InYourGeek
visiteur@inyourgeek — shell
compléter historique ouvrirhelp
FR
Hardware· 3 min read

Intel finally switches on CMRR in Linux 7.4 — just not on Lunar Lake

A patch series from Intel heading into Linux 7.4 wakes up Content Match Refresh Rate after nearly two years switched off. It promises stutter-free video playback — just not on the machines that introduced it.

A laptop screen playing a video, with a refresh-rate readout showing a fractional frequency next to Intel's graphics driver code

Since 2023, Intel has been carrying around a feature in its open-source graphics driver that is named like a line from a spec sheet: Content Match Refresh Rate. On September 3, 2026, Phoronix spotted the patch series that finally takes it out of the drawer, headed for the Linux 7.4 kernel.

Sync the panel to the video, not to the GPU

VRR — the Adaptive-Sync you already know — makes the display chase whatever frame rate the graphics card manages to push out. That is built for games, where the frame rate is jittery by nature. CMRR, which arrived with the Xe2 graphics hardware in Lunar Lake, is after something else: matching the cadence of the content itself, more precisely than ordinary VRR can. The stated goal is video playback with no stutter and no dropped frames.

You can gauge how precise by looking at the control interface: the target frequency is expressed in millihertz, and you can hand it a denominator for video timing. Translation: video frame rates do not land on round numbers, and rounding them off is exactly what gives you that little hiccup every few seconds.

Two years of code sitting in the dark

Phoronix was already on this in 2023, before Lunar Lake had even shipped. Panther Lake and Wildcat Lake have landed since, the CMRR patches have lived in the driver for the best part of two years — and the feature has never actually been put to use under Linux. Intel engineer Mitul Golani takes inventory in the series: the fractional timing code was permanently disabled, restricted to eDP (the internal laptop panel), and leaned on a heuristic to guess when that path was needed. A feature switched off, wired to a single connection type, and guessing. The new patches go after all three.

The knob lives in DebugFS

Pending the real userspace API — announced, not yet here — control takes the shape of one DebugFS file per CRTC: you write in the refresh rate you are aiming for and the video-mode requirement. It is an Intel-driver-specific interface, handy for testing, not something your video player is going to pick up on its own tomorrow morning.

The hardware that benefits is not the one you would expect

Here is the detail that reframes the whole announcement: enabling it by default only applies where the VRR timing comes from the default timing generator, which today means Display IP version 30 and up — that is Xe3, Panther Lake and beyond. So the generation that introduced CMRR is not the generation that gets it switched on out of the box. And battery life never comes up anywhere: this is about playback smoothness, not watts saved.

The same drm-intel-next pull request also brings along the port of DG2’s multi-protocol PLL code to the DPLL framework, display stream compression fixes for DP-HDMI PCONs, and a batch of cleanups. The Linux 7.4 merge window opens in late October, so Intel still has several weeks to slip something else in.

Two years to switch a feature back on, and it comes back on for the next generation. CMRR did pull off one piece of perfect synchronization after all: its schedule with the product refresh cycle.

Sources (1)

Written with AI assistance from the sources cited above, then reviewed and approved before publication by Sébastien Soulier.