https://bugs.freedesktop.org/show_bug.cgi?id=72051

--- Comment #1 from Eugene Shalygin eugene.shalygin+bugzilla.FDO@gmail.com --- Created attachment 89861 --> https://bugs.freedesktop.org/attachment.cgi?id=89861&action=edit xrandr -q --verbose with screen 2 connected

https://bugs.freedesktop.org/show_bug.cgi?id=72051

--- Comment #3 from Eugene Shalygin eugene.shalygin+bugzilla.FDO@gmail.com --- Created attachment 89863 --> https://bugs.freedesktop.org/attachment.cgi?id=89863&action=edit xorg log

https://bugs.freedesktop.org/show_bug.cgi?id=72051

--- Comment #5 from Alex Deucher agd5f@yahoo.com --- Can you bisect?

This sounds like it might be related to the hotplug breakage fixed by this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=76... but the problematic change wasn't introduced until 3.13.

https://bugs.freedesktop.org/show_bug.cgi?id=72051

--- Comment #7 from Eugene Shalygin eugene.shalygin+bugzilla.FDO@gmail.com --- To my knowledge I do not have radeon.hw_i2c set. Since the screen with the problem is on my work desk, bisecting will take time

https://bugs.freedesktop.org/show_bug.cgi?id=72051

--- Comment #9 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #8)

first bad commit: [d1e3b5564834ea24dee6b364a172365f64865fe5] drm/radeon: atombios hw i2c fixes

You must have radeon.hw_i2c=1 set somewhere then. Anyway, this is fixed in: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ff...

https://bugs.freedesktop.org/show_bug.cgi?id=72051

--- Comment #11 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #10)

Indeed, this option is set. Commit that was pointed out by you fixes the problem.

However, now when booting when the problematic screen is attached, I see a message that EDID is invalid:

[ 8.922653] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 255 [ 8.922666] Raw EDID: [ 8.922670] ff ff ff ff ff ff ff 00 22 64 e5 20 fb 01 00 00 [ 8.922676] 17 14 01 03 80 3b 25 78 ea af f6 a6 54 4c 9e 23 [ 8.922680] 10 4f 54 bf ef 80 d1 00 b3 00 a9 40 95 00 90 40 [ 8.922684] 81 80 81 40 71 4f 28 3c 80 a0 70 b0 23 40 30 20 [ 8.922688] 36 00 51 73 21 00 00 1a 00 00 00 ff 00 30 32 33 [ 8.922692] 4c 4b 33 51 41 30 30 35 30 37 00 00 00 fd 00 38 [ 8.922696] 4b 18 50 0f 00 0a 20 20 20 20 20 20 00 00 00 fc [ 8.922700] 00 48 48 32 38 31 0a 20 20 20 20 20 20 20 01 e2

repeated 4 times. This is probably is separate problem?

Does it work correctly without the hw_i2c option? If not, it's probably a buggy monitor or a hdmi receiver that doesn't patch the checksum correctly.

https://bugs.freedesktop.org/show_bug.cgi?id=72051

--- Comment #13 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #12)

Without the option, the message is not shown, but the HDMI screen is unusable: every second or third frame is shown shifted by approx. 50 pixels downward. When the screen is connected before boot, it is recognized always, but it does not work every time when hot-plugged. So, in my case radeon.hw_i2c=1 seems to be required option.

It's failing to read the edid when hw_i2c=1 so you end up with a fallback mode. Sounds like the monitor doesn't like the hdmi packets the driver is sending. Does booting with radeon.audio=0 help?

https://bugs.freedesktop.org/show_bug.cgi?id=72051

Martin Peres martin.peres@free.fr changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |MOVED

--- Comment #15 from Martin Peres martin.peres@free.fr --- -- 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/drm/amd/issues/412.