RE: [External Mail] Re: Test result / finding of "drm/amd/display: Consult MCCS FreeSync cap only if requested & supported"

[Pei-Hsin Yang <peihsiny@valvesoftware.com>]

Hi Michel,

> Tested with 3 HDMI sinks with different FreeSync/HDMI VRR capabilities.  I saw one case that a FreeSync sink (Dell S2721HS) with E6h VCP code supported was detected as FreeSync capable at beginning but identified as not FreeSync capable later – after do_mccs is changed from true to false.

>> And that doesn't happen without my patch applied?

There are other issues without your patch applied.   One issue is that if a FreeSync capable sink with MCCS VCP Code = 0 (mostly are TVs), it will be detected as not FreeSync supported and VRR will be disabled.

>> TBH I don't really want to be fixing the regression I hit, I'd prefer the AMD display team to handle it.

Yes, agreed.  As FreeSync MCCS support has immediate impacts to Valve's Steam devices, I will work with AMD display team to handle it.   HDMI 2.1 VRR and VTEM packet sending support need to be included as well.

Thanks,
Pei-Hsin

-----Original Message-----
From: Michel Dänzer <michel.daenzer@mailbox.org> 
Sent: Wednesday, May 20, 2026 12:49 AM
To: Pei-Hsin Yang <peihsiny@valvesoftware.com>
Cc: amd-gfx@lists.freedesktop.org
Subject: [External Mail] Re: Test result / finding of "drm/amd/display: Consult MCCS FreeSync cap only if requested & supported"

On 5/19/26 22:12, Pei-Hsin Yang wrote:
> 
> Here is my test result and finding after applying Michel Dänzer’s patch on May 18, 2026 to SteamOS 6.16 branch.
> 
>  
> 
> Applied patch from Michael Dänzer to SteamOS 6.16.
> 
>  
> 
> Tested with 3 HDMI sinks with different FreeSync/HDMI VRR capabilities.  I saw one case that a FreeSync sink (Dell S2721HS) with E6h VCP code supported was detected as FreeSync capable at beginning but identified as not FreeSync capable later – after do_mccs is changed from true to false.

And that doesn't happen without my patch applied?


> I understood the recent implementation to determine freesync_capable is trusting hardware (via MCCS VCP transaction) over EDID.  But in real world application, it does cause certain false detection to inadvertently disable the VRR.
> 
>  
> 
> My opinion is: If EDID has AMD FreeSync VSDB specified with valid refresh rate range, then it should be determined as FreeSync capable.  As for MCCS VCP Code support, it is used to send Set command to sink to enable/disable the VRR handling.  Result of dm_helpers_read_mccs_caps() at runtime should not override the freesync_capable value.  Because the impact of MCCS VCP Code Set command failure is significantly lower than the disabling VRR when sink is capable.

I basically agree.


TBH I don't really want to be fixing the regression I hit, I'd prefer the AMD display team to handle it.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast