On Wed, Sep 24, 2025 at 4:00 PM Harry Wentland <harry.wentl...@amd.com> wrote: > > > > On 2025-09-24 15:11, Alex Deucher wrote: > > On Wed, Sep 24, 2025 at 2:44 PM Harry Wentland <harry.wentl...@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.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. > > > > 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.
Now that compositors generally control all of this, unless you are running X, there's probably not a good way to mess with this. Alex > > 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...@amd.com/ > >>> > >>> > >> >
