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 <[email protected]> Sent: Wednesday, May 20, 2026 12:49 AM To: Pei-Hsin Yang <[email protected]> Cc: [email protected] 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
