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ä <[email protected]> > >> CC: Jani Nikula <[email protected]> > >> CC: Harry Wentland <[email protected]> > >> CC: Mario Limonciello <[email protected]> > >> CC: Alex Hung <[email protected]> > >> Reported-by: Ivan Sergeev <[email protected]> > >> Fixes: 0159f88a ("drm/amd/display: remove redundant freesync parser for > >> DP") > >> Signed-off-by: Melissa Wen <[email protected]> > >> --- > >> > >> 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_fx9suzyy1itpmj...@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
