Re: [RFC PATCH] drm/drm_edid: ignore continuous frequency support for VRR

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Mon, Feb 23, 2026 at 05:29:46PM -0300, Melissa Wen wrote:
> Display can be VRR capable even if its EDID doesn't contain the
> Continuous Frequency flag. On the other hand, continuous frequency
> support is expected for smooth VRR and ensures better compatibility with
> VRR tehcnologies. As the lack of this flag can result in unexpected
> issues like tearing, get monitor range even without the guarantee of
> continuous frequency but add a debug message for unexpected results.
> 
> CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
> CC: Jani Nikula <jani.nikula@intel.com>
> CC: Harry Wentland <harry.wentland@amd.com>
> CC: Mario Limonciello <superm1@kernel.org>
> CC: Alex Hung <alex.hung@amd.com>
> Reported-by: Ivan Sergeev <ivan8215145640@gmail.com>
> Fixes: 0159f88a ("drm/amd/display: remove redundant freesync parser for DP")
> Signed-off-by: Melissa Wen <mwen@igalia.com>
> ---
> 
> Hello,
> 
> After replacing the AMD driver-specific parser for VRR with the drm_edid
> implementation, monitors without the continuous frequency flag in their
> EDID stopped obtaining the monitor range because the DRM common code
> considers them incompatible with VRR if they don't advertise support to
> continuous frequencies. This differs from the original driver-specific
> parser of AMD, that only checked EDID version, EDID_DETAIL_MONITOR_RANGE
> and DRM_EDID_RANGE_LIMITS_ONLY_FLAG to determine the VRR range, so
> switching to DRM common code caused a regression (reported by Ivan).
> 
> The commit ca2582c66b930 `drm/edid: Parse only the VRR range for
> continuous frequency displays` [1] introduced the Continuous Frequency
> flag condition. While it was created to avoid issues related to
> non-continuous refresh rates, it looks very restrictive to drivers that
> want to deal with VRR capable monitor even without the guarantee of
> continuous frequencies. I propose relaxing this restriction and adding a
> debug message if anyone experiences problems related to the lack of
> continuous frequency support.

AFAIK without the continuous frequency bit the monitor isn't guaranteed
to support all the refresh rates between min/max. So is this monitor
trying to tell us that you are allowed to change the vtotal dynamically
between the various explicit timings declared in the EDID but not between
any other other timings?

Or is it just a buggy EDID that needs quirking?

> 
> Maybe I'm missing something, so I would like to hear your opinions.
> 
> Obs.: In addition to the display kernel developers who have already
> worked with this code, I am sending copies to some compositor developers
> who may have an opinion on it.
> 
> [1] https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ca2582c66b930
> 
> Thanks in advance,
> 
> Melissa
> 
> 
>  drivers/gpu/drm/drm_edid.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index ff432ac6b569..8ebd1c17d78a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -6517,7 +6517,9 @@ static void drm_get_monitor_range(struct drm_connector *connector,
>  		return;
>  
>  	if (!(drm_edid->edid->features & DRM_EDID_FEATURE_CONTINUOUS_FREQ))
> -		return;
> +		drm_dbg_kms(connector->dev,
> +			    "[CONNECTOR:%d:%s] Display doesn't support continuous frequencies\n",
> +			    connector->base.id, connector->name);
>  
>  	drm_for_each_detailed_block(drm_edid, get_monitor_range, &closure);
>  
> -- 
> 2.51.0

-- 
Ville Syrjälä
Intel