On 2025-09-24 15:11, Alex Deucher wrote:
> On Wed, Sep 24, 2025 at 2:44鈥疨M Harry Wentland <[email protected]> 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 <[email protected]>
>>>>>>
>>>>>> 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/[email protected]/
>>>
>>>
>>
