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

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

On Tue, Feb 24, 2026 at 09:49:17AM -0300, Melissa Wen wrote:
> 
> 
> On 24/02/2026 04:49, Ville Syrjälä wrote:
> > 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?
> 
> Looks like a buggy EDID. From decoded EDID I understand it supports all
> refresh rates between 48Hz/75Hz (very small range anyway), without the
> continuous freq flag in Features:
> 
> ```
>    EDID Structure Version & Revision: 1.4
>    Vendor & Product Identification:
>      Manufacturer: SKG
>      Model: 10003
>      Made in: week 25 of 2023
>    Basic Display Parameters & Features:
>      Digital display
>      Bits per primary color channel: 10
>      DisplayPort interface
>      Maximum image size: 60 cm x 33 cm
>      Gamma: 2.20
>      DPMS levels: Off
>      Supported color formats: RGB 4:4:4, YCrCb 4:4:4, YCrCb 4:2:2
>      First detailed timing includes the native pixel format and 
> preferred refresh rate
>    Color Characteristics:
> 
> [...]
> 
> Detailed Timing Descriptors:
> [...]
>     Display Range Limits: Monitor ranges (Bare Limits): 48-75 Hz V, 
> 223-223 kHz H, max dotclock 400 MHz
> [...]
> 
> Vendor-Specific Data Block (AMD), OUI 00-00-1A:
> Version: 2.1
> Minimum Refresh Rate: 48 Hz
> Maximum Refresh Rate: 75 Hz
> [...]
> ```
> 
> The reporter shared the EDID here:
> - 
> https://lore.kernel.org/amd-gfx/CAKx_Wg7_HBxuq5W4T_AmoFYJGQpa6TAS_Fx9SUzyy1itPmj5Bw@mail.gmail.com/

I see no mention of the model of the display. What is it, and is it
really supposed to support VRR?

> 
> Melissa
> 
> >
> >> 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