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/

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

Reply via email to