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
