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