Created attachment 89860 [details] xrandr -q --verbose with screen 1 connected I have two external screens, say screen 1 and 2. Screen 1 have HDMI input and screens 2 is connected via HDMI-to-DVI adapter. With kernel 3.12 screen 1 is not recognized on connect anymore. Booting kernel 3.11.9 makes it work again. When I connect screen 1 nothing appears not in Xorg.0.log nor in dmesg
Created attachment 89861 [details] xrandr -q --verbose with screen 2 connected
Created attachment 89862 [details] dmesg
Created attachment 89863 [details] xorg log
"xrandr -q --verbose with screen 1 connected" was obtained under kernel 3.11.9
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=760c960bd6880cf22a57c0af9ff60c96250aad39 but the problematic change wasn't introduced until 3.13.
Actually do you have radeon.hw_i2c=1 set somewhere? If so, it should be fixed with this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fae009d15a44e5f1d938340facf4b8bc7dc69a09
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
first bad commit: [d1e3b5564834ea24dee6b364a172365f64865fe5] drm/radeon: atombios hw i2c fixes
(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=ffd3d3361d583cb73fa65a5fed3a196ba6f261bb
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?
(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.
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.
(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?
With radeon.audio=0 the amplitude of these "jumps" is lower, somewhat about 2--5 pixels
-- 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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.