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 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.
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?
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?
I don't think it's a bug if a monitor doesn't advertise support for
certain modes. Honestly I think we've gotten quite lucky that eDP that
panels worked with non-native resolutions not in the EDID in the first
place.
Agreed.
