Bug 27470

Summary: Dual link DVI mode (2560x1920) on Dell 30" display unusable (distorted screen) on RV770 [Radeon HD 4850]
Product: xorg Reporter: nine
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED INVALID QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: medium    
Version: 7.5 (2009.10)   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log
none
expected background image and cursor
none
picture of the distortions on the screen
none
dmesg output of boot
none
dmesg on 2.6.37-rc8 with new display
none
Xorg.0.log
none
vbios.rom
none
new pll algo
none
patched files
none
dmesg output of a drm-fixes kernel with the following (useless) patch, showing failure to detect DP output
none
vbios of the 5670 none

Description nine 2010-04-05 09:23:45 UTC
Created attachment 34677 [details] [review]
Xorg.0.log

Trying to use a Dell 3007 WFPHC display in it's native mode (2560x1920) leads to a distorted screen. It's showing about the colors that should be on the screen but distorted and flickering so nothing is recognizable and the system unusable. Lower resolutions do work fine, so I think the problem is in the dual link DVI support. The screen gets distorted as soon as KMS is switching to the native resolution.

I'm running Linux with:
openSUSE kernel 2.6.34-rc3-7-desktop,
xorg-x11-server-7.5_1.8.0-19.3.x86_64,
xorg-x11-driver-video-7.5.99_20100401-1.2.x86_64,
libdrm-2.4.99_20100402-1.1.x86_64,
Mesa-7.8.99_20100403-1.1.x86_64
Comment 1 nine 2010-04-05 09:24:56 UTC
Created attachment 34678 [details]
expected background image and cursor
Comment 2 nine 2010-04-05 09:25:47 UTC
Created attachment 34679 [details]
picture of the distortions on the screen
Comment 3 nine 2010-04-05 09:43:07 UTC
Created attachment 34680 [details]
dmesg output of boot
Comment 4 Alex Deucher 2010-04-05 09:54:10 UTC
Does radeon.new_pll=0 help?
Comment 5 nine 2010-04-05 10:02:18 UTC
(In reply to comment #4)
> Does radeon.new_pll=0 help?

Negative. No change.
Comment 6 Alex Deucher 2010-10-19 19:31:37 UTC
Is this still an issue with a newer version of the kernel or driver?
If so, does:
xrandr --output DVI-0 --set coherent 0
help?
Comment 7 nine 2011-01-06 08:55:17 UTC
(In reply to comment #6)
> Is this still an issue with a newer version of the kernel or driver?
> If so, does:
> xrandr --output DVI-0 --set coherent 0
> help?

Problem still exists with 2.6.37-rc7. In the meantime I got a new display. It's a Dell 3008 WFP with same resolution as the other one. This time I do get an image, but horizontal resolution is exactly half of what it should be. So instead of 2560x1600 I get 1280x1600 scaled up by the display. Resolutions up to 1920x1200 work fine. xrandr --output DVI-0 --set coherent 0 did not change anything.

Please tell me what I can do to solve this or help solving this. This time I actually own the display and I would very much like to use it's full potential with free radeon drivers. I have no problem running bleeding edge stuff and am a programmer myself, so any hint where to get started would be very appreciated.
Comment 8 Alex Deucher 2011-01-06 09:38:16 UTC
I have a Dell 3008 WFP as well and it works on all cards I have access to including an rv770. Perhaps there is a problem with one of your DVI ports?  Does the other DVI port work any better?  Please attach your xorg log and dmesg output with the latest kernel and also a copy of your vbios.  To get a copy of your bios:
(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom
Comment 9 nine 2011-01-06 10:51:44 UTC
Problem persists with the second DVI port and with a different dual link DVI cable.
Now running 2.6.37-rc8.
Comment 10 nine 2011-01-06 10:52:59 UTC
Created attachment 41717 [details]
dmesg on 2.6.37-rc8 with new display
Comment 11 nine 2011-01-06 10:54:30 UTC
Created attachment 41718 [details]
Xorg.0.log
Comment 12 nine 2011-01-06 10:55:08 UTC
Created attachment 41719 [details]
vbios.rom
Comment 13 nine 2011-01-12 22:43:47 UTC
Just a heads up: problem's still there on 2.6.37 final. 

And for completeness, lspci output for my graphics card:

05:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4850] (prog-if 00 [VGA controller])
        Subsystem: Giga-byte Technology Device 21c7
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 40
        Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Region 2: Memory at fd8e0000 (64-bit, non-prefetchable) [size=64K]
        Region 4: I/O ports at 6c00 [size=256]
        [virtual] Expansion ROM at fd800000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: radeon
Comment 14 Alex Deucher 2011-01-12 23:19:49 UTC
Created attachment 41950 [details] [review]
new pll algo

Does this patch help?
Comment 15 nine 2011-01-13 01:45:30 UTC
Created attachment 41952 [details]
patched files

Negative. Patch applies to 2.6.37, but the problem still persists:

patching file drivers/gpu/drm/radeon/atombios_crtc.c
Hunk #1 succeeded at 915 (offset -48 lines).
patching file drivers/gpu/drm/radeon/radeon_display.c
Hunk #1 succeeded at 448 (offset -332 lines).
Hunk #2 succeeded at 560 (offset -332 lines).
Hunk #3 succeeded at 619 (offset -332 lines).
Hunk #4 succeeded at 735 (offset -332 lines).
patching file drivers/gpu/drm/radeon/radeon_legacy_crtc.c
patching file drivers/gpu/drm/radeon/radeon_mode.h

Attaching patched files in case you want to check the rather large offsets.
Comment 16 nine 2011-01-30 03:17:32 UTC
Retested on 2.6.38-rc2. The patch now applies cleanly but still does not help. I also tried the radeonhd and fglrx drivers. All show the same problem. With radeonhd, the highest working resolution is even lower at 1600x1200.

I start suspecting a hardware problem here, since all drivers show such consistent failures.
Comment 17 nine 2011-02-05 03:46:41 UTC
I bit the bullet and tested on Windows 7 -> same problem there. So I bought a Sapphire Radeon HD5670 and had the tech support confirm that this card does support 2560x1600. But still, using DVI, I get exactly the same problems. Frustration reached a new peak.

But the upside is: this card supports displayport and with UMS I am finally able to use full resolution of my display! But KMS does not find the displayport output and the screen stays blank. And without KMS I get no acceleration at all and no power management.
Comment 18 nine 2011-02-05 03:52:27 UTC
Created attachment 42960 [details]
dmesg output of a drm-fixes kernel with the following (useless) patch, showing failure to detect DP output

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c
index 695de9a..a8c23c6 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -356,7 +356,8 @@ retry:
        atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t *)&args);
 
        if (args.v1.ucReplyStatus && !args.v1.ucDataOutLen) {
-               if (args.v1.ucReplyStatus == 0x20 && retry_count++ < 10)
+              if (args.v1.ucReplyStatus != 3 && retry_count++ < 2000)
Comment 19 Alex Deucher 2011-02-05 10:19:10 UTC
Can you attach a copy of your vbios from the new card?

(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom
Comment 20 nine 2011-02-06 09:07:57 UTC
Created attachment 42993 [details]
vbios of the 5670
Comment 21 Adam Jackson 2018-06-12 19:10:27 UTC
Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.

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.