Re: [PATCH 0/5] Adjustments to common mode behavior

["Timur Kristóf" <timur.kristof@gmail.com>]

On 9/24/25 19:21, Mario Limonciello wrote:
> 
> On 9/24/25 12:13 PM, Timur Kristóf wrote:
>>
>>
>> On 9/24/25 18:16, Mario Limonciello wrote:
>>> As part of enablement for SI and CIK in DC Timur pointed out some
>>> differences in behavior for common mode handling for DC vs non DC
>>> code paths. This series lines up the behavior between the two
>>> implementations.
>>>
>> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
>>
>> Thank you Mario, this series makes good sense to me.
>> My only worry is this: is it possible that removing the common modes 
>> from connectors like DP, HDMI, etc. will regress somebody's setup?
> 
> Possibly.  We're not going to know until we try.  I generally prefer not 
> to add common modes (hence why I tried to drop them before until we hit 
> the Xorg bug report).
> 
> If someone complains about this then I see two other directions we can go.

Sounds good.

Considering the non-DC code already didn't add those common modes, I 
think it's reasonable to assume that we would have already heard about 
it if somebody had issues with it.

> 
> 1) to make both DC and non-DC paths apply common modes to eDP,LVDS, DP, 
> HDMI.  Make them not apply common modes to VGA and DVI
> 
> 2) Enabling common modes /across the board/ but anything not in the EDID 
> gets the GPU scalar turned on.

I guess we'll see if any of those are necessary. For now, I'd propose to 
just consider adding the common modes if there are 0 modes probed. But 
I'm also OK with leaving that for later if you feel it isn't necessary.

A slightly related question, would you be OK with changing the link 
detection code to return dc_connection_none when DDC cannot read an EDID 
header on digital signals, similar to how the non-DC code does it?

>>
>> Two possible cases come to mind:
>> 1. When we are unable to read the EDID for some reason
>> 2. When the EDID is buggy and/or doesn't contain any modes
>> Are these issues real or am I overthinking it?
>>
>> Thanks & best regards,
>> Timur
> 
> Failing to read EDID has happened in the past, but I think with the 
> deferred aux message handling that should be cleared up now.

I was actually curious about that. I saw that issue while I was working 
on something else. How is it deferred now? Can you point me to the 
series that fixed it?

> 
> I don't think it's a bug if a monitor doesn't advertise support for 
> certain modes.  Honestly I think we've gotten quite lucky that eDP that 
> panels worked with non-native resolutions not in the EDID in the first 
> place.

Agreed.