Created attachment 16674 [details] [review] My xorg.conf I have an ATI Radeon 9600 ("RV350 AP" chip, apparently) on a machine running Fedora 9. With a basic X.org configuration, the X server starts up successfully but I only get a blank screen. With the proprietary driver, I get normal output. (Well, I have historically; currently fglrx and F9 don't play well together.) This may be related to my monitor: a Dell 3007WFP with maximum resolution of 2560x1600. If I start X using the vesa driver, I also get either a blank screen or mangled output, where the GDM greeter is sheared horizontally really badly. (Whether I see something or nothing varies as I hit Ctrl-Alt-+ in vesa mode.) I'll attach my xorg.conf and a log from starting up the server. I'd really rather not have to use the proprietary driver, so I'm happy to help debug however possible. I'm a longtime Linux user and programmer so I'm comfortable doing tricky stuff to my system.
Created attachment 16675 [details] [review] An example log
for some reason the xserver is picking a random mode rather than one of the modes in the edid. (II) RADEON(0): Output DVI-1 connected (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): Output S-video disconnected (II) RADEON(0): Using sloppy heuristic for initial modes (II) RADEON(0): Output DVI-1 using initial mode 1152x864 You'll want to override that in the monitor section. If you have problems with 2560x1600, try 1280x800 next. Section "Monitor" Identifier "DVI-1" Option "DPMS" Modeline "2560x1600R" 268.50 2560 2608 2640 2720 1600 1603 1609 1646 +hsync -vsync Modeline "1280x800R" 71.00 1280 1328 1360 1440 800 803 809 823 +hsync -vsync Option "PreferredMode" "2560x1600R" #Option "PreferredMode" "1280x800R" EndSection Section "Device" Identifier "Videocard0" Driver "radeon" #Option "OpenGLOverlay" "off" #Option "VideoOverlay" "on" Option "Monitor-DVI-1" "DVI-1" EndSection
With 2560x1600R being the preferred mode, I also get a blank screen. The only significant difference in the logs is (as a diff): -(II) RADEON(0): Output DVI-1 has no monitor section +(II) RADEON(0): Output DVI-1 using monitor section DVI-1 +(**) RADEON(0): Option "PreferredMode" "2560x1600R" With 1280x800R, I get a GDM screen with the colors *completely* hosed. Funky messed-up-palette rainbow stuff going on. The log shows: -(II) RADEON(0): Output DVI-1 has no monitor section +(II) RADEON(0): Output DVI-1 using monitor section DVI-1 +(**) RADEON(0): Option "PreferredMode" "1280x800R" ... (II) RADEON(0): Output S-video disconnected -(II) RADEON(0): Using sloppy heuristic for initial modes -(II) RADEON(0): Output DVI-1 using initial mode 1152x864 +(II) RADEON(0): Using user preference for initial modes +(II) RADEON(0): Output DVI-1 using initial mode 1280x800R after xf86InitialConfiguration ... init pll1 -freq: 81620000 -best_freq: 81623077 -best_feedback_div: 786 -best_ref_div: 65 +freq: 71000000 +best_freq: 71000000 +best_feedback_div: 284 +best_ref_div: 27 best_post_div: 4 The log with PreferredMode = 2560x1600 still uses the "sloppy heuristic" to guess the mode; maybe this is related to the earlier line that says: (II) RADEON(0): Max desktop size set to 2560x1200 ?
(In reply to comment #3) > The log with PreferredMode = 2560x1600 still uses the "sloppy heuristic" to > guess the mode; maybe this is related to the earlier line that says: > > (II) RADEON(0): Max desktop size set to 2560x1200 So what happens if you add that Virtual line (Virtual 2560 1600, Section Screen, Subsection Display) to your xorg.conf?
I added a "Virtual" line and changed the preferred mode back to 2560x1600, restarted GDM, and ... my computer rebooted! The monitor went into standby mode for maybe 10 seconds, then I got my POST screen. That was exciting!
I should probably add that after the POST, my computer got to the point where the graphical boot would start and again the monitor went into standby mode. I let the computer sit for a little while and it didn't look like it was rebooting again, but it did look like it had hard-locked: the caps lock light wouldn't turn on and off, for instance, and the disk light wasn't flashing the way it would if the computer was actually booting in the background.
Does it work any better on the other DVI port (either the 2560 or 1280 modes)?
(In reply to comment #7) > Does it work any better on the other DVI port (either the 2560 or 1280 modes)? > Oh, man this is annoying. With 1280 on DVI-0, making the the appropriate changes in xorg.conf, it does work. Colors are fine, everything looks happy. But 2560 on DVI-0 won't work, because only DVI-1 has the dual-link connection necessary to drive the monitor at that resolution. I checked this: without the Virtual line, I get a blank screen as before, with the driver attempting to use the weird 1152x864 mode again. (As a side note, this time, the driver said the DPI was set to 96,96, not 53,76 as when on DVI-1.) When I tried 2560 on DVI-0 with the Virtual line, I got another computer reset. Being able to run at 1280 makes my computer usable, at least, but unsurprisingly, I'd very much like to be able to get it to run at 2560 ...
Created attachment 16694 [details] Log with DVI-0 and 1280x800 resolution While I have this computer booted up, here's a log from the X server when it worked in 1280 mode with the monitor on DVI-0.
(In reply to comment #8) > Oh, man this is annoying. > > With 1280 on DVI-0, making the the appropriate changes in xorg.conf, it does > work. Colors are fine, everything looks happy. > > But 2560 on DVI-0 won't work, because only DVI-1 has the dual-link connection > necessary to drive the monitor at that resolution. I checked this: without the > Virtual line, I get a blank screen as before, with the driver attempting to use > the weird 1152x864 mode again. (As a side note, this time, the driver said the > DPI was set to 96,96, not 53,76 as when on DVI-1.) When I tried 2560 on DVI-0 > with the Virtual line, I got another computer reset. > > Being able to run at 1280 makes my computer usable, at least, but > unsurprisingly, I'd very much like to be able to get it to run at 2560 ... > The basic root cause of this (barring the xserver picking the wrong mode), is that the bios does not appear to set up the external TMDS encoder to work in duallink mode. The driver attempts to set up the encoder, but it doesn't appear to work in your case. This may also explain the reboot as the external TMDS encoder is hanging off some unknown GPIO on the radeon. Unfortunately, without knowing what chip is used and how it's connected, there's not much we can do.
Is there any research I can do to help diagnose what needs to be fixed? Some kind of tracing of the fglrx driver or anything? Or even a particular function in the driver that I can futz with to see if anything helps?
(In reply to comment #11) > Is there any research I can do to help diagnose what needs to be fixed? Some > kind of tracing of the fglrx driver or anything? Or even a particular function > in the driver that I can futz with to see if anything helps? > Well, you can identify the chip by looking at the card. It's probably a siliconimage chip of some sort (sil-something). The hard part is figuring out the gpio line and pins used for i2c to configure the chip. You may be able to tell from tracing what the bios or fglrx does when it sets a mode on that ouput. As to the radeon driver, take a look at RADEONInitExtTMDSInfoFromBIOS() and RADEONGetExtTMDSInfoFromBIOS(). The bios has a table for what gpio reg it uses and the commands to set up the chip, but, I'm not sure how to find out what pins it uses or what's needed to enable them. The problem is I think it tends to vary based on the OEM. I'll ask around AMD and see what I can find out.
(In reply to comment #12) > Well, you can identify the chip by looking at the card. It's probably a > siliconimage chip of some sort (sil-something). The hard part is figuring out > the gpio line and pins used for i2c to configure the chip. You may be able to > tell from tracing what the bios or fglrx does when it sets a mode on that > ouput. Looking at it, I see two smallish (~1cm x 1cm) chips near the DVI outputs that are labeled Silicon Image TMDS PanelLink SII178CTG64 VJ7530.1-7 0541 2.0 The chips are identical, which seems a bit weird since one connector is dual-link and the other isn't. I haven't had time to play with the software at all yet, unfortunately.
I've finally gotten the chance to take a further look at debugging what's going on inside the driver. I'm using git master of the X server, xf86-video-ati, and their relevant dependencies. As a side question, it seems like in my situation, DVI-1 is connected to Port0 and DVI-0 is connected to Port1. Is that plausible? As far as I can figure out, there are three problems here: * Without a "Virtual 2560 1600" line, the server chooses a bogus mode to try to use. When I first reported the bug, it was 1152x864; now it's 1600x1200; it should be using the monitor's other reported mode, 1280x800. * If I force 1280x800 and use DVI-1, I get what may be the right resolution, but my colors are totally messed up. * If I enable 2560x1600, nothing happens since it seems that the TMDS isn't set up into dual-link mode correctly. I'm focusing on the second problem at the moment. I imagine that maybe some piece of hardware isn't getting set up correctly here. If I step through legacy_output_mode_set, eventually there's a call to RADEONInitExtTMDSInfoFromBIOS, which was mentioned to me as a function to look at. There are some calls to RADEONDVOWriteByte that fail and show up in my logs: i2c write: 0xe, 0x0 (EE) RADEON(0): Unable to write to DVO Slave 112. i2c write: 0x8, 0x39 (EE) RADEON(0): Unable to write to DVO Slave 112. i2c write: 0x9, 0x38 (EE) RADEON(0): Unable to write to DVO Slave 112. i2c write: 0xa, 0x90 (EE) RADEON(0): Unable to write to DVO Slave 112. i2c write: 0xc, 0x89 (EE) RADEON(0): Unable to write to DVO Slave 112. i2c write: 0x33, 0x0 (EE) RADEON(0): Unable to write to DVO Slave 112. i2c write: 0xd, 0x0 (EE) RADEON(0): Unable to write to DVO Slave 112. Might these messages be related to what I'm seeing, or should I look elsewhere? (There is some promise for the third problem of setting up the TMDS in dual-link mode. In RADEONInitFP2Registers, I see: if (IS_R300_VARIANT) { ... #if 0 if (mode->Clock > 165000) save->fp2_gen_cntl |= R300_FP2_DVO_DUAL_CHANNEL_EN; #endif } Is there an explanation for why those lines are commented out? It sounds like that bit might be exactly what I need. But, again, I'd like to get 1280x800 working before working on 2560x1600.)
Ping. I've intermittently tested git master of xorg-server and xf86-video-ati over the past 10 months and (not surprisingly) I still see the same symptoms. Any feedback on the questions in my previous comment?
(In reply to comment #14) > i2c write: 0xe, 0x0 > (EE) RADEON(0): Unable to write to DVO Slave 112. > i2c write: 0x8, 0x39 > (EE) RADEON(0): Unable to write to DVO Slave 112. > i2c write: 0x9, 0x38 > (EE) RADEON(0): Unable to write to DVO Slave 112. > i2c write: 0xa, 0x90 > (EE) RADEON(0): Unable to write to DVO Slave 112. > i2c write: 0xc, 0x89 > (EE) RADEON(0): Unable to write to DVO Slave 112. > i2c write: 0x33, 0x0 > (EE) RADEON(0): Unable to write to DVO Slave 112. > i2c write: 0xd, 0x0 > (EE) RADEON(0): Unable to write to DVO Slave 112. > > Might these messages be related to what I'm seeing, or should I look elsewhere? The driver isn't able to communicate with the tmds controller which is probably the problem. Accessing the external tmds only seems to work on some cards using the hw i2c controller rather than bit-banging the gpios directly. > if (IS_R300_VARIANT) { > ... > #if 0 > if (mode->Clock > 165000) > save->fp2_gen_cntl |= R300_FP2_DVO_DUAL_CHANNEL_EN; > #endif > } > > Is there an explanation for why those lines are commented out? It sounds like > that bit might be exactly what I need. But, again, I'd like to get 1280x800 > working before working on 2560x1600.) > You might need them, it depends on how the tmds controller is connected to the DVO port. There are 3 possible combinations: SDR single channel (data rate 165 Mhz, port width 12 bits) DDR single channel (data rate 330 Mhz, port width 12 bits) SDR dual channel (data rate 330 Mhz, port width 24 bits) Relevant bits in FP2_GEN_CNTL: R200_FP2_DVO_RATE_SEL_SDR selects SDR or DDR R300_FP2_DVO_DUAL_CHANNEL_EN selects DVO channels In your case, I'd try DDR single channel or SDR dual channel.
After looking into the driver a little bit and deciding that fixing this problem would be too much work, I have worked around this bug by buying a new graphics card. I think I'm the only person who will ever care about this, so I'm closing it as WONTFIX.
Would be nice to see if someone could take up this bug. There is at least one more person interested. I'm trying to drive a 30" display at 2560x1600 with an ATI RV350 on an old PowerMac G5. Seems to be the same issue. Unfortunately I can't even try proprietary driver, doesn't exist for powerpc.
(In reply to comment #18) > Would be nice to see if someone could take up this bug. There is at least one > more person interested. I'm trying to drive a 30" display at 2560x1600 with an > ATI RV350 on an old PowerMac G5. Seems to be the same issue. Unfortunately I > can't even try proprietary driver, doesn't exist for powerpc. You'd need to figure out what external tmds chip is used on your board and what i2c line it's connected to. Unfortunately mac cards do not have the information available via a table in the vbios and as such have to be hard-coded in the driver. If you enable kms on newer kernels, you should be able to probe the i2c buses on the card and look for the tdms chip.
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.