Test result / finding of "drm/amd/display: Consult MCCS FreeSync cap only if requested & supported"

Test result / finding of "drm/amd/display: Consult MCCS FreeSync cap only if requested & supported"

[Pei-Hsin Yang]

[-- Attachment #1.1: Type: text/plain, Size: 1482 bytes --]

Hi all,

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.
[cid:image001.png@01DCE790.20A0ACA0]

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. When I brought up the Steam Quick Access Menu, "Enable VRR" setting is grayed out and can no longer enable the VRR.  This is a very severe side effect.

Kernel log below shows the FreeSync capable transition:
[cid:image002.png@01DCE790.20A0ACA0]

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.

Thanks,
Pei-Hsin

[-- Attachment #1.2: Type: text/html, Size: 4118 bytes --]

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 58659 bytes --]

[-- Attachment #3: image002.png --]
[-- Type: image/png, Size: 275090 bytes --]

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

[Michel Dänzer]

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

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

[Pei-Hsin Yang]

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

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

[Michel Dänzer]

On 5/20/26 17:54, Pei-Hsin Yang wrote:
> 
>> 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.

That sounds similar to https://gitlab.freedesktop.org/drm/amd/-/work_items/5286 .


I was wondering if the specific issue you described above with Dell S2721HS is reproducible without my patch though, in which case it might be a separate regression (and wouldn't speak against merging my patch).


>>> 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.

Note that some kind of short-term solution is needed for the regression(s) in 7.1-rc.


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

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

[Pei-Hsin Yang]

[-- Attachment #1: Type: text/plain, Size: 2763 bytes --]

> Note that some kind of short-term solution is needed for the regression(s) in 7.1-rc.

Here is my suggestion as a short-term workaround:  
	- Just refer to the vsdb_info data structure to set the value of freesync_capable.  freesync_mccs_vcp_code = 0 doesn't mean FreeSync is not supported.
	- Check both freesync_supported and freesync_mccs_vcp_code along with do_mccs to call dm_helpers_mccs_vcp_set().
	- Note that MCCS command over DDC might be failed at runtime, but at least, it will not inadvertently disable the VRR if (1) sink is FreeSync supported but vcp_code = 0, or (2) dm_helpers_read_mccs_cap() failed intermittently at runtime.

Patch created based on commit 53f0235c0284fc676d1510a460e1c6c111de3ea1 is attached as a reference for AMD team to review.

commit 53f0235c0284fc676d1510a460e1c6c111de3ea1 (HEAD -> amd-staging-drm-next, origin/amd-staging-drm-next, origin/HEAD)

Thanks
Pei-Hsin


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

On 5/20/26 17:54, Pei-Hsin Yang wrote:
> 
>> 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.

That sounds similar to https://gitlab.freedesktop.org/drm/amd/-/work_items/5286 .


I was wondering if the specific issue you described above with Dell S2721HS is reproducible without my patch though, in which case it might be a separate regression (and wouldn't speak against merging my patch).


>>> 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.

Note that some kind of short-term solution is needed for the regression(s) in 7.1-rc.


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


[-- Attachment #2: asdn-freesync-mccs-caps-use-vsdb.patch --]
[-- Type: application/octet-stream, Size: 907 bytes --]

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 af0af7519517..ffc0273fcf61 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -13680,11 +13680,10 @@ void amdgpu_dm_update_freesync_caps(struct drm_connector *connector,
 
 	if ((sink->sink_signal == SIGNAL_TYPE_HDMI_TYPE_A ||
 		as_type == FREESYNC_TYPE_PCON_IN_WHITELIST) &&
-		(!sink->edid_caps.freesync_vcp_code ||
-		(sink->edid_caps.freesync_vcp_code && !sink->mccs_caps.freesync_supported)))
+		(!vsdb_info.freesync_supported))
 		freesync_capable = false;
 
-	if (do_mccs && sink->mccs_caps.freesync_supported && freesync_capable)
+	if (do_mccs && vsdb_info.freesync_supported && vsdb_info.freesync_mccs_vcp_code)
 		dm_helpers_mccs_vcp_set(adev->dm.dc->ctx, amdgpu_dm_connector->dc_link, sink);
 
 update:

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

[Michel Dänzer]

On 5/23/26 00:15, Pei-Hsin Yang wrote:
>> Note that some kind of short-term solution is needed for the regression(s) in 7.1-rc.
> 
> Here is my suggestion as a short-term workaround:  
> 	- Just refer to the vsdb_info data structure to set the value of freesync_capable.  freesync_mccs_vcp_code = 0 doesn't mean FreeSync is not supported.
> 	- Check both freesync_supported and freesync_mccs_vcp_code along with do_mccs to call dm_helpers_mccs_vcp_set().
> 	- Note that MCCS command over DDC might be failed at runtime, but at least, it will not inadvertently disable the VRR if (1) sink is FreeSync supported but vcp_code = 0, or (2) dm_helpers_read_mccs_cap() failed intermittently at runtime.
> 
> Patch created based on commit 53f0235c0284fc676d1510a460e1c6c111de3ea1 is attached as a reference for AMD team to review.
> 
> commit 53f0235c0284fc676d1510a460e1c6c111de3ea1 (HEAD -> amd-staging-drm-next, origin/amd-staging-drm-next, origin/HEAD)

In the future, please send patches inline, to make giving feedback easier.


> @@ -13680,11 +13680,10 @@ void amdgpu_dm_update_freesync_caps(struct drm_connector *connector,
> 
>         if ((sink->sink_signal == SIGNAL_TYPE_HDMI_TYPE_A ||
>                 as_type == FREESYNC_TYPE_PCON_IN_WHITELIST) &&
> -               (!sink->edid_caps.freesync_vcp_code ||
> -               (sink->edid_caps.freesync_vcp_code && !sink->mccs_caps.freesync_supported)))
> +               (!vsdb_info.freesync_supported))
>                 freesync_capable = false;

vsdb_info.freesync_supported already guards setting freesync_capable = true in the first place (given either of the other two conditions) above, so this if-statement looks superfluous now.


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

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

[Pei-Hsin Yang]

> In the future, please send patches inline, to make giving feedback easier.

Will do.  Thanks.

> vsdb_info.freesync_supported already guards setting freesync_capable = true in the first place (given either of the other two conditions) above, so this if-statement looks superfluous now.

Yes, if hardware detection via MCCS VCP Code read is not preferred, then this if-statement can be removed.

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

On 5/23/26 00:15, Pei-Hsin Yang wrote:
>> Note that some kind of short-term solution is needed for the regression(s) in 7.1-rc.
> 
> Here is my suggestion as a short-term workaround:  
> 	- Just refer to the vsdb_info data structure to set the value of freesync_capable.  freesync_mccs_vcp_code = 0 doesn't mean FreeSync is not supported.
> 	- Check both freesync_supported and freesync_mccs_vcp_code along with do_mccs to call dm_helpers_mccs_vcp_set().
> 	- Note that MCCS command over DDC might be failed at runtime, but at least, it will not inadvertently disable the VRR if (1) sink is FreeSync supported but vcp_code = 0, or (2) dm_helpers_read_mccs_cap() failed intermittently at runtime.
> 
> Patch created based on commit 53f0235c0284fc676d1510a460e1c6c111de3ea1 is attached as a reference for AMD team to review.
> 
> commit 53f0235c0284fc676d1510a460e1c6c111de3ea1 (HEAD -> amd-staging-drm-next, origin/amd-staging-drm-next, origin/HEAD)

In the future, please send patches inline, to make giving feedback easier.


> @@ -13680,11 +13680,10 @@ void amdgpu_dm_update_freesync_caps(struct drm_connector *connector,
> 
>         if ((sink->sink_signal == SIGNAL_TYPE_HDMI_TYPE_A ||
>                 as_type == FREESYNC_TYPE_PCON_IN_WHITELIST) &&
> -               (!sink->edid_caps.freesync_vcp_code ||
> -               (sink->edid_caps.freesync_vcp_code && !sink->mccs_caps.freesync_supported)))
> +               (!vsdb_info.freesync_supported))
>                 freesync_capable = false;

vsdb_info.freesync_supported already guards setting freesync_capable = true in the first place (given either of the other two conditions) above, so this if-statement looks superfluous now.


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

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

[Thorsten Leemhuis]

[+Alex +Christian]

On 5/21/26 09:09, Michel Dänzer wrote:
> On 5/20/26 17:54, Pei-Hsin Yang wrote:
>>
>>> 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.
> 
> That sounds similar to https://gitlab.freedesktop.org/drm/amd/-/work_items/5286 .
>
> I was wondering if the specific issue you described above with Dell S2721HS is reproducible without my patch though, in which case it might be a separate regression (and wouldn't speak against merging my patch).
> 
> 
>>>> 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.
> 
> Note that some kind of short-term solution is needed for the regression(s) in 7.1-rc.

Yeah, that would be good. Makes me wonder how the rough plan to realize
this looks like? Sounds like Michael's patch[1] that was discussed here
is not a good option? Reminder, Linus ideally wants known regression
fixed by -rc6, which is why I'm asking.

Ciao, Thorsten

[1]
https://lore.kernel.org/amd-gfx/20260518154809.660061-1-michel@daenzer.net/

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

[Deucher, Alexander]

Public

> -----Original Message-----
> From: Thorsten Leemhuis <regressions@leemhuis.info>
> Sent: Thursday, May 28, 2026 7:17 AM
> To: Michel Dänzer <michel.daenzer@mailbox.org>; Pei-Hsin Yang
> <peihsiny@valvesoftware.com>
> Cc: amd-gfx@lists.freedesktop.org; Linux kernel regressions list
> <regressions@lists.linux.dev>; Deucher, Alexander
> <Alexander.Deucher@amd.com>; Koenig, Christian
> <Christian.Koenig@amd.com>
> Subject: Re: [External Mail] Re: Test result / finding of "drm/amd/display:
> Consult MCCS FreeSync cap only if requested & supported"
>
> [+Alex +Christian]
>
> On 5/21/26 09:09, Michel Dänzer wrote:
> > On 5/20/26 17:54, Pei-Hsin Yang wrote:
> >>
> >>> 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.
> >
> > That sounds similar to https://gitlab.freedesktop.org/drm/amd/-
> /work_items/5286 .
> >
> > I was wondering if the specific issue you described above with Dell S2721HS
> is reproducible without my patch though, in which case it might be a separate
> regression (and wouldn't speak against merging my patch).
> >
> >
> >>>> 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.
> >
> > Note that some kind of short-term solution is needed for the regression(s) in
> 7.1-rc.
>
> Yeah, that would be good. Makes me wonder how the rough plan to realize
> this looks like? Sounds like Michael's patch[1] that was discussed here is not a
> good option? Reminder, Linus ideally wants known regression fixed by -rc6,
> which is why I'm asking.

@Wentland, Harry can you sort this out for next week's -fixes PR?

Alex

>
> Ciao, Thorsten
>
> [1]
> https://lore.kernel.org/amd-gfx/20260518154809.660061-1-
> michel@daenzer.net/

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

[Michel Dänzer]

On 5/29/26 00:02, Deucher, Alexander wrote:
>> From: Thorsten Leemhuis <regressions@leemhuis.info>
>> On 5/21/26 09:09, Michel Dänzer wrote:
>>>
>>> Note that some kind of short-term solution is needed for the regression(s) in
>> 7.1-rc.
>>
>> Yeah, that would be good. Makes me wonder how the rough plan to realize
>> this looks like? Sounds like Michael's patch[1] that was discussed here is not a
>> good option? Reminder, Linus ideally wants known regression fixed by -rc6,
>> which is why I'm asking.
> 
> @Wentland, Harry can you sort this out for next week's -fixes PR?

Looks like this regression will make it to 7.1 final?

I filed https://gitlab.freedesktop.org/drm/amd/-/work_items/5286 3 weeks ago, and proposed a fix the following week. There's been no reaction by any AMD display developer.

This is pretty sad.


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

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

[Alex Deucher]

On Thu, Jun 4, 2026 at 3:59 AM Michel Dänzer <michel.daenzer@mailbox.org> wrote:
>
> On 5/29/26 00:02, Deucher, Alexander wrote:
> >> From: Thorsten Leemhuis <regressions@leemhuis.info>
> >> On 5/21/26 09:09, Michel Dänzer wrote:
> >>>
> >>> Note that some kind of short-term solution is needed for the regression(s) in
> >> 7.1-rc.
> >>
> >> Yeah, that would be good. Makes me wonder how the rough plan to realize
> >> this looks like? Sounds like Michael's patch[1] that was discussed here is not a
> >> good option? Reminder, Linus ideally wants known regression fixed by -rc6,
> >> which is why I'm asking.
> >
> > @Wentland, Harry can you sort this out for next week's -fixes PR?
>
> Looks like this regression will make it to 7.1 final?
>
> I filed https://gitlab.freedesktop.org/drm/amd/-/work_items/5286 3 weeks ago, and proposed a fix the following week. There's been no reaction by any AMD display developer.
>
> This is pretty sad.

@Wentland, Harry , @Leo (Sunpeng) Li come on guys!  I've picked up
Michel's patch and I'll send an update -PR today.

Alex

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

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

[Michel Dänzer]

On 6/4/26 15:20, Alex Deucher wrote:
> On Thu, Jun 4, 2026 at 3:59 AM Michel Dänzer <michel.daenzer@mailbox.org> wrote:
>> On 5/29/26 00:02, Deucher, Alexander wrote:
>>>> From: Thorsten Leemhuis <regressions@leemhuis.info>
>>>> On 5/21/26 09:09, Michel Dänzer wrote:
>>>>>
>>>>> Note that some kind of short-term solution is needed for the regression(s) in
>>>> 7.1-rc.
>>>>
>>>> Yeah, that would be good. Makes me wonder how the rough plan to realize
>>>> this looks like? Sounds like Michael's patch[1] that was discussed here is not a
>>>> good option? Reminder, Linus ideally wants known regression fixed by -rc6,
>>>> which is why I'm asking.
>>>
>>> @Wentland, Harry can you sort this out for next week's -fixes PR?
>>
>> Looks like this regression will make it to 7.1 final?
>>
>> I filed https://gitlab.freedesktop.org/drm/amd/-/work_items/5286 3 weeks ago, and proposed a fix the following week. There's been no reaction by any AMD display developer.
>>
>> This is pretty sad.
> 
> @Wentland, Harry , @Leo (Sunpeng) Li come on guys!  I've picked up
> Michel's patch and I'll send an update -PR today.

Thanks Alex.


Note that Pei-Hsin reported an issue when running with my fix at the start of this thread, unfortunately it's still unclear if that's a regression of my fix or happens even without it (in which case it might be another regression of the MCCS related changes for 7.1).

An alternative would be reverting the 4 commits d49086491bcb..8dc88c6a5948.


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

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

[Pei-Hsin Yang]

Hi Michel,

> Note that Pei-Hsin reported an issue when running with my fix at the start of this thread, unfortunately it's still unclear if that's a regression of > my fix or happens even without it (in which case it might be another regression of the MCCS related changes for 7.1).

As I have mentioned earlier, my testing of your patch confirms that it is a regression even without your patch.

There are two reliability matters in most recent FreeSync / MCCS implementation need further clarification from the AMD team.  freesync_capable or MCCS support are inadvertently disabled on some occasions, for example, after HDMI cable hot plug.

1. AMD VSDB EDID parsing via internal dmub communication.
2. AMD MCCS VCP Code helpers.

NOTE: I found these issues after backporting from asdn 7.x to SteamOS 6.16/6.18.  It is verified on Steam Machine.

Thanks,
Pei-Hsin


-----Original Message-----
From: Michel Dänzer <michel.daenzer@mailbox.org> 
Sent: Thursday, June 4, 2026 6:58 AM
To: Alex Deucher <alexdeucher@gmail.com>
Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; Thorsten Leemhuis <regressions@leemhuis.info>; Pei-Hsin Yang <peihsiny@valvesoftware.com>; Wentland, Harry <Harry.Wentland@amd.com>; Li, Sun peng (Leo) <Sunpeng.Li@amd.com>; amd-gfx@lists.freedesktop.org; Linux kernel regressions list <regressions@lists.linux.dev>; Koenig, Christian <Christian.Koenig@amd.com>
Subject: [External Mail] Re: Test result / finding of "drm/amd/display: Consult MCCS FreeSync cap only if requested & supported"

On 6/4/26 15:20, Alex Deucher wrote:
> On Thu, Jun 4, 2026 at 3:59 AM Michel Dänzer <michel.daenzer@mailbox.org> wrote:
>> On 5/29/26 00:02, Deucher, Alexander wrote:
>>>> From: Thorsten Leemhuis <regressions@leemhuis.info> On 5/21/26 
>>>> 09:09, Michel Dänzer wrote:
>>>>>
>>>>> Note that some kind of short-term solution is needed for the 
>>>>> regression(s) in
>>>> 7.1-rc.
>>>>
>>>> Yeah, that would be good. Makes me wonder how the rough plan to 
>>>> realize this looks like? Sounds like Michael's patch[1] that was 
>>>> discussed here is not a good option? Reminder, Linus ideally wants 
>>>> known regression fixed by -rc6, which is why I'm asking.
>>>
>>> @Wentland, Harry can you sort this out for next week's -fixes PR?
>>
>> Looks like this regression will make it to 7.1 final?
>>
>> I filed https://gitlab.freedesktop.org/drm/amd/-/work_items/5286 3 weeks ago, and proposed a fix the following week. There's been no reaction by any AMD display developer.
>>
>> This is pretty sad.
> 
> @Wentland, Harry , @Leo (Sunpeng) Li come on guys!  I've picked up 
> Michel's patch and I'll send an update -PR today.

Thanks Alex.


Note that Pei-Hsin reported an issue when running with my fix at the start of this thread, unfortunately it's still unclear if that's a regression of my fix or happens even without it (in which case it might be another regression of the MCCS related changes for 7.1).

An alternative would be reverting the 4 commits d49086491bcb..8dc88c6a5948.


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

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

[Michel Dänzer]

On 6/4/26 19:21, Pei-Hsin Yang wrote:
> 
>> Note that Pei-Hsin reported an issue when running with my fix at the start of this thread, unfortunately it's still unclear if that's a regression of > my fix or happens even without it (in which case it might be another regression of the MCCS related changes for 7.1).
> 
> As I have mentioned earlier, my testing of your patch confirms that it is a regression even without your patch.

You previously wrote "There are other issues without your patch applied", I didn't see anything about whether or not the issue you reported in the post which started this thread happens without my fix though.

Anyway, thanks for confirming that it's not a regression of my fix, that's a relief.


Alex, since the MCCS changes caused other regressions, it might be better to revert them for now anyway though?


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

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

[Alex Deucher]

On Fri, Jun 5, 2026 at 3:42 AM Michel Dänzer <michel.daenzer@mailbox.org> wrote:
>
> On 6/4/26 19:21, Pei-Hsin Yang wrote:
> >
> >> Note that Pei-Hsin reported an issue when running with my fix at the start of this thread, unfortunately it's still unclear if that's a regression of > my fix or happens even without it (in which case it might be another regression of the MCCS related changes for 7.1).
> >
> > As I have mentioned earlier, my testing of your patch confirms that it is a regression even without your patch.
>
> You previously wrote "There are other issues without your patch applied", I didn't see anything about whether or not the issue you reported in the post which started this thread happens without my fix though.
>
> Anyway, thanks for confirming that it's not a regression of my fix, that's a relief.
>
>
> Alex, since the MCCS changes caused other regressions, it might be better to revert them for now anyway though?
>

I don't know if I'll have time to get the reverts in this week.  Your
patch is in at least.  Maybe Harry or Leo can take a look next week
when they are back in the office.

Alex