Bug 72167

Created attachment 90014 [details]
grep drm: /var/log/kern.log

Created attachment 90015 [details]
xrandr -q

Edit: Since January: https://bugs.freedesktop.org/show_bug.cgi?id=59703#c12

(In reply to comment #0)
> Created attachment 90013 [details]
> Xorg.0.log
> 
> The mode on my (cheap Korean) 1440p monitors on DP outputs (via DP->DVI
> converters) is detected incorrectly.

Do they work properly if you connect via DP directly?  From the log it looks like the driver is still driving them as DP rather than DVI.

This bug has nothing to do with bug 59703.

(In reply to comment #4)
> Do they work properly if you connect via DP directly?  From the log it looks
> like the driver is still driving them as DP rather than DVI.

They are DVI only so I can't connect them to the DP outputs directly, but they work correctly when I plug them into the DVI output.

(In reply to comment #5)
> This bug has nothing to do with bug 59703.

Yes, this was only for some older logs.

(In reply to comment #6)
> (In reply to comment #4)
> > Do they work properly if you connect via DP directly?  From the log it looks
> > like the driver is still driving them as DP rather than DVI.
> 
> They are DVI only so I can't connect them to the DP outputs directly, but
> they work correctly when I plug them into the DVI output.

What's strange is that the monitor seems to present itself as DP, even over DVI.  The driver is able to get DPCD from the monitor and is able to communitcate with it over aux.  The only thing that doesn't seem to be wired up is the EDID.You might check and see if they have any configuration options in the menus.  For DP ports, the driver attempts to talk DP to the monitor and if that fails, it tries DVI/HDMI.  Unfortunately, your monitor responds via DP so the driver never tries DVI.  It seems like a hw issue with the monitors.

Actually, I guess you are using active DP adapters.  So the driver is treating them as DP as it should.  However, they don't seem to be passing through the EDID properly.  Can you try another adapter?

(In reply to comment #9)
> Actually, I guess you are using active DP adapters.  So the driver is
> treating them as DP as it should.  However, they don't seem to be passing
> through the EDID properly.  Can you try another adapter?

I don't have any other adapters.
What I don't get is: The BIOS displays correctly on the DP outputs, which implies that the card knows the correct EDID data, right?

(In reply to comment #10)
> I don't have any other adapters.
> What I don't get is: The BIOS displays correctly on the DP outputs, which
> implies that the card knows the correct EDID data, right?

If the bios is able to bring up the monitors it should work.  The monitor is deferring the transaction.  You might try increasing the number of retries.  E.g., something like:

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c
index fb3ae07..5bc5edc 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -272,7 +272,7 @@ int radeon_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
                break;
        }
 
-       for (retry = 0; retry < 4; retry++) {
+       for (retry = 0; retry < 16; retry++) {
                ret = radeon_process_aux_ch(auxch,
                                            msg, msg_bytes, reply, reply_bytes, 0, &ack);
                if (ret == -EBUSY)

(In reply to comment #11)
Some improvement... the monitors sync now but I still have to tell X to use 2560x1440: Without the Modeline in xorg.conf the default resolution displayed by xrandr -q is still 1024x768.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/84.