Created attachment 34665 [details] dmesg from 2.6.32.9 stable with drm-radeon-testing merged BACKGROUND I ordered a Radeon HD 5750 at the beginning of February, when the first Evergreen support was announced for xf86-video-ati. I first tried it out on Feb. 15. See this post: http://lists.x.org/archives/xorg-driver-ati/2010-February/013857.html I was using the "drm-radeon-testing" branch of kernel 2.6.32, as well as 2.6.33-rc8 with "drm-radeon-testing" merged, and experienced some black screen issues. See: http://lists.x.org/archives/xorg-driver-ati/2010-February/013859.html I was able to verify that my video card, cables, power supply, etc., were not at fault by multibooting with Windows Vista and installing the ATI Catalyst drivers. The system worked fine -- spent 6 hours giving it a thorough workout with a 3D FPS game! A week later, I discovered that my usage of a KVM device (keyboard/video/mouse, not kernel virtualization) was causing the black screen issue. Using a DVI cable direct to the monitor resolved the problems. (This was disappointing, since my HD 4850 works fine with the same KVM device, even using a DVI-to-VGA cable before connecting to the KVM.) See: http://lists.x.org/archives/xorg-driver-ati/2010-February/013942.html CURRENT PROBLEM A few days later, I upgraded my monitor. This monitor only has VGA/Dsub and HDMI inputs, but provided no HDMI cable. Instead, a DVI-to-HDMI converter cable was packaged with the monitor, so I used that. I found that booting into KMS with no X server gave me a radeondrmfb virtual terminal with a pink vertical line, 2 pixels wide, from top to bottom on the left side of the screen. See: http://lists.x.org/archives/xorg-driver-ati/2010-February/014044.html Disabling KMS worked correctly, but switching from X to virtual terminals was not supported without KMS. Since KMS is the future, I felt this cure to be worse than the disease. See: http://lists.x.org/archives/xorg-driver-ati/2010-February/014061.html Replacing the HD 5750 with the HD 4850, but still using the DVI-to-HDMI cable, worked: http://lists.x.org/archives/xorg-driver-ati/2010-February/014062.html I thought it may be an artifact of the DVI-to-HDMI converter cable, so I ordered a HDMI cable. That arrived on March 1, but made no difference regarding the vertical pink line: http://lists.x.org/archives/xorg-driver-ati/2010-March/014083.html The monitor itself actually gets set to a strange 1922x1200 mode, when it is only physically cable of 1920x1200 resolution. I would have thought it would simply refuse to display an image, but instead it actually gives me a near-perfect display... just with the thin vertical bar on the left edge. As mentioned in the above email message, a lurker on the xorg-driver-ati list emailed me (privately, for some reason) that he had an identical vertical bar on his HD 5870 card. (Mine is HD 5750.) At that time (beginning of March), I didn't know where else I could report Evergreen issues than the xorg-driver-ati list. It looked like Alex Deucher was the one who had written the Evergreen support code; the DRM/DRI mailing list looked pretty dead; and no one recommended that I should file a bug on the fdo bugzilla. I didn't think there were product/component settings appropriate for Evergreen support yet. Since then, I have been tracking changes (via git) to the Linux kernel and xf86-video-ati, looking for anything related to my HD 4850 and HD 5750 cards. Recently, there have been some commits in the kernel that touch (slightly) on Evergreen support, so I built a 2.6.34-rc3 kernel including the drm-linus changes up to commit 42be79e on Apr 1, 2010. I tested the HD 5750 with that kernel yesterday, but I found that I still get the pink vertical line. I have partial dmesg output from stable kernel 2.6.32.9 with drm-radeon-testing merged (save on Feb. 23), and the corresponding dmesg output from yesterday is identical. After yesterday's testing, I decided to look more carefully at the fdo bugzilla to see whether an appropriate combination of product and component for Evergreen issues could be found; I'm filing this bug to see how much trouble I can get myself into! ;) Presently, I have replaced the HD 5750 with the HD 4850: I don't like running my monitor with its onscreen display reporting 1922 horizontal resolution. It's a brand new monitor, and works beautifully. I will leave the HD 5750 installed permanently once this mode setting issue is addressed.
Seeing the recent set of commits touch on Evergreen support, I tested a new kernel using "drm-radeon-testing" up to commit 98e5963 of Apr. 9, 2010. I'm not interested in UMS, so I configured to default to KMS. My monitor only has VGA and HDMI inputs, and I'm only interested in seeing the problem with HDMI support for Evergreen solved in this bug report, so I only tested with the HDMI cable. Results: - still have pink line along left side of screen (2 pixels wide) - monitor OSD still reports crazy 1922x1200 mode (instead of 1920x1200) - it is known that the hardware (both video card and monitor) are fine: Windows uses HDMI-to-HDMI cable (and DVI-to-HDMI cable) without problems - as before, X runs fine; I will include Xorg.0.log for completion (problem is in KMS/radeondrmfb, not X, though) in case any helpful info is present there Brainstorming: - looked at some of the DRM code, but couldn't understand HDMI connection code; apparently something in the ATOMBIOS functionality between HD 4XXX and HD 5XXX is subtly different - possibly the problem arises with the KMS equivalent of what would be called modelines in X: the Xorg.0.log shows that the preferred mode for the monitor (1920x1200) is set using detailed timings reported by the monitor; this is fine with UMS (and KMS on HD 4850), but fails with KMS on HD 5750 ... (II) RADEON(0): Supported detailed timing: (II) RADEON(0): clock: 154.0 MHz Image Size: 593 x 371 mm (II) RADEON(0): h_active: 1920 h_sync: 1968 h_sync_end 2000 h_blank_end 2080 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1203 v_sync_end 1209 v_blanking: 1235 v_border: 0 [FYI: the "drm-radeon-testing" commits now require JUNIPER*.bin firmware blobs, but I did download them and add them to my kernel with a built-in initramfs -- see attached 'dmesg' output.]
Created attachment 34874 [details] dmesg from drm-radeon-testing kernel 2.6.34-rc3 (Apr. 9, 2010)
Created attachment 34875 [details] Xorg.0.log from drm-radeon-testing kernel 2.6.34-rc3 (Apr. 9, 2010)
Created attachment 34876 [details] Output from 'hwinfo' and 'fbset' Out of curiosity, I thought I would run 'hwinfo' and 'fbset' to see what they reported about radeondrmfb. This output is probably useless, but I'm attaching it just in case.... Running 'hwinfo --framebuffer' does not even report 1920x1200 as a possible mode, and 'hwinfo --monitor' reports nothing at all.
I have that same problem. Radeon 5750 connected to a projector via HDMI, resolution is set to 1920x1080, projector reports 1922x1080, pink line on the left from top to bottom running debian sid with xserver-xorg-video-radeon 1:6.13.0-1 and a custom compiled (vanilla) linux 2.6.34-rc3 kernel
Created attachment 35137 [details] dmesg from 2.6.34-rc4 (+ recent drm-radeon-testing) with drm.debug=7 Built a new kernel with 2.6.34-rc4 on the night it was released. Also saw some new commits in drm-radeon-testing, so merged them with it (up to commit 3a44d81 of Apr. 10). Had my HD 4850 installed then and since, but today finally found time to swap in the HD 5750 and try it out. Also (accidentally) discovered the "drm.debug" kernel parameter, so I tested the new kernel by booting to a non-X runlevel with drm.debug=7 enabled. Results from 'dmesg' attached. Still get the pink vertical line on the left side of screen; monitor's OSD still reports crazy 1922x1200 resolution instead of 1920x1200.
Created attachment 35158 [details] /sys/class/drm/card0-HDMI Type A-1/edid
added some debug statements to atombios_crtc_mode_set to print out the contents of the mode and adjusted_mode structures (which were identical): crtc_hsync_start: 2008 crtc_hsync_end: 2052 crtc_hdisplay: 1920 crtc_hblank_end: 2200 crtc_vsync_start: 1084 crtc_vsync_end: 1089 crtc_vdisplay: 1080 crtc_vblank_end: 1125 flags: 5
bug still there with 2.6.34-rc5 + drm-radeon-testing 10fd883ce384706f88554a0b08cc4d63345e7d8b
Created attachment 37676 [details] dmesg from 2.6.35 with drm.debug=15 I have still been testing kernels to see if this bug goes away, but there has been no change since last time I posted to this bug. Today, I tested the HD 5750 card with 2 kernels: - A much older kernel, which I had forgotten to test with the 5750: linux 2.6.34 + drm-radeon-testing (up to commit 0818fe9 of 04/29/2010) - linux 2.6.35 (built on 08/01/2010) Both kernels still result in a pinkish/purplish vertical line along the entire left side of the screen when using the HDMI cable. Using a HD 4850 card with both kernels (and HDMI) works fine. Looking carefully, I am noticing that (with the 5750) there is also a black gap at the top and on the left -- maybe 2 or 3 mm wide. The bug also has always caused the monitor's onscreen display to report 1922x1200 resolution (the 1922 should be 1920, of course); this doesn't happen with the 4850 card. I believe also that the pink vertical line (a few pixels wide) may be before the addressable pixels of the screen. That is, I'm not sure that I'm losing actual screen space to the pink line, but that the image that ought to be displayed is actually just shifted to the right (and down) from where it ought to be. Seems like the sort of timing problem one might have seen in the old days on a CRT. Attached is dmesg from 2.6.35 with "drm.debug=15" boot parameter.
(In reply to comment #10) [...] > Looking carefully, I am noticing that (with the 5750) there is also a black gap > at the top and on the left -- maybe 2 or 3 mm wide. Umm, strike this, please. Because of the pink line issue, I don't leave the 5750 installed -- I remove it after testing and use the 4850 instead. I see that the gaps (which I hadn't noticed before) are actually normal. The X server, for some reason, detects DPI differently when I swap cards, so what looked to me like screen real estate being cut off at the bottom of the screen was probably an artifact of the fonts being a different size when the 5750 was installed.
Fixed with this patch: http://lists.freedesktop.org/archives/dri-devel/2010-August/003142.html
(In reply to comment #12) > Fixed with this patch: > http://lists.freedesktop.org/archives/dri-devel/2010-August/003142.html Applied patch. Installed HD 5750 card. Verified that pink vertical line is gone. Thanks Alex!
(In reply to comment #12) > Fixed with this patch: > http://lists.freedesktop.org/archives/dri-devel/2010-August/003142.html Any news on the real cause of the problem? Completely unrelated but we have an HDMI driver for another platform here (ARM-based with an SII9022 HDMI transmitter) and when operating in HDMI mode to get audio (before we've even configured audio...) we're getting this very same pink line down the side of the screen. We've got no idea where it came from or what might cause it.. some quirk in CEA mode timings? HDMI being less tolerant of a slightly askew pixel clock? Who knows, but I would love to see someone tell me what causes this stuff. It's obviously the horizontal back porch showing through but we're pulling EDID data from the monitor and converting it directly (and very accurately) to framebuffer timings..
(In reply to comment #14) > (In reply to comment #12) > > Fixed with this patch: > > http://lists.freedesktop.org/archives/dri-devel/2010-August/003142.html > > Any news on the real cause of the problem? When running in HDMI mode, the monitor expects properly formatted CEA infoframe packets (for audio, 3D, colorspace, etc.) from the source, however, at the moment, we don't yet have support for them in the open source driver for evergreen hw. The monitor can misinterpret the bogus/missing infoframe packets and do strange things.
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.