AMD posted a fresh patch series for HDMI Passive VRR in the upstream AMDGPU kernel driver on September 1, 2026, and the interesting part is not the feature so much as the split. Passive VRR used to travel inside the larger HDMI 2.1 gaming series alongside variable refresh rate and auto low latency mode, a series that has repeatedly missed merge windows. It is now its own submission, enabled by default with an opt out, aimed at Linux 7.4. If you have ever watched your desktop blank or flash when a game takes the display into VRR, this is the patch for that.
The short answer
AMD's Jerry Zuo posted an updated patch series on September 1, 2026 adding HDMI Passive VRR to the upstream AMDGPU kernel graphics driver. Passive VRR keeps an HDMI sink in its variable refresh state during fixed refresh desktop use, which removes the blanking or brightness flicker that many panels show when an output transitions into or out of VRR mode. The code was previously carried inside the larger HDMI 2.1 gaming series alongside VRR and auto low latency mode, and has now been split into its own submission. It targets Linux 7.4, whose merge window is expected in late October, and is enabled by default with an opt out.
There is a specific flash that Radeon users on HDMI know well. A game goes fullscreen, the display drops out for a fraction of a second or the brightness jumps, and then everything is fine. The same thing happens on the way back to the desktop. It is not a bug in any single component, it is what a lot of panels do when they are told to enter or leave variable refresh mode.
AMD's answer, posted again on September 1, 2026, is to stop telling them.
Never leave the state, never pay for the transition
Passive VRR keeps the HDMI sink in its variable refresh state even while the desktop is running at a fixed refresh rate. The display stays where it is. Because the mode change is what produces the blank and the brightness shift, removing the mode change removes the artefact.
That framing is worth holding onto, because it explains why the feature is called passive. Nothing is being varied for the benefit of the desktop. The sink is simply held in the state it would be in during a game, so that entering and leaving a game costs nothing visually. The active part of variable refresh, matching the panel refresh to frame delivery, is unchanged and continues to be driven by the application.
The series was posted by Jerry Zuo at AMD and is enabled by default, with a documented way to opt out for anyone who prefers the old behaviour. That default is defensible: the transition blank is visible and annoying, and a correctly behaving panel held in the variable refresh state shows nothing at all.
The split is the news
Passive VRR is not new code. It has been travelling inside AMD's HDMI 2.1 gaming patch series, together with variable refresh rate and auto low latency mode, and that series has a history of being reworked, resubmitted and missing merge windows. It missed Linux 7.3.
Carving Passive VRR out into a standalone series changes its odds materially, and the reason is ordinary upstream mechanics rather than anything specific to display code. A large series that bundles several features has to clear review on all of them at once. One open question in one patch holds the whole thing. A focused series that does a single well described thing gets reviewed faster, gets objections that are actionable, and can land while the rest of the bundle is still being argued about.
It is the same pattern visible elsewhere in the kernel this cycle. The KVM MMU was split into three parts for Linux 7.3 for maintainability rather than for any new capability, and AMD's eSPI work was posted as a new bus type rather than as an extension bolted onto an existing subsystem. Smaller, clearer submissions move.
The opt out is not decoration
Worth being honest about why the escape hatch exists.
Holding a panel in its variable refresh state permanently is not free on every display. Panel behaviour at low refresh rates varies, and some units show brightness variation or visible flicker when the refresh rate sits low for a sustained period rather than briefly. On such a panel, one clean blank at the moment you enter a game may genuinely be preferable to a persistent artefact while you read a web page.
This is also why testing reports are the most useful thing a reader can contribute right now. The code is reviewable from the code. Whether a given monitor is happy sitting in a variable refresh state for eight hours is not, and no maintainer has the panel you own. If you run a Radeon card on HDMI, testing the series against your specific display and reporting the result is a real contribution to whether the default survives review.
What to expect and when
Linux 7.4's merge window is expected to open in late October 2026. A target is not a merge, and this particular family of patches has slipped before, so the realistic posture is interest rather than expectation. If it lands, the visible result is the absence of something: the flash you were used to at every fullscreen transition simply stops happening, on hardware that already supported VRR the whole time.
Nothing to do today unless you build your own kernels. If you do, this is a small, self contained series with a clearly stated behaviour change and an easily observed effect, which makes it an unusually pleasant thing to test.
Sources and further reading
- AMDGPU Linux Driver's Latest Patches For HDMI Passive VRR Support, Phoronix, September 1, 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, Linux.org news thread
Frequently asked questions
What is Passive VRR and what problem does it solve?
Passive VRR keeps an HDMI sink in its variable refresh state during ordinary fixed refresh desktop use, rather than switching the sink in and out of VRR mode as applications come and go. The problem it solves is the transition itself. Moving a display into or out of VRR mode causes many panels to blank briefly or to shift brightness, which is the flash people notice when a game goes fullscreen or when they alt tab back to the desktop. If the sink never leaves the variable refresh state, there is no transition and no flash.
Which kernel release is this targeting?
Linux 7.4, whose merge window is expected to open in late October 2026. The code missed Linux 7.3. That is worth stating plainly because the broader HDMI 2.1 gaming series this was carved out of has a long record of slipping releases, and a target is not a merge. What improves the odds here is precisely the split: a focused series that does one thing is easier to review and easier to accept than a large series bundling several display features together, each with its own open questions.
Why did AMD separate it from the HDMI 2.1 gaming series?
The HDMI 2.1 gaming work bundles variable refresh rate, auto low latency mode and Passive VRR into a single submission, and that bundle has been reworked and resubmitted several times without landing. Splitting Passive VRR out means it can be reviewed on its own merits and merged on its own schedule. It is a normal and sensible upstream tactic: when a series stalls, the parts that are ready stop waiting on the parts that are not. The remaining HDMI 2.1 features continue separately.
Is it on by default and can I turn it off?
It is enabled by default in the posted series, with an opt out for anyone who would rather keep the old behaviour. That default is the right one for most people, since the transition blank is a visible annoyance and staying in the variable refresh state is invisible when it works. The opt out matters because panel behaviour under a permanently variable refresh state is not uniform. Some displays exhibit brightness variation or flicker at low refresh rates, and on such a panel you may prefer a single blank at transition over a persistent artefact.
What should I actually do about this today?
Nothing urgent, and one thing if you are already testing kernels. This is a posted patch series, not a shipped feature, so no current stable kernel has it. If you run a Radeon card on HDMI and the VRR transition flash bothers you, the useful contribution is to test the series against your specific panel and report the result, because panel behaviour is exactly the variable that review cannot determine from the code. Everyone else should note the Linux 7.4 target, expect the merge window in late October, and check the AMDGPU release notes then.