On Mon, 16 Feb 2026, Tomasz Pakuła <[email protected]> wrote:
> [Why]
> Some monitors only expose their full VRR range in AMD vsdb for some
> reason.
>
> [How]
> Compare exposed ranges and use the bigger one.
> Only adjust lower limit if it doesn't support LFC
>
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4177
> Signed-off-by: Tomasz Pakuła <[email protected]>
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 31 +++++++++++++++++++
>  1 file changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index b3bf5e0c19a5..f36059bb0324 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -13269,6 +13269,34 @@ static bool copy_range_to_amdgpu_connector(struct 
> drm_connector *conn)
>       return is_freesync_capable(range);
>  }
>  
> +static void extend_range_from_vsdb(struct drm_display_info *display,
> +                                const struct amdgpu_hdmi_vsdb_info *vsdb)
> +{
> +     u16 vrr_min = display->monitor_range.min_vfreq;
> +     u16 vrr_max = display->monitor_range.max_vfreq;
> +
> +     /* Always extend upper limit */
> +     if (vsdb->max_refresh_rate_hz > vrr_max)
> +             vrr_max = vsdb->max_refresh_rate_hz;
> +
> +     /*
> +      * Only extend lower limit if current one disables LFC.
> +
> +      * During widespread testing, we found that some manufacturers probably
> +      * had issues with their monitors' lower VRR boundaries and adjusted
> +      * them up (Gigabyte X34GS with official range 48 - 180, AMD vsdb 48 -
> +      * 180 yet Monitor Ranges 55 - 180). After setting the lower boundary
> +      * from AMD vsdb, such monitors start having blanking issues.
> +      *
> +      * Work around that by not touching VRR min if it still supports LFC.
> +      */
> +     if (vsdb->min_refresh_rate_hz < vrr_min && (vrr_min * 2 >= vrr_max))
> +             vrr_min = vsdb->min_refresh_rate_hz;
> +
> +     display->monitor_range.min_vfreq = vrr_min;
> +     display->monitor_range.max_vfreq = vrr_max;

Random driver code should *not* modify struct drm_display_info,
especially the fields that drm_edid.c parses. Drivers should cease to
parse EDID and DisplayID altogether.

I'm on the verge of NAKing, to the extent that I have control over this,
any further improvements on driver EDID/DisplayID parsing, with the
expectation that everything's moved to shared EDID parser in drm_edid.c
first, and improved there.

BR,
Jani.


> +}
> +
>  /**
>   * amdgpu_dm_update_freesync_caps - Update Freesync capabilities
>   *
> @@ -13339,6 +13367,9 @@ void amdgpu_dm_update_freesync_caps(struct 
> drm_connector *connector,
>               if (is_monitor_range_invalid(connector))
>                       monitor_range_from_vsdb(&connector->display_info, 
> &vsdb_info);
>  
> +             /* Try extending range if found in AMD vsdb */
> +             extend_range_from_vsdb(&connector->display_info, &vsdb_info);
> +
>               if (dpcd_caps.allow_invalid_MSA_timing_param)
>                       freesync_capable = 
> copy_range_to_amdgpu_connector(connector);

-- 
Jani Nikula, Intel

Reply via email to