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

[Harry Wentland <harry.wentland@amd.com>]

On 2025-09-24 15:11, Alex Deucher wrote:
> On Wed, Sep 24, 2025 at 2:44 PM Harry Wentland <harry.wentland@amd.com> wrote:
>>
>>
>>
>> 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.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 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.
> 
> My thinking with the original logic in radeon and the amdgpu non-DC
> code was to only add the common modes to eDP/LVDS because the EDIDs
> for those panels usually only had one mode in them and users almost
> always wanted to do clone mode with an external monitor.  For external
> monitors they often supported multiple modes already so there was less
> incentive to add additional modes.  The default setting of the scaler
> property was also different on eDP/LVDS (on) and external displays
> (off).  If a user wanted to use the GPU scaler on an external display,
> they could enable the scaler property and then manually add whatever
> mode they wanted.  If they wanted to use the modes from the EDID, they
> would just disable the scaler property and pick the mode from the
> EDID.
> 

Makes sense. I forgot usermode controls scaling via the "scaling mode"
property.

Harry

> Alex
> 
>>
>> 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.wu@amd.com/
>>>
>>>
>>