On 2025-09-24 13:48, Mario Limonciello wrote:
> On 9/24/25 12:33 PM, Timur Kristóf wrote:
>>
>>
>> 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.kris...@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 was surprised the previous approach failed, which seems
to indicate GPU scaling isn't already happening. I wonder
why. I think this would make a better default behavior
instead of relying on monitor scalers to deal with
non-advertised modes.
Harry
>>
>> 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.
>>
>
> Yeah if something comes up and we need to weight it out we have this thread
> to refer back to for our ideas on what to do.
>
>> 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?
>>
>
> I personally think lining up all these nuances that are different between the
> two is a good idea.e e
>
> But for that specific question that's probably more of a Harry/Alex Hung
> question.
>
>>>>
>>>> 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?
>>
>
> There's more patches than this one, but I believe this was the 💰 patch.
>
> https://lore.kernel.org/amd-gfx/20250428135514.20775-27-ray...@amd.com/
>
>
