AMDGPU Splits Off HDMI Passive VRR Support, Targets Linux 7.4

As AMD continues to work on HDMI 2.1 support in its upstream AMDGPU kernel graphics driver, the latest patches for Passive VRR for HDMI connections have been published. According to reporting by Michael Larabel at Phoronix, a new patch series was sent out on September 1, 2026.

As part of AMD’s ongoing effort for getting HDMI 2.1 support squared away in their upstream AMDGPU kernel graphics driver, sent out today were the latest patches around passive variable refresh rate “Passive VRR” for HDMI connections.

The patches improve display handling when HDMI output transitions to variable refresh rate. They are drawing attention as preparation for the Linux 7.4 merge window.

Challenges Addressed by Passive VRR

Passive VRR is a feature designed to avoid screen blanking and brightness flicker that occurs when HDMI output transitions to VRR mode. In conventional HDMI implementations, there have been reports of output momentarily dropping when switching from a desktop environment running at a fixed refresh rate to games or video playback at a variable refresh rate. The cause is the insertion of a black screen as the display resynchronizes and brightness fluctuations due to mismatched backlight control.

Passive VRR is a technique to make this transition less noticeable. It keeps the HDMI sink in a variable refresh state while continuing to render the desktop at a fixed refresh rate. This avoids triggering a mode switch again when VRR is actually needed, suppressing visual interruptions. From the user’s perspective, it reduces the sense of incongruity when moving from window operations or web browsing to launching a game. It is expected to be particularly effective in environments where high-refresh-rate gaming monitors or TVs are connected via HDMI.

While this kind of flicker is not a functional defect, it is a factor that affects quality of experience. AMD has been continuously addressing this area as part of its HDMI 2.1 support. The latest patches are positioned to enable this countermeasure persistently on the kernel driver side.

Specification Differences Between HDMI and

DisplayPort

The handling of VRR transitions differs depending on the connection standard. For DisplayPort and Embedded DisplayPort, seamless VRR transitions are mandated by the specification. The standard design is for the source and sink to cooperatively adjust the refresh rate dynamically without causing display interruption during mode switching. Therefore, when using VRR over DisplayPort, the additional measures introduced here are unnecessary.

The situation is different for HDMI. HDMI’s VRR implementation differs from DisplayPort in the balance between mandatory specification requirements and implementation flexibility. Explicit transitions between fixed and variable refresh are more likely to occur, and when the sink resynchronizes at that time, black screens or brightness fluctuations may occur. Passive VRR is a driver-side workaround to absorb this HDMI-specific behavior.

AMD’s AMDGPU driver handles both DisplayPort and HDMI through the same display stack. It controls VRR with common code while inserting Passive VRR maintenance handling only for the HDMI path. Reporting by Michael Larabel at Phoronix notes that Passive VRR is not an issue for DisplayPort but is effective for HDMI. It can be seen as a typical example of compensating for specification differences in the driver.

Background of HDMI 2.1 Support and Patch

Separation

The current Passive VRR support was previously provided as part of the HDMI 2.1 gaming patch series. The Passive VRR implementation had been bundled within a comprehensive HDMI 2.1 feature set that includes VRR and ALLM (Auto Low Latency Mode). HDMI 2.1 is a standard that bundles multiple features such as high-bandwidth transmission, variable refresh rate, and low-latency mode. AMD has been working to bring these features upstream to the kernel in stages.

In the latest development, the code related to Passive VRR has been split into an independent patch series. The aim is seen as clarifying review units per feature and smoothing integration upstream. The overall HDMI 2.1 support is large in scope, making the split reasonable from the perspective of reviewer load and test coverage. Features such as VRR and ALLM each have different verification aspects, and Passive VRR is a change focused specifically on display transition quality. The separation makes it possible to discuss and revise Passive VRR on its own without depending on the progress of other HDMI 2.1 features.

This split also aligns with Linux kernel development practices. Large feature additions are recommended to be divided into logically independent series and merged incrementally. Within AMD’s ongoing effort to submit HDMI 2.1 support upstream, this separation can be seen as indicating a more mature stage.

Enabled by Default with an Option to Disable

In the published patch series, Passive VRR is designed to be enabled by default. Even without special configuration by the user, the maintenance handling is automatically applied on HDMI connections, suppressing flicker during VRR transitions. At the same time, an option to disable it is also provided for those who do not want this behavior. It is possible to revert to the previous behavior that allows screen blanking and flicker when transitioning to VRR mode.

The decision to enable it by default reflects that the benefits are significant for many users. In environments where HDMI is used for gaming or video viewing, less disruption during transitions is preferable. Retaining a path to disable it allows for cases where maintaining Passive VRR causes side effects on certain displays or TVs. Implementations on the display side vary, and for some sinks, maintaining a variable refresh state may cause unexpected behavior. Keeping the option available is a design that balances compatibility and quality.

Switching via kernel parameters or module options is anticipated, but the specific operating instructions are expected to be documented as the upstream integration progresses. When distributions adopt Linux 7.4 and later, users will benefit without additional configuration.

Outlook for Integration in the Linux 7.4

Merge Window

According to reporting by Michael Larabel at Phoronix, review and preparation are expected to proceed so that these additional HDMI 2.1 features for AMDGPU make it in time for the Linux 7.4 merge window opening in late October. The merge window is the consensus-building period for incorporating features into the next kernel. After review, testing, and revisions, maintainers will decide on inclusion.

The AMDGPU driver is an area of active development within the kernel. Display, power management, and compute functions are closely intertwined, and changes have a wide impact. HDMI 2.1 support is a field where compliance with external specifications is required, and reviews carefully check specification conformance and impact on existing hardware. For changes that are enabled by default, such as Passive VRR, the absence of regressions is a key focus.

In recent kernel development, optimizations have proceeded in parallel across subsystems such as display, memory management, and networking. As with performance improvements like Linux Cache Aware Scheduling Extension, MySQL Up to 360% Faster, security-related analysis such as Windows GDID Contributes to Identifying Scattered Spider Suspects, and data protection trends like OpenAI Announces Private Safety Processing, Achieving Zero Data Retention, collaboration between the kernel and surrounding technologies is becoming increasingly important. The AMDGPU HDMI improvements can also be positioned as steady enhancements that raise end-user quality of experience.

The upstreaming of overall HDMI 2.1 support also demonstrates the continuity of AMD’s open-source strategy. Rather than holding patches downstream for a long time, integrating them upstream early promotes testing across a wide range of distributions and hardware. The separation of Passive VRR can be seen as a move to accelerate that process.

Editorial Opinion

In the short term, we see clear benefits for Linux users who use gaming monitors or TVs over HDMI. If reviews proceed smoothly toward the Linux 7.4 merge window in late October, the default experience could improve in major distributions from the end of the year to next spring. We consider the design of enabled by default yet disableable to be a reasonable choice for broad rollout while curbing reports of compatibility issues. In the long term, we believe the effort to bridge the experience gap between HDMI and DisplayPort in the driver demonstrates the maturity of the open-source graphics stack as a whole. Continuing HDMI 2.1 support in the upstream kernel despite the constraints of HDMI Forum specification handling and certification will help expand gaming use of the Linux desktop. From a one- to three-year perspective, progress in upstreaming HDMI 2.1 features including VRR and ALLM is expected to reduce dependence on vendor-specific patches. The remaining question is how to quantify the impact of maintaining Passive VRR on power consumption and display latency. The cost of maintaining a variable refresh state while rendering the desktop at a fixed refresh rate calls for measurement and disclosure.

References

• “AMDGPU Linux Driver’s Latest Patches For HDMI Passive VRR Support”, by Michael Larabel — Phoronix, 2026-09-01T20:41:59.000Z (ARR)
• Source URL: https://www.phoronix.com/news/AMDGPU-HDMI-Passive-VRR