Bug 21050

Summary:

Radeon driver displays nothing on DVI-0, but works fine on DVI-1

Product:

xorg

Reporter:

Phil Armstrong <phil>

Component:

Driver/Radeon

Assignee:

xf86-video-ati maintainers <xorg-driver-ati>

Status:

RESOLVED FIXED

QA Contact:

Xorg Project Team <xorg-team>

Severity:

normal

Priority:

medium

CC:

jon.a

Version:

git

Hardware:

x86 (IA32)

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Non working Xorg log	none
Working Xorg log	none
Xorg output	none
Working Xorg output	none
Xorg.conf	none
disable coherent mode by default	none

Description Phil Armstrong 2009-04-04 07:15:45 UTC

Created attachment 24541 [details] [review]
Non working Xorg log

I have a Radeon HD4670, which works perfectly (so far) with the git radeon driver & r6xx-r7xx-support drm branch. The only wart is that the output only works on the second DVI output of the card. If I plug the monitor into the first port, then it works fine until I start X at which point the monitor goes to sleep. If I switch back to a text VT then the monitor wakes up again and when I switch back to the X VT, it goes back to sleep.

The monitor is an 1920x1200 HP LP2475W, so I believe it requires the low-blanking DVI modes to be used in order to have a signal that will fit within the single-channel DVI timings.

I've attached my Xorg.conf, together with the logs from two runs one with the monitor in the working port (DVI-1) and one in DVI-0. Both runs were from a cold boot.

A second wrinkle is that if I plug in my old 1280x1024 monitor, then the new 1920x1200 doesn't work at all, regardless of which ports the two monitors occupy. Should I submit this as a second bug, or get some more logs and attach them to this one?

The HP monitor works fine in windows from either port, but with both monitors plugged in I have to manually tick the "use alternate timings" tickbox in the ATI Catalyst GUI for them both to work at their native resolution.

Comment 1 Phil Armstrong 2009-04-04 07:16:10 UTC

Created attachment 24542 [details] [review]
Working Xorg log

Comment 2 Phil Armstrong 2009-04-04 07:16:48 UTC

Created attachment 24543 [details] [review]
Xorg output

Comment 3 Phil Armstrong 2009-04-04 07:17:12 UTC

Created attachment 24544 [details] [review]
Working Xorg output

Comment 4 Phil Armstrong 2009-04-04 07:17:31 UTC

Created attachment 24545 [details] [review]
Xorg.conf

Comment 5 Phil Armstrong 2009-04-04 07:25:10 UTC

For reference, I'm using drm git 9858540fab30f9219b6f689c9668ebb3fa203d23 and xf86-driver-ati 215e12f9c0e8ac62c23af1add776ef88f9a0dc54

but this problem has existed ever since I set up the new card back at the beginning of January, and I had some related problems with my old r300 card as well, but had got rid of the card before I could do any in depth debugging: with that card I ended up having to manually force a reduced-blanking mode on the DVI port. That was bug http://bugs.freedesktop.org/show_bug.cgi?id=19348

The card is a Powercolor HD4670.

Comment 6 Alex Deucher 2009-04-04 15:46:20 UTC

Should be fixed now in git master:
a707d355c3c6ff92252c5a060a1fc32d97547552
f8c7d6a6162196a743f6885ecaf63ba50de1722a

Comment 7 Phil Armstrong 2009-04-05 08:09:30 UTC

(In reply to comment #6)
> Should be fixed now in git master:
> a707d355c3c6ff92252c5a060a1fc32d97547552
> f8c7d6a6162196a743f6885ecaf63ba50de1722a
> 

Unfortunately not. I get the same symptoms as before.

Anything else I can do?

Comment 8 Alex Deucher 2009-04-06 08:01:17 UTC

Created attachment 24605 [details] [review]
disable coherent mode by default

Does this patch help?

Comment 9 Phil Armstrong 2009-04-06 08:31:58 UTC

I can give it a go.

BTW, according to xrandr, coherent mode is set on for both output ports:

$ xrandr --prop
DVI-1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 546mm x 352mm
	EDID_DATA:
		00ffffffffffff0022f0f72601010101
		2912010380362378eece50a3544c9926
		0f5054a56b808140a900a940b300d100
		010101010101283c80a070b023403020
		360022602100001a000000fc00485020
		4c5032343735770a2020000000fd0030
		551e5e11000a202020202020000000ff
		00435a43383431303635480a20200066
	dvi_monitor_type: auto
	scaler: full
	coherent_mode: 1 (0x00000001)	range:  (0,1)
	load_detection: 1 (0x00000001)	range:  (0,1)
   1920x1200      60.0*+
   1600x1200      60.0  
   1680x1050      59.9  
   1600x1000      60.0  
   1280x1024      75.0  
   1280x960       60.0  
   1152x864       75.0  
   1024x768       75.0     60.0  
   832x624        74.6  
   800x600        75.0     60.3  
   640x480        75.0     59.9  
   720x400        70.1  
DVI-0 disconnected (normal left inverted right x axis y axis)
	dvi_monitor_type: auto
	scaler: full
	coherent_mode: 1 (0x00000001)	range:  (0,1)
	load_detection: 1 (0x00000001)	range:  (0,1)

Comment 10 Phil Armstrong 2009-04-06 08:54:39 UTC

NB. Surely I need coherent mode to be on for this monitor to work at all at standard refresh rates? It came with single-link DVI cables, so it seems likely that the receiver end in the monitor is single-link only.

Comment 11 Alex Deucher 2009-04-06 08:59:14 UTC

(In reply to comment #9)
> I can give it a go.
> 
> BTW, according to xrandr, coherent mode is set on for both output ports:

Right.  The default is to enable it.  this patch disables it by default.  You can also enable/disable it on the fly with
xrandr --output <output> --set coherent_mode <val>

(In reply to comment #10)
> NB. Surely I need coherent mode to be on for this monitor to work at all at
> standard refresh rates? It came with single-link DVI cables, so it seems likely
> that the receiver end in the monitor is single-link only.
> 

Coherent has nothing to do with single link vs. dual link, rather it affects how the clock is recovered in the monitor.  Most new monitors prefer coherent, however, that's not always the case.

Comment 12 Phil Armstrong 2009-04-06 10:09:43 UTC

(In reply to comment #11)
> Coherent has nothing to do with single link vs. dual link, rather it affects
> how the clock is recovered in the monitor.  Most new monitors prefer coherent,
> however, that's not always the case.

Indeed, but 1920x1200@60Hz can't be done in non-coherent single-link, whereas it just fits (with reduced blank timings) in the coherent mode available bandwidth IIRC.

Comment 13 Alex Deucher 2009-04-06 10:20:40 UTC

(In reply to comment #12)
> (In reply to comment #11)
> > Coherent has nothing to do with single link vs. dual link, rather it affects
> > how the clock is recovered in the monitor.  Most new monitors prefer coherent,
> > however, that's not always the case.
> 
> Indeed, but 1920x1200@60Hz can't be done in non-coherent single-link, whereas
> it just fits (with reduced blank timings) in the coherent mode available
> bandwidth IIRC.
> 

The timing is the same whether you are using coherent mode or not.  Some monitors work better with coherent mode other do not.  Does disabling coherent mode help?

Comment 14 Phil Armstrong 2009-04-06 11:07:17 UTC

(In reply to comment #13)

> The timing is the same whether you are using coherent mode or not.  Some
> monitors work better with coherent mode other do not.  Does disabling coherent
> mode help?

OK.

Sadly not.

However, further experimentation with windows has revealed that if the monitor is plugged into DVI-0 at boot, then I get a blank screen at startup. However, if I startup with the monitor plugged into DVI-1 & then transfer it to DVI-0 after logging in, then it picks up the display and everything works.

Weird. Maybe I actually do have a duff card & something is right on the edge for this card / monitor combination for DVI-0.

Comment 15 Phil Armstrong 2009-04-06 11:08:49 UTC

(In reply to comment #14) 
> Sadly not.

To clarify: disabling coherent mode doesn't appear to change the behaviour: apart from the fact that with coherent mode disabled I get a brief flash of the X startup before the display loses it & goes to sleep on DVI-0, but a solid display from DVI-1.

Comment 16 Phil Armstrong 2009-04-06 11:35:11 UTC

New information. I tried the hard-wired reduced blanking mode that worked on the sole DVI output of my R300 based card. It worked!

Looking at the logs, the only difference between the hard-wired mode, and the mode offered by the Xserver appears to be the Hsync setting: here's the relevant lines from the log:

(II) RADEON(0): Modeline "1920x1200R"x60.0  154.00  1920 1968 2000 2080  1200 1203 1209 1235 -hsync -vsync (74.0 kHz)
(II) RADEON(0): Modeline "1920x1200"x60.0  154.00  1920 1968 2000 2080  1200 1203 1209 1235 +hsync -vsync (74.0 kHz)

So colour me confused.

Comment 17 Alex Deucher 2009-04-06 11:50:34 UTC

(In reply to comment #16)
> New information. I tried the hard-wired reduced blanking mode that worked on
> the sole DVI output of my R300 based card. It worked!
> 
> Looking at the logs, the only difference between the hard-wired mode, and the
> mode offered by the Xserver appears to be the Hsync setting: here's the
> relevant lines from the log:
> 
> (II) RADEON(0): Modeline "1920x1200R"x60.0  154.00  1920 1968 2000 2080  1200
> 1203 1209 1235 -hsync -vsync (74.0 kHz)
> (II) RADEON(0): Modeline "1920x1200"x60.0  154.00  1920 1968 2000 2080  1200
> 1203 1209 1235 +hsync -vsync (74.0 kHz)
> 
> So colour me confused.
> 

I wonder if it's a bug in your monitor's edid?  Maybe it actually prefers -hsync.  Not sure why it would only have a problem on one encoder however.  Does the hard-coded mode also work on the other (previously working) DVI port?  FWIW, the 1920x1200 monitor I (Dell LCD), has the same preferred modeline in it's edid, however, it works fine on either DVI port on my RV730 card.

For reference:
(II) RADEON(0): Supported additional Video Mode:
(II) RADEON(0): clock: 154.0 MHz   Image Size:  519 x 324 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
(II) RADEON(0): Serial No: G283H8AD26FS
(II) RADEON(0): Monitor name: DELL 2408WFP
(II) RADEON(0): Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 170 MHz
(II) RADEON(0): EDID (in hex):
(II) RADEON(0):         00ffffffffffff0010ac2aa053463632
(II) RADEON(0):         2a12010380342078eab325ac5130b426
(II) RADEON(0):         105054a54b008180a940714f01010101
(II) RADEON(0):         010101010101283c80a070b023403020
(II) RADEON(0):         360007442100001a000000ff00473238
(II) RADEON(0):         3348384144323646530a000000fc0044
(II) RADEON(0):         454c4c20323430385746500a000000fd
(II) RADEON(0):         00384c1e5311000a20202020202000fd

Comment 18 Phil Armstrong 2009-04-06 13:15:02 UTC

(In reply to comment #17)
> I wonder if it's a bug in your monitor's edid?  Maybe it actually prefers
> -hsync.  Not sure why it would only have a problem on one encoder however. 
> Does the hard-coded mode also work on the other (previously working) DVI port? 

Yes, the hard-coded mode works on either port.

Comment 19 Jon Hurst 2009-04-29 12:30:40 UTC

I have a similar problem - I can't convince DVI-0 and DVI-1 to work at the same time with 6.12.2. 6.12.1-r1 (from gentoo - upstream patches included) works fine.

I startx and the display comes up as expected on DVI-0. I then bring in the second monitor with:

xrandr --output DVI-0 --left-of DVI-1

On 6.12.1-r1 the second monitor comes up and all is well. On 6.12.2, the second monitor comes up but the first blanks and switches off. If I now do:

xrandr --output DVI-0 --mode 0x3e

...the first monitor comes up and the second blanks.

xrandr --output DVI-0 --set coherent_mode 0

has the same effect. If I then change the mode on DVI-1, that monitor pops up and the first blanks again - it doesn't appear to be anything to do with what I am setting, just the act of setting something that toggles the monitor.

Comment 20 Alex Deucher 2009-04-29 12:38:03 UTC

(In reply to comment #19)
> I have a similar problem - I can't convince DVI-0 and DVI-1 to work at the same
> time with 6.12.2. 6.12.1-r1 (from gentoo - upstream patches included) works
> fine.

this is fixed in git after 6.12.2 was released:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=eea9800890b56bac9c07b7bd9c9e33fae2938af3

Comment 21 Jon Hurst 2009-04-30 01:00:19 UTC

(In reply to comment #20)
> this is fixed in git after 6.12.2 was released:
> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=eea9800890b56bac9c07b7bd9c9e33fae2938af3

Thanks. Confirmed as working fine in git version.

Comment 22 Alex Deucher 2009-10-21 13:35:53 UTC

Please re-open if this is still an issue.

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.