Created attachment 17248 [details] [review] Xorg.0.log for Fedora Core 8 This bug is identical to https://bugs.freedesktop.org/show_bug.cgi?id=12844 This bug has been marked as Resolved, yet I am having the identical symptoms even after upgrading to latest driver: xorg-x11-drv-ati-6.8.0-4.fc8.i386.rpm I think the ATI ES1000 chipset (device id: 515e) must have been missed in the resolution of 12844. Symptoms: Display is washed out (bleached) on 2nd monitor. Primary monitor is fine. On Fedora Core 5, both monitors using driver 6.6.3 are displaying normally. After upgrading to Fedora core 8 with the latest driver 6.8.0-4, the 2nd monitor is washed out. Contrast settings have no effect and greyed out sections are essentially unreadable. I did a diff on the settings for FC5 and FC8 as follows using radeontool: *** radeontool_regs_fc5 2008-06-18 15:39:50.000000000 +0100 --- radeontool_regs_fc8 2008-06-18 15:54:38.000000000 +0100 *************** *** 1,10 **** RADEON_DAC_CNTL=ff002102 ! RADEON_DAC_CNTL2=00010f80 ! RADEON_TV_DAC_CNTL=e0490223 RADEON_DISP_OUTPUT_CNTL=00000000 RADEON_CONFIG_MEMSIZE=04000000 RADEON_AUX_SC_CNTL=00000000 ! RADEON_CRTC_EXT_CNTL=00008048 RADEON_CRTC_GEN_CNTL=03200600 RADEON_CRTC2_GEN_CNTL=04000000 RADEON_DEVICE_ID=0000515e --- 1,10 ---- RADEON_DAC_CNTL=ff002102 ! RADEON_DAC_CNTL2=00000180 ! RADEON_TV_DAC_CNTL=20000000 RADEON_DISP_OUTPUT_CNTL=00000000 RADEON_CONFIG_MEMSIZE=04000000 RADEON_AUX_SC_CNTL=00000000 ! RADEON_CRTC_EXT_CNTL=00008040 RADEON_CRTC_GEN_CNTL=03200600 RADEON_CRTC2_GEN_CNTL=04000000 RADEON_DEVICE_ID=0000515e *************** *** 14,17 **** RADEON_GPIO_CRT2_DDC=00000300 RADEON_GPIO_DVI_DDC=00000300 RADEON_GPIO_VGA_DDC=00000300 ! RADEON_LVDS_GEN_CNTL=0880000a --- 14,17 ---- RADEON_GPIO_CRT2_DDC=00000300 RADEON_GPIO_DVI_DDC=00000300 RADEON_GPIO_VGA_DDC=00000300 ! RADEON_LVDS_GEN_CNTL=08000009 I downloaded radeontools-hacked so I could experiment with the register settings. I was able to fix the problem on the 2nd monitor by doing the following using the hacked radeontool: [root@chassis1 radeontool]# ./radeontool regset TV_DAC_CNTL 0xe0490223 OLD: TV_DAC_CNTL (088c) 0x00000000 NEW: TV_DAC_CNTL (088c) 0xe0490223 [root@chassis1 radeontool]# Contrast immediately became normal! The system I am using is a blade enclosure. Each computing blade has a VGA connector on the blade (this is the primary) and a Rear-transition module with another VGA connector (this is the secondary). No DVI outputs are available on these computing blades. I can provide details of the blade if required but I think you will conclude this is an ATI ES1000 (device id 515e) problem. I've attached the Xorg.0.log on Fedora Core 8. Regards, Geoff Linuxsolve Ltd (UK)
Created attachment 17256 [details] [review] possible fix Looks like the ES1000 may actually use the TV DAC rather than the primary DAC. Does this patch fix the issue?
Created attachment 17322 [details] [review] Radeontool registers after applying patch
Created attachment 17323 [details] Radeontool regs after manually setting TV_DAC_CNTL
The patch didn't work. I've attached 2 files: 1) radeontool_regs_fc8_notworking (after the patch was applied). I got a different value for TV_DAC_CNTL each time I grabbed the registers? See attached file. 2) radeontool_regs_fc8_working (after manually setting TV_DAC_CNTL via ./radeontool regset TV_DAC_CNTL 0xe0490223) fixed problem as per initial bug report. I've noted the following regarding the dac: If you do a # radeontool dac off ==> It turns off the 2nd (unbleached / normal) monitor. The monitor with the bleached out look stays on. My process for applying the patch was as follows. Please correct me if this was not the intention: 1) Install source rpm for 6.8.0-4 2) Append your patch to radeon-git-upsteam-fixes2.patch under /usr/src/redhat/SOURCES/ 3) Bump version number in spec file to 6.8.0-5 4) rpmbuild -ba xorg-x11-drv-ati.spec 5) rpm -Uvh /usr/src/redhat/RPMS/i386/xorg-x11-drv-ati-6.8.0-5.i386.rpm I verified patch took by inspecting /usr/src/redhat/BUILD/xorg*/src/radeon_bios.c Geoff.
ok, your bios only reports one connector (primary dac), while it sounds like you have two. Two VGA ports I assume? Can you send me your bios? (as root) cd /sys/bus/pci/devices/<pci domain:bus:slot.func>/ (looks like sys/bus/pci/devices/0000\:06\:0c.0/ in your case) echo 1 > rom cat rom > /tmp/videobios.rom echo 0 > rom
Yes. There are 2 VGA ports. Mirror image on both. I've attached the BIOS as requested.
Created attachment 17348 [details] ATI ES1000 Video BIOS ROM
Ugh. Unfortunately, you bios not only lists only 1 output (primary dac), it also lists an apparently invalid value for the bg/dac adj values for the tvdac. The following options should make everything work: Option "DefaultTVDACAdj" "TRUE" Option "ConnectorTable" "96,1,0,1,96,2,0,1"
Created attachment 17370 [details] Radeontool registers after making changes to xorg.conf as requested I modified xorg.conf -> Device section (see attached) with your suggestions. After applying the change to xorg.conf both monitors have no signal. Inoperative. I tried with the original xorg-x11-drv-ati-6.8.0-4 and the patched version, both with the same result. The file attached shows the registers after I made the xorg.conf change. I was able to get the primary monitor back after setting the radeon registers as per the working Fedora Core 5 settings. The second monitor still had no signal. For our application, we require both monitors working (mirrored). Just to clarify this problem because I'm not sure it's due to an incorrect BIOS etc => Both VGA monitors work perfectly when Fedora Core 5 or Windows XP are installed. It is only Fedora Core 8 (latest rpm) that is showing the fault as described in initial Bug report. Thanks for your continued assistance. Geoff.
Created attachment 17371 [details] [review] xorg.conf after applying Option settings as requested
Can you please attach your xorg log from the run with the options I suggested?
Created attachment 17390 [details] Xorg.0.log file for 6.8.0-4 rpm Attachments as requested. This one is for the unpatched Fedora Core 8 rpm - xorg-x11-drv-ati-6.8.0-4
Created attachment 17391 [details] Xorg.0.log file for patched 6.8.0-4 This attachment is for the Fedora core 8 6.8.0-4 patched with your ATI ES1000 radeon_bios.c patches.
Created attachment 17633 [details] [review] Xorg.0.log when Dell E172FP monitor attached to front working port When a Dell E172FP monitor is connected to the front VGA port of the Kontron CP6012 blade, the monitor is detected correctly and there is no bleaching evident. It is as expected. The Xorg.0.log file for this scenario is attached.
Created attachment 17634 [details] [review] Xorg.0.log when Dell E172FP monitor attached to rear port only When a Dell E172FP monitor is connected to the rear VGA port via the rear transition module (RTM) of the Kontron CP6012 blade, the monitor is 'not' detected correctly and there is 'bleaching' evident. The Xorg.0.log file for this scenario is attached and it shows a generic colour CRT monitor as being detected. Not the actual monitor (Dell E172FP) as for the front connected scenario.
Hi Alex, Hi Goeff, I'm working together with Goeff to investigate and to solve this problem with the ES1000. Currently, I'm in contact with ATI to get an solution for this. Currently I have a updated VGA BIOS where the connector issue you mentioned is fixed. Now, there are two VGA ports defined. Unfortunately, this doesn't solve the problem with the washed out. I did some investigations under Windows XP to see, how the register settings are here. What I can see is, that the content of the register is changing, depending on the configuration (monitor attached to 2nd port or not). In case of a connected monitor, the value is 0xe0490223. If no monitor is connected, the value is 0x00490203. Looking into the available register description, the main reason for the faulty display is the DAC output standard. As Goeff has show in his register reading, the default after starting the driver is 0x00000000. In order to get a reasonable picture, I have to change the DAC2 output standard (bits 9:8). According to the datasheet, 00b means it's configured to PAL, 10b means PS2. Setting to PS2 let the image become normal. This fits also to the settings seen under Windows. Starting the machine without the graphical environment, the result is 0xe0490223. So, the default after boot up seems to be correct. I havn't yet downloaded the driver to search for the piece of code which is changing the register. Do you have an idea? Is this intended somehow? Best regards, Adalbert
The driver should do the right thing if both dacs are listed in the bios connector tables. It explicitly sets the dac standard to PS/2 if the dac is being used for VGA (as opposed to tv). Can you attach your xorg log and config from the system with the updated bios?
Created attachment 18103 [details] [review] X.Org logfile using the new VGA BIOS (Fedora Core 8)
Created attachment 18104 [details] [review] xorg.conf file created by the installer. Hi Alex, I uploaded the config file as well as the log file. If you need more information, please let me know. Best regards, Adalbert
You are using a very old version of the driver which does not support cloning of multiple outputs on the same crtc. Please try again with xf86-video-ati 6.9.0 or from git.
This should be fixed now in ati git: 18429390440a829fb24ed3afd99ccf8278138496 there was an improper check for old radeons that was forcing the dac to always be the primary on single crtc cards.
Hi Alex / Adalbert, I cloned the ati driver git repo, verified Alex's commit was in place and then used autogen.sh --prefix=/usr; make; make install to apply it into /usr/lib/xorg/modules/drivers. Unfortunately, the monitor is still exhibiting the bleached out (washed out) look. Geoff.
(In reply to comment #22) > Unfortunately, the monitor is still exhibiting the bleached out (washed out) > look. Please attach your updated xorg log from git master.
(In reply to comment #23) > (In reply to comment #22) > > Unfortunately, the monitor is still exhibiting the bleached out (washed out) > > look. > > Please attach your updated xorg log from git master. > Not exactly sure what that means, so I've attached the output from the git log command and the Xorg.0.log file on the blade with the bleached monitor.
Created attachment 18695 [details] [review] Xorg.0.log file after recompiling ati_drv.so and radeon_drv.so from GIT
Created attachment 18696 [details] Output of 'git log' after 'git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati'
Sorry for the confusion, I just needed the xorg log. The bios you are using only lists the primary DAC in the connector table, so the driver has no knowledge of the second DAC. Either update your bios (as Adalbert did) or use the following options to force the connector table: Option "DefaultTVDACAdj" "TRUE" Option "ConnectorTable" "96,1,0,1,108,2,0,1" You may not need the first option if your bios has the proper dac adj values.
Applied the latest BIOS from Kontron. Seeing different behaviour now. 2nd screen (previously bleached) is now inactive when X starts. Fine prior to X starting (text mode). 1st screen is fine (as per normal). I tried adjusting the Options as you suggested and got the same behaviour as above. I've attached the xorg.conf and Xorg.0.log file.
Created attachment 18779 [details] [review] Xorg.conf xorg.conf
Created attachment 18780 [details] [review] Xorg.0.log after BIOS update.
(II) RADEON(0): Output VGA-1 connected (II) RADEON(0): Output VGA-0 disconnected (II) RADEON(0): Output VGA-1 using initial mode 1024x768 The driver is not able to detect a monitor attached to the second output so it does not turn the output on. You can use xrandr to force the output on: xrandr --addmode VGA-0 1024x768 xrandr --output VGA-0 --mode 1024x768
Tried the xrandr commands and both returned: "Can't open display". Tried xhost + (in case it was an X security issue) and it returned: unable to open display "" VGA-0 is being picked up correctly if there is a monitor connected (without the bleaching - so the driver path in combination with the BIOS upgrade have worked!) If there is no monitor connected, then the following message (as you found) is in the Xorg.0.log => (II) RADEON(0): Output VGA-0 disconnected. Connecting the monitor does not resolve the issue. Stays blank. VGA-1 which is the other VGA output for the ES1000 does not have a monitor connected but it always is connected in the X server start. Can we force VGA-0 in xorg.conf to do similar? At this point, we almost have a working system. We just have to ensure that the monitor is powered on and connected when the blade with the ATI ES1000 boots. Non-ideal but workable :( Also, could this be a vendor issue as the EDID / I2C info is not being detected for VGA-0 but it is for VGA-1 (even when both monitors disconnected)? (See previous Xorg.0.log)
(In reply to comment #32) > Tried the xrandr commands and both returned: > "Can't open display". > Tried xhost + (in case it was an X security issue) and it returned: > unable to open display "" If you are tryign to use xrandr remotely (via ssh for example), you'll need to either set the DISPLAY env var or specify the display to connect to on the xrandr command line (see xrandr --help). Most xinit scripts should take care of this. Try running xrandr from xterm or gnome-terminal or whatever X terminal app you are using. > VGA-0 is being picked up correctly if there is a monitor connected (without the > bleaching - so the driver path in combination with the BIOS upgrade have > worked!) Great! > If there is no monitor connected, then the following message (as you found) is > in the Xorg.0.log => > (II) RADEON(0): Output VGA-0 disconnected. Right. If there is nothing attached to an output the driver doesn't turn it on by default to save power and because it doesn't know what resolutions/refresh rates may or may not be safe to enable on whatever potential monitor could attached. You also have cases like DVI-I where you don't know whether the attached monitor is digital or analog and hence which encoder to driver the connector with. > Connecting the monitor does not resolve the issue. Stays blank. Right. You'll need to tell the driver (via xrandr) to re-detect the outputs. Either run 'xrandr --auto' to redetect the attached monitors or force the output on as per comment #13. > VGA-1 which is the other VGA output for the ES1000 does not have a monitor > connected but it always is connected in the X server start. > Can we force VGA-0 in xorg.conf to do similar? The driver attempts to pick a default output if nothing is connected. See this page for forcing static configurations in your xorg.conf (it's also a good general info page about xrandr): http://wiki.debian.org/XStrikeForce/HowToRandR12 > At this point, we almost have a working system. We just have to ensure that the > monitor is powered on and connected when the blade with the ATI ES1000 boots. > Non-ideal but workable :( You can either force a static config in your xorg.conf or run 'xrandr --auto' to redetect attached monitors at run time. > Also, could this be a vendor issue as the EDID / I2C info is not being detected > for VGA-0 but it is for VGA-1 (even when both monitors disconnected)? (See > previous Xorg.0.log) I'm not sure I follow you. In the log you attached in comment #30, the driver is able to get an EDID from VGA-1. So either you didn't have a monitor attached when you started X, or the driver isn't able to get an EDID from VGA-0. In the log Adalbert attached in comment #18 the driver is able to properly get an EDID from both monitors. Also you mentioned that VGA-0 works if a monitor is connected in comment #32 so presumably it's able to get an EDID in that case, so DDC seems to be working on both ports. The EDID comes from the monitor so if there is no monitor connected, the driver will not able to get one for that port.
(In reply to comment #33) > Right. You'll need to tell the driver (via xrandr) to re-detect the outputs. > Either run 'xrandr --auto' to redetect the attached monitors or force the > output on as per comment #13. Sorry, I meant comment #31.
Ok. xrandr isn't working for me. Probably because I'm on the virtual text terminals. exporting the DISPLAY isn't helping either. It's not the way we want to proceed anyway. My client needs to just turn on the monitor (connected to VGA-0) and see the display. I'm guessing there isn't a way to detect when a monitor has been connected and hook that into xrandr --auto ? Notes following refer to files in attached xorg-tests.tar The problem seems to be that VGA-1 always detects a Color CRT monitor even when nothing is connected. (See Xorg.0.log.no_monitors). Which is great if I was using that output. I can connect a monitor at any time / or power it on and it just works. What I need is to force this same behaviour with VGA-0. So I tried modifying xorg.conf. I disabled VGA-1 and enabled VGA-0. I don't want to specify the Modelines as I can't guarantee what monitor our customer will eventually connect. That didn't work. See Xorg.0.log_modified_xorg_conf. It needs a valid screen to start X and as none have been detected it fails. I've attached Xorg.0.log_monitor_VGA_0 as well which is the log for when a Dell LCD monitor is connected via VGA-0 and nothing is connected to VGA-1. It still detects a color CRT on VGA-1. >I'm not sure I follow you. In the log you attached in comment #30, the driver >is able to get an EDID from VGA-1. So either you didn't have a monitor >attached when you started X, or the driver isn't able to get an EDID from >VGA-0. I was assuming that some default I2C / EDID activity is occurring on VGA-1 even when no monitor is connected on this port as the Xorg.0.log is always reporting that a Color CRT is detected. Hence maybe the Vendor has done something unique in their hardware here to force this specific behaviour? Thanks for your continued help with this. Geoff.
Created attachment 18847 [details] Tarball of several Xorg.0.log results and a modified xorg.conf
(In reply to comment #35) > Ok. xrandr isn't working for me. Probably because I'm on the virtual text > terminals. exporting the DISPLAY isn't helping either. It's not the way we want > to proceed anyway. My client needs to just turn on the monitor (connected to > VGA-0) and see the display. I'm guessing there isn't a way to detect when a > monitor has been connected and hook that into xrandr --auto ? > Can you try on a terminal running on X? Do you have an up-to-date version of xrandr? Maybe your system has an old pre-1.2 support version. > Notes following refer to files in attached xorg-tests.tar > The problem seems to be that VGA-1 always detects a Color CRT monitor even when > nothing is connected. (See Xorg.0.log.no_monitors). Which is great if I was > using that output. I can connect a monitor at any time / or power it on and it > just works. What I need is to force this same behaviour with VGA-0. > That is from load detection. If DDC fails, we attempt to detect a monitor based on load on the primary DAC. If it's succeeding even when no monitor is attached, then either the algorithm needs adjustment for your chip (i.e., it's getting a false positive), or the connector is wired up in such a away that it always looks like a monitor is attached. > So I tried modifying xorg.conf. I disabled VGA-1 and enabled VGA-0. I don't > want to specify the Modelines as I can't guarantee what monitor our customer > will eventually connect. That didn't work. See Xorg.0.log_modified_xorg_conf. > It needs a valid screen to start X and as none have been detected it fails. > You'll need to specify some mode otherwise there will be no signal. If you don't know what sort of monitor will be attached xrandr is really your best bet. I would try and get that working. If you want you can just hack the driver to always detect the monitors as connected. I can provide a patch if you like. If you want it to be dynamic though, you really need to use xrandr. > I've attached Xorg.0.log_monitor_VGA_0 as well which is the log for when a Dell > LCD monitor is connected via VGA-0 and nothing is connected to VGA-1. It still > detects a color CRT on VGA-1. > > >I'm not sure I follow you. In the log you attached in comment #30, the driver > >is able to get an EDID from VGA-1. So either you didn't have a monitor > >attached when you started X, or the driver isn't able to get an EDID from > >VGA-0. > I was assuming that some default I2C / EDID activity is occurring on VGA-1 even > when no monitor is connected on this port as the Xorg.0.log is always reporting > that a Color CRT is detected. Hence maybe the Vendor has done something unique > in their hardware here to force this specific behaviour? > It's just load detection. See above. > Thanks for your continued help with this. No problem.
Another thing to try is enabling load detection for the secondary DAC. It's disabled by default as it's somewhat unreliable, especially on cards with TV-out and VGA since they both share the DAC. Add: Option "TVDACLoadDetect" "TRUE" to the device section of your xorg.conf
And down the rabbit hole we go. The TVDACLoadDetect option appeared to work perfectly. I have been using a KVM for my tests. When I restart X, the trick that rendered the screen blank previously was to switch to another monitor. The EDID/I2C would fail and the VGA-0 screen would be disconnected. After adding the option for TVDACLoadDetect to xorg.conf, switching back to the screen after X had restarted showed a working screen. Xorg.0.log informed that the monitor was detected as a Colour CRT and it looked like I had a solution. However, restarting X without anything connected to VGA-0 didn't detect a default Colour CRT like the primary DAC. The screen was blank again and VGA-0 disconnected in the log. Seems like the KVM was providing some signalling that the Driver was picking up even when it wasn't the monitor in focus. After a bit of hunting around, it appears the KVM connects pins 4 and 11 to ground when the focus is off that monitor, so that graphics drivers are fooled into thinking a Colour CRT @ 1024 x 768 is connected. Turns out our customer may be using a KVM style connection for our blades, so the problem may well be moot. Would be nice though to force the same behaviour as the primary DAC in the absence of a connected monitor via this xorg.conf Device Option. Thanks again for your help. I might need that patch still (unless you know of another Device parameter) if the customer's KVM doesn't offer the signalling mentioned above. Query - when would you expect the git repo changes you made to xorg-x11-drv-ati to make their way into the Fedora community updates?
(In reply to comment #39) > Query - when would you expect the git repo changes you made to xorg-x11-drv-ati > to make their way into the Fedora community updates? > Not sure (they may already be there), but redhat usually keeps their drivers pretty up to date.
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.