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

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

[Melissa Wen]

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.

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

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

[Ville Syrjälä]

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

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

[Melissa Wen]

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/

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

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

[Ville Syrjälä]

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

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

[Ivan Sergeev]

On Wed Feb 25, 2026 at 10:18 AM MSK, Ville Syrjälä wrote:
> I see no mention of the model of the display. What is it, and is it
> really supposed to support VRR?

The display is DEXP DQ27N2. It has a Freesync option in the on-screen
menu, and it is turned on.

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

[Melissa Wen]

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?

Melissa

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

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

[Ville Syrjälä]

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