|Summary:||regression: vertical pink line on HDMI port with KMS / wrong resolution|
|Product:||[Fedora] Fedora||Reporter:||ivan <ivan.mitev>|
|Component:||xorg-x11-drv-ati||Assignee:||Hans de Goede <hdegoede>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||22||CC:||hdegoede, krofnica996, xgl-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-08-19 13:54:52 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description ivan 2015-06-27 20:26:04 UTC
Description of problem: After updating/booting to kernel-4.0.5-300.fc22.x86_64 I now see a vertical pink line on the left side on a projector plugged in the HDMI port of an AMD APU based HTPC. It happens as soon as Xorg starts (but note that there's no pink line in the console after modesetting prior to Xorg start). Reverting to kernel-4.0.4-303.fc22.x86_64 "fixes" the problem. Setting radeon.nomodeset=1 too, but that's not an acceptable workaround. Version-Release number of selected component (if applicable): xorg-x11-drv-ati-7.5.0-3.fc22.x86_64 Additional info: cpu: Vendor ID: AuthenticAMD CPU family: 21 Model: 16 Model name: AMD A8-5500 APU with Radeon(tm) HD Graphics Stepping: 1 the projector (epson EH-TW4500) shows that the resolution is 1922x1080, so it's off by 2 pixels. However there's nothing in dmesg, Xorg.0.log, decoded EDID or /sys/class/drm/* that show anything different than 1920x1080. There are similar bug reports (eg. bug 597366) or https://email@example.com/msg12869.html, but things used to work perfectly before the kernel update so they don't seem relevant.
Comment 1 ivan 2015-06-29 18:52:21 UTC
BTW, same problem with today's kernel update - kernel-4.0.6-300.fc22.x86_64.
Comment 2 ivan 2015-07-21 08:49:30 UTC
same problem with 4.0.8-300.fc22.x86_64 :( I'd be happy to help with debugging - only that I have no clue where to begin from.
Comment 3 Hans de Goede 2015-07-21 19:40:21 UTC
Hi, The problem seems to be that the radeon kernel driver thinks that your beamer is hdmi-audio capable, while it is not, and then the beamer sees the audio data in the hdmi frames as video data. Can you try adding: "radeon.audio=0" to your kernel cmdline and see if that helps? That should work around this, once that is confirmed we can see if we can make the auto-detect code work with your beamer. Regards, Hans
Comment 4 ivan 2015-07-21 21:02:45 UTC
Hi, You were right, radeon.audio=0 fixed it. Cool.. Let me know when you want me to do additional tests/debug with the auto-detection code. (Or feel free to close the bug). Thanks ! ivan
Comment 5 Hans de Goede 2015-07-23 08:51:42 UTC
Hi, (In reply to ivan from comment #4) > Hi, > > You were right, radeon.audio=0 fixed it. Cool.. Good. > Let me know when you want me to do additional tests/debug with the > auto-detection code. (Or feel free to close the bug). Can you please do: cd /sys/class/drm ls You should then see something like this: card0 card0-DP-2 card0-HDMI-A-2 controlD64 version card0-DP-1 card0-HDMI-A-1 card0-VGA-1 renderD128 Then for each of the cord0-$connector dirs do: cat card0-$connector/modes Until you've found the connector which corresponds to your projector. Then do: cat card0-$connector/edid > ~/projector-edid.bin And then attach projector-edid.bin here. Then I'll see if I can figure out what is going wrong in the auto-detect code for the audio setting. Regards, Hans
Comment 6 ivan 2015-07-23 12:01:53 UTC
Hi, I forgot to mention that the projector is not always plugged: the PC is more a server that is used as HTPC from times to times than a real HTPC; it has a DVI monitor always plugged. The PC's HDMI output goes into an AV amplifier and the projector is then plugged in the amplifier. The amplifier is not a "smart" one, ie. it only acts as an HDMI switch with no decoding/encoding capabilities, so it shouldn't mangle the EDID (I don't have longer cables so I couldn't try to physically plug the beamer directly into the PC's HDMI port to verify that this assumption is right though). The projector was on card0-HDMI-A-1. By the way the output of card0-HDMI-A-1/modes didn't list 1920x1080 while the projector supports it (see output below). edid-decode properly lists it though. Thanks for the help ! Ivan $ for i in card0*; do echo $i; cat $i/modes; echo; done card0-DVI-D-1 1280x1024 1280x1024 1280x960 1152x864 1024x768 1024x768 1024x768 832x624 800x600 800x600 800x600 800x600 640x480 640x480 640x480 640x480 720x400 card0-HDMI-A-1 1280x720 1280x720 1280x720 720x576 720x576i 720x480 720x480 720x480i 720x480i 640x480 640x480 card0-VGA-1
Comment 8 Mislav 2015-07-24 09:32:10 UTC
I am also affected by this bug, but the pink line is on monitor.
Comment 9 Hans de Goede 2015-07-24 13:29:26 UTC
Hi, I've just started a scratch build of the fedora 4.1.3 kernel with a patch from upstream which should fix this: http://koji.fedoraproject.org/koji/taskinfo?taskID=10462458 Please download the following rpms: kernel-4.1.3-...rpm kernel-core-4.1.3-...rpm kernel-modules-4.1.3-...rpm For your arch from there (note this is still building atm). Save them all to the same directory (which should not contain other rpms) and do: sudo rpm -ivh kernel-*.rpm From within that directory. Then boot into the new kernel (without any special kernel commandline options) and check if this fixes things. Thanks & Regards, Hans
Comment 10 Hans de Goede 2015-07-24 13:31:28 UTC
Created attachment 1055738 [details] [PATCH] drm/radeon: rework audio detect (v4) Patch from: https://bugzilla.kernel.org/show_bug.cgi?id=93701 backported to 4.1 kernel.
Comment 11 ivan 2015-07-24 16:14:55 UTC
Hi, The test kernel fixes the problem - no more pink/purple vertical lines. Thanks! Ivan
Comment 12 Hans de Goede 2015-07-24 16:18:56 UTC
Hi, (In reply to ivan from comment #11) > Hi, > > The test kernel fixes the problem - no more pink/purple vertical lines. > > Thanks! > Ivan That is good to hear, I'm going to wait for upstream to declare the fix stable before adding it to any officia Fedora kernels though, so for now please keep using the radeon.audio=0 workaround. Regards, Hans
Comment 13 Hans de Goede 2015-08-19 13:54:52 UTC
The fix for this is in 4.1.6, which is in updates testing now, closing.