after installing latest x-swat intel driver for Karmic, screen is sometimes corrupted

Oded, could you attach /var/log/Xorg.0.log, /etc/X11/xorg.conf, and the output of `lspci -vvnn` here? You can attach this and some other useful information semi-automatically by running `apport-collect 396171`.

Does it happen when compiz is disabled?

Architecture: amd64
DistroRelease: Ubuntu 9.10
MachineType: LENOVO 88986DG
Package: xserver-xorg-video-intel 2:2.7.99.901+git20090702.74227141-0ubuntu1
PackageArchitecture: amd64
ProcCmdLine: root=UUID=414f00b9-7a73-447d-b354-7c8e9373e54e ro quiet splash
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-1.14-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4+3ubuntu4
 libgl1-mesa-glx 7.5~rc4-1ubuntu2
 libdrm2 2.4.11-0ubuntu1
 xserver-xorg-video-intel 2:2.7.99.901+git20090702.74227141-0ubuntu1
 xserver-xorg-video-ati 1:6.12.99+git20090629.f39cafc5-0ubuntu1
Uname: Linux 2.6.31-1-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare vboxusers
XorgConf: Error: [Errno 2] No such file or directory: '/etc/X11/xorg.conf'
dmi.bios.date: 07/01/2008
dmi.bios.vendor: LENOVO
dmi.bios.version: 7LETC1WW (2.21 )
dmi.board.name: 88986DG
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr7LETC1WW(2.21):bd07/01/2008:svnLENOVO:pn88986DG:pvrThinkPadT61:rvnLENOVO:rn88986DG:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 88986DG
dmi.product.version: ThinkPad T61
dmi.sys.vendor: LENOVO
fglrx: Not loaded
system:
 distro: Ubuntu
 architecture: x86_64kernel: 2.6.31-1-generic

These attachments are after I caused the screen corruption and then reset it back. I can generate the report while the screen is corrupted, but I thought about it only after the fact - let me know if you wish me to re-do it.

Re: comment #3 - yes, I have compiz enabled.

I was asking if you could try it with compiz disabled to see if it happens in that case as well, I have a feeling I know what it is and it would only happen when compiz is enabled.

Sorry, also happens with compiz disabled.

I've noticed that the graphics adapter resets itself to 85Hz refresh rate - which causes the screen corruption - rather spuriously: when connecting external monitors or coming back from sleep.

When the screen comes back from sleep, and the refresh rate is reset to 85Hz, I get this in Xorg.0.log:

---8<---
(II) intel(0): EDID for output VGA1
(II) intel(0): EDID for output LVDS1
(II) intel(0): Manufacturer: LEN Model: 4020 Serial#: 0
(II) intel(0): Year: 2007 Week: 35
(II) intel(0): EDID Version: 1.3
(II) intel(0): Digital Display Input
(II) intel(0): Max Image Size [cm]: horiz.: 29 vert.: 21
(II) intel(0): Gamma: 2.20
(II) intel(0): DPMS capabilities: StandBy Suspend Off
(II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
(II) intel(0): First detailed timing is preferred mode
(II) intel(0): redX: 0.610 redY: 0.330 greenX: 0.300 greenY: 0.530
(II) intel(0): blueX: 0.150 blueY: 0.130 whiteX: 0.313 whiteY: 0.329
(II) intel(0): Manufacturer's mask: 0
(II) intel(0): Supported additional Video Mode:
(II) intel(0): clock: 65.0 MHz Image Size: 287 x 215 mm
(II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
(II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
(II) intel(0): Supported additional Video Mode:
(II) intel(0): clock: 54.2 MHz Image Size: 287 x 215 mm
(II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
(II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0
(WW) intel(0): Unknown vendor-specific block f
(II) intel(0): LTD141ECMB
(II) intel(0): EDID (in hex):
(II) intel(0): 00ffffffffffff0030ae204000000000
(II) intel(0): 23110103801d1578ea6f959c544c8726
(II) intel(0): 21505400000001010101010101010101
(II) intel(0): 01010101010164190040410026301888
(II) intel(0): 36001fd7100000182815004041002630
(II) intel(0): 188836001fd7100000180000000f0061
(II) intel(0): 43326143280f010030640053000000fe
(II) intel(0): 004c544431343145434d420a202000e9
(II) intel(0): EDID vendor "LEN", prod id 16416
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
(II) intel(0): Modeline "1024x768"x0.0 54.16 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (40.3 kHz)
(II) intel(0): Not using default mode "1152x864" (exceeds panel dimensions)
(II) intel(0): Not using default mode "1280x960" (exceeds panel dimensions)
(II) intel(0): Not using default mode "1280x960" (exceeds panel dimensions)
(II) intel(0): Not using default mode "1280x1024" (exceeds panel dimensions)
(II) intel(0): Not using default mode "1280x1024" (exceeds panel dimensions)
(II) intel(0): Not using default mode "1280x1024" (exceeds panel dimensions)
(II) intel(0): Not using default mode "1600x1200" (exceeds panel dimensions)
(II) intel(0): Not using default mode "1600x1200" (exceeds panel dimensions)
(II) intel(0): Not using default mode "1600x1200" (exceeds panel dimensions)
(II) intel(0): Not using default mode "1600x1200" (exceeds panel dimensions)
(II) intel(0): Not using default mode "1600x1200" (exceeds panel dimensio...

Great that you found out that it was the 85 Hz frequency that causes the corruption. I have never seen a LVDS display running at 85 Hz before.

The added lines to Xorg.0.log is from EDID probing. This also happens when you run xrandr. Does simply running xrandr cause problems as well?

Just running xrandr doesn't do anything. the output is:
$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
VGA1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 287mm x 215mm
   1024x768 60.0*+ 85.0 75.0 70.1 60.0* 50.0
   832x624 74.6
   800x600 85.1 72.2 75.0 60.3 56.2
   640x480 85.0 72.8 75.0 59.9
   720x400 85.0
   640x400 85.1
   640x350 85.1
DVI1 disconnected (normal left inverted right x axis y axis)

Any refresh rate of anything over 60Hz cause the corruption - in this case the display configuration offers me, as can be seen, 70Hz, 75Hz and 85Hz refresh rates that cause problems.

Bug #398026 is interesting as on my system 60Hz works fine bug higher then that I get the corruption. The effect looks identical.

I have marked bug 398026 as a duplicate of this bug, even though it is reported for GM45 and this one is for 965GM. We usually don't duplicate bugs reported for different chipsets, but I think it is very likely that this is the same newly introduced bug.

The previous version of xserver-xorg-video-intel (...git20090602) had a bug in which only the preferred mode from the EDID information would be available (https://bugs.freedesktop.org/show_bug.cgi?id=20801). In ...git20090702 this bug is fixed and also other modes are available. The problem seems to be that for LVDS output the driver sometimes chooses a mode with the preferred resolution, but with a higher frequency (85 Hz instead of 60 Hz in bug 396171 and 60 Hz instead of 50 Hz in bug 398026).

As far as I can see, this bug is not upstream yet (it was introduced only recently) , so we should get it there. Upstream prefers to focus on a single use case, and I think Chris' (bug 398026) describes this better, as he has xrandr output and Xorg.0.log for both 20090602 and 20090702, so it's easy to see the difference. I don't have time to take this upsteam right now, but maybe Chris and Oded can take a look at each other's report and report any striking differences that I haven't seen. Also, if you could take a look at http://intellinuxgraphics.org/how_to_report_bug.html and see if there is some additional information that you may give so that we can include it upstream, that would be nice. To keep the two use cases apart, I think it is best if Chris attaches any additional info to his report and Oded to his.

I agree with Geir's assessment that Chris' bug is the one we should take upstream, so I'm reversing the dupe on this, even though this one was reported first. Hopefully whatever solves Chris' problem will do this one too, but on the off chance it doesn't, please un-dupe this one and we'll investigate further.