Hello, as explained in IRC I've got problems with my Sapphire X1650Pro card. I'm using the latest git master and this problem doesn't occur on my laptop (X1250). The "color" grey seems like white so on I can't figure out many things correctly on my TFT. I attached a screenshot (if I take a screenshot of it there it's all normal) and marked some points with comments. I hope it will be enough if I quote the irc log here: <the-me> libv, hm no, I try to explain it :) on my desktop (it doesnt occur on my notebook) with my x1650 pro from sapphire the white has a very big brightness, also grey, too. now for example at kde I can't see any differences between white and grey "colors". I would like to show you it but if I took a screenshot it seems normal again. with my tft setup everything is fine and I also tried to tune it so that it looks normal again :( <the-me> both setups are based on debian sid with radeonhd git master <libv> the-me: have you played with xgamma? <the-me> hmm never played with. at the moment every value eq 1.000 <the-me> ah: if I start it with fglrx for example everything is fine again (or vesa) - it just occurs with radeonhd <libv> the-me: can you play with xgamma, and if this doesn't fully solve the issue file a bug? <the-me> libv, hm okay also not very usefull (like tuning my tft itself). I created a screenshot on the box and added some comments on it - would be nice if you would have a look first on it (not so easy to explain it in english *grml*) ;) <the-me> libv, ok here is the screenshot: (***SEE ATTACHMENT***) to the comment numbers: #1: the font is just an little little bit grey, nearly unreadable. #2: the color of the lower and upper arrow are nearly the same (white). #3: unable to see this grey breaking line #4: same like #2 and #3 but there I can see an little little difference between both :) <libv> the-me: is this on tmds or on the dac? <libv> the-me: is this a digitally connected monitor, or is it connected to analog? <the-me> ah. this graphic board just has two digitally connector. there's such a digital -> analog plug after that and then the tft is plugged about a vga cable to it <libv> right, so a dac <libv> find out which dac from the log, DACA or DACB <the-me> libv, http://nopaste.linux-dev.org/?615 Okay right now here are the results: Is it DACA or DACB?: ==================== # grep -i dac /var/log/Xorg.0.log (II) RADEONHD(0): Connector[0] {RHD_CONNECTOR_DVI, "DVI-I CRT1 DFP3", RHD_DDC_0, RHD_HPD_1, { RHD_OUTPUT_DACA, RHD_OUTPUT_LVTMA } } (II) RADEONHD(0): Connector[1] {RHD_CONNECTOR_TV, "SVIDEO TV1", RHD_DDC_NONE, RHD_HPD_NONE, { RHD_OUTPUT_DACB, RHD_OUTPUT_NONE } } (II) RADEONHD(0): Connector[2] {RHD_CONNECTOR_DVI, "DVI-I DFP1 CRT2", RHD_DDC_1, RHD_HPD_0, { RHD_OUTPUT_TMDSA, RHD_OUTPUT_DACB } } (--) RADEONHD(0): Attaching Output DAC A to Connector DVI-I 1 (--) RADEONHD(0): Attaching Output DAC B to Connector TV SVIDEO (--) RADEONHD(0): Attaching Output DAC B to Connector DVI-I 2 (II) RADEONHD(0): RandR: Adding RRoutput DVI-I_1/analog for Output DAC A (II) RADEONHD(0): RandR: Adding RRoutput TV_SVIDEO for Output DAC B (II) RADEONHD(0): RandR: Adding RRoutput DVI-I_2/analog for Output DAC B (II) RADEONHD(0): DAC B: Sensed Output: VGA (II) Loading sub module "ramdac" (II) LoadModule: "ramdac"(II) Module "ramdac" already built-in (WW) RADEONHD(0): RandR: While switching off TV_SVIDEO: output DAC B is also used by DVI-I_2/analog - ignoring (WW) RADEONHD(0): RandR: While switching off TV_SVIDEO: output DAC B is also used by DVI-I_2/analog - ignoring (WW) RADEONHD(0): RandR: While switching off TV_SVIDEO: output DAC B is also used by DVI-I_2/analog - ignoring (WW) RADEONHD(0): RandR: While switching off TV_SVIDEO: output DAC B is also used by DVI-I_2/analog - ignoring rhd_dump output with radeonhd: ============================== exez:/usr/src/xf86-video-radeonhd/utils/conntest# ./rhd_dump -r 7A00,7A70 05:00.0 rhd_dump: v1.2.1, git branch master, commit 1f65f354 0x7A00: 0x00000001 0x7A04: 0x00000000 0x7A08: 0x00000000 0x7A0C: 0x00000000 0x7A10: 0x3FFFFFFF 0x7A14: 0x0000003F 0x7A18: 0x3FFFFFFF 0x7A1C: 0x0000003F 0x7A20: 0x00000000 0x7A24: 0x00000000 0x7A28: 0x00070000 0x7A2C: 0x0000000B 0x7A30: 0x00000000 0x7A34: 0x02020200 0x7A38: 0x00000000 0x7A3C: 0x00000000 0x7A40: 0x00000000 0x7A44: 0x00000000 0x7A48: 0x00000000 0x7A4C: 0x00000000 0x7A50: 0x00000000 0x7A54: 0x00050602 0x7A58: 0x00000000 0x7A5C: 0x00000000 0x7A60: 0x00000000 0x7A64: 0x00000000 0x7A68: 0x00000002 0x7A6C: 0x00000000 0x7A70: 0x00000000 rhd_dump output with vesa: ========================== exez:/usr/src/xf86-video-radeonhd/utils/conntest# ./rhd_dump -r 7A00,7A70 05:00.0 rhd_dump: v1.2.1, git branch master, commit 1f65f354 0x7A00: 0x00000001 0x7A04: 0x00000000 0x7A08: 0x00000000 0x7A0C: 0x00000000 0x7A10: 0x3FFFFFFF 0x7A14: 0x0000003F 0x7A18: 0x3FFFFFFF 0x7A1C: 0x0000003F 0x7A20: 0x00000000 0x7A24: 0x00000000 0x7A28: 0x00070000 0x7A2C: 0x0000000B 0x7A30: 0x00000000 0x7A34: 0x02020200 0x7A38: 0x00000000 0x7A3C: 0x00000000 0x7A40: 0x00000000 0x7A44: 0x00000000 0x7A48: 0x00000000 0x7A4C: 0x00000000 0x7A50: 0x00000000 0x7A54: 0x00051002 0x7A58: 0x00000000 0x7A5C: 0x00000000 0x7A60: 0x00000000 0x7A64: 0x00000000 0x7A68: 0x00000002 0x7A6C: 0x00000000 0x7A70: 0x00000000 How you can see, the only option which is different from vesa is 0x7A54 => 0x00050602 (radeonhd) vs. 0x00051002 (vesa). :)
Created attachment 17201 [details] Screenshot with comment numbers
First; rhd_dump with -w 0x7A54 0x00051002 This command changes everything as it has to be, the bios dump will follow now.
Created attachment 17203 [details] BIOS dump
WhiteFineControl values depend on Asic, DAC, TV mode and TV standard. I don't have time to deal with this ATM.
*** Bug 16211 has been marked as a duplicate of this bug. ***
Commit ae159a1d68157bac0c051fb9488f103a2e390928 should address this issue. The attached BIOS contains a 'Compassionate Data' table therefore it's particularly easy to solve for this case. Please test.
Same problem here. I've wrongly reported this on the "radeon" driver, that suffered of the same problem. Here's the report: I'm running Debian Lenny, xorg 7.3, xserver-xorg-video-radeonhd 1.2.1, ATI X1300 based Sapphire video card, Philips 220AW LCD monitor connected on DVI-I_1/analog through DVI to VGA adapter, set as primary display, and older 17" CRT (apparently not plug and play) on VGA_1. According to the grayscale in the KDE 3.5.9 display options, gamma section, everything from E4E4E4 is displayed as white on the LCD. The CRT is fine. Changing gamma does not really help, the problem is only on the high luminosity range, as if values are scaled and clamped (very well visible on a GIMP color selector). Using the "ati" xorg driver (that is xserver-xorg-video-radeon 6.9.0) instead of "radeonhd", the LCD displays fine, but I lose the dual monitor (same image on both monitors).
This has been fixed in GIT master a while ago. Please retest with the current HEAD from GIT master. I assume this bug is FIXED. If you still see issues with the latest GIT versions please reopen.
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.