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

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

On Mon, Apr 20, 2026 at 12:15:07PM -0300, Melissa Wen wrote:
> 
> 
> On 24/02/2026 09:49, 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/ 
> >
> 
> Hi Ville,
> 
> In the end, it wasn't clear to me if this approach is acceptable or 
> should I create a quirk for this monitor.
> WDYT?

That things seems to have some AMD vendor specific VRR block. I'm
thinking that needs to added to the EDID parser and it should probably
take precedence over the base EDID stuff.

There are also some patch floating around for the DisplayID adaptive
sync block. I have no idea what the priority should be between that
and the AMD vendor specific block.

-- 
Ville Syrjälä
Intel