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.
Created attachment 24542 [details] [review] Working Xorg log
Created attachment 24543 [details] [review] Xorg output
Created attachment 24544 [details] [review] Working Xorg output
Created attachment 24545 [details] [review] Xorg.conf
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.
Should be fixed now in git master: a707d355c3c6ff92252c5a060a1fc32d97547552 f8c7d6a6162196a743f6885ecaf63ba50de1722a
(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?
Created attachment 24605 [details] [review] disable coherent mode by default Does this patch help?
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)
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.
(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.
(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.
(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?
(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.
(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.
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.
(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
(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.
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.
(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
(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.
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.