Hi there. My Thinkpad R500 develops a red tinge on the right hand half of the screen when using KMS. The problem goes away if I use UMS and set NewPll=True in xorg.conf. The problem did not occur in Ubuntu Hardy and doesn't occur under Windows 7. The tinge is strange. The left hand side of the screen is fine, but the right hand side seems to have a red vertial banding as if the phase was slightly wrong. Note that whites are still white. The problem can take a while (~30 minutes) to appear. Changing the update rate between 50 and 60 Hz has no effect. Seen both under Unbuntu Lucid and Ubuntu Maverick. My current setup under Maverick is: X.Org X Server 1.9.0 Release Date: 2010-08-20 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.24-27-server x86_64 Ubuntu Current Operating System: Linux crucis 2.6.36-996-generic #201010080908 SMP Fri Oct 8 09:09:53 UTC 2010 x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.36-996-generic root=UUID=8888e0eb-2088-4a61-9fd8-56321be8f3a9 ro quiet splash Build Date: 16 September 2010 06:18:41PM xorg-server 2:1.9.0-0ubuntu7 (For technical support please see http://www.ubuntu.com/support) Current version of pixman: 0.18.4 The kernel is the latest 2.6.36 from the Ubuntu kernel PPA. The same problem occurs under the Lucid kernel and 2.6.35. The machine is a Lenovo Thinkpad R500 with a 15" 1680x1050 screen. Xorg.0.log contains the following: ... [ 18.270] (II) RADEON(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 18.270] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 [ 18.270] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [ 18.270] (==) RADEON(0): Default visual is TrueColor [ 18.270] (==) RADEON(0): RGB weight 888 [ 18.270] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [ 18.270] (--) RADEON(0): Chipset: "ATI Mobility Radeon HD 3400 Series" (ChipID = 0x95c4) [ 18.270] (II) RADEON(0): PCIE card detected ... [ 18.314] (II) RADEON(0): Manufacturer: LEN Model: 4053 Serial#: 0 [ 18.314] (II) RADEON(0): Year: 2007 Week: 0 [ 18.314] (II) RADEON(0): EDID Version: 1.3 [ 18.314] (II) RADEON(0): Digital Display Input [ 18.314] (II) RADEON(0): Max Image Size [cm]: horiz.: 33 vert.: 21 [ 18.314] (II) RADEON(0): Gamma: 2.20 [ 18.314] (II) RADEON(0): DPMS capabilities: StandBy Suspend Off [ 18.314] (II) RADEON(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 [ 18.314] (II) RADEON(0): First detailed timing is preferred mode [ 18.314] (II) RADEON(0): redX: 0.569 redY: 0.332 greenX: 0.312 greenY: 0.544 [ 18.314] (II) RADEON(0): blueX: 0.149 blueY: 0.132 whiteX: 0.313 whiteY: 0.329 [ 18.314] (II) RADEON(0): Manufacturer's mask: 0 [ 18.314] (II) RADEON(0): Supported detailed timing: [ 18.314] (II) RADEON(0): clock: 122.0 MHz Image Size: 331 x 207 mm [ 18.314] (II) RADEON(0): h_active: 1680 h_sync: 1712 h_sync_end 1776 h_blank_end 1904 h_border: 0 [ 18.314] (II) RADEON(0): v_active: 1050 v_sync: 1051 v_sync_end 1054 v_blanking: 1066 v_border: 0 [ 18.314] (II) RADEON(0): Supported detailed timing: [ 18.314] (II) RADEON(0): clock: 101.7 MHz Image Size: 331 x 207 mm [ 18.314] (II) RADEON(0): h_active: 1680 h_sync: 1712 h_sync_end 1776 h_blank_end 1904 h_border: 0 [ 18.314] (II) RADEON(0): v_active: 1050 v_sync: 1051 v_sync_end 1054 v_blanking: 1066 v_border: 0 [ 18.314] (II) RADEON(0): Unknown vendor-specific block f [ 18.314] (II) RADEON(0): LTN154P3-L02 [ 18.314] (II) RADEON(0): EDID (in hex): ... [ 18.314] (II) RADEON(0): Printing probed modes for output LVDS [ 18.314] (II) RADEON(0): Modeline "1680x1050"x60.1 122.00 1680 1712 1776 1904 1050 1051 1054 1066 -hsync -vsync (64.1 kHz) [ 18.314] (II) RADEON(0): Modeline "1680x1050"x50.1 101.67 1680 1712 1776 1904 1050 1051 1054 1066 -hsync -vsync (53.4 kHz) [ 18.314] (II) RADEON(0): Modeline "1400x1050"x60.0 121.75 1400 1488 1632 1864 1050 1053 1057 1089 -hsync +vsync (65.3 kHz) [ 18.314] (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz)
Does booting with radeon.new_pll=0 on the kernel command line help? You can also test this set of drm patches: http://people.freedesktop.org/~agd5f/pll_fixes/ or test Dave's drm-next branch: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-next as it already has those patches.
The 2.6.36 kernel the reporter refers to is a recent build of drm-next, current up to commit 47dafe7d, so that kernel should have had the pll fixes applied.
(In reply to comment #2) > The 2.6.36 kernel the reporter refers to is a recent build of drm-next, current > up to commit 47dafe7d, so that kernel should have had the pll fixes applied. In that case, radeon.new_pll=0 is only applicable to 2.6.35.
Does reverting f28488c282d8916b9b6190cc41714815bbaf97d5 from drm-next help?
Michael Hope, Ubuntu Lucid Desktop reached EOL on May 9, 2013. For more on this, please see https://wiki.ubuntu.com/Releases . If this is still reproducible in a supported release, it will help immensely if you filed a new report with Ubuntu by ensuring you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information running the following from a terminal: ubuntu-bug xorg Also, please feel free to subscribe me to it. For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.
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.