Bug 21191

Summary:	Screen corruptions on intel hardware
Product:	xorg	Reporter:	Nicolas Bigaouette <nbigaouette>
Component:	Server/Acceleration/EXA	Assignee:	Xorg Project Team <xorg-team>
Status:	RESOLVED WONTFIX	QA Contact:	Xorg Project Team <xorg-team>
Severity:	normal
Priority:	medium	CC:	freedesktop-bugzilla, nbigaouette
Version:	7.4 (2008.09)
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Nicolas Bigaouette 2009-04-14 19:52:43 UTC

Using:
xorg 7.4
xorg-server 1.6.0
intel-dri 7.4
xf86-video-intel 2.6.3

I am facing some screen corruptions, as seen on this screenshot:
http://nbigaouette.inrs-emt.homelinux.net/linux/arch/xf86_video_intel_corruption.png
The only way to make it disappear is to force a redraw. It is not sufficient to hide the window and make it appear again. If the corruption appears inside the text of a KDE editor, moving the cursor to the corrupted line should change its background color and thus force a redraw. Or if it appears in toolbars, I need to mouse over the toolbard to refresh it.

This happens on both of my computers. One is an asus eeepc 1000:
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

The other is a Dell Optiplex 755 desktop:
00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02)
00:02.1 Display controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02)

Both are using kwin's compositing and no xorg.conf.

These are what might look suspiscious from /var/log/Xorg.0.log:
[...]
(II) intel(0): Comparing regs from server start up to After PreInit
(WW) intel(0): Register 0x61114 (PORT_HOTPLUG_STAT) changed from 0x00000000 to 0x00000b00
[...]
(II) intel(0): I830CheckAvailableMemory: 4669436 kB available
(WW) intel(0): DRI2 requires UXA
[...]
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: Open failed
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: Open failed
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 10, (OK)
drmOpenByBusid: drmOpenMinor returns 10
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(II) [drm] loaded kernel module for "i915" driver.
[...]
exaCopyDirty: Pending damage region empty!

Comment 1 Michel Dänzer 2009-04-15 00:54:08 UTC

Does

    Option "ExaOptimizeMigration" "off"

work around the problem?

Comment 2 Nicolas Bigaouette 2009-04-15 09:18:22 UTC

I tried
Option "ExaOptimizeMigration" "off"
as you suggested, and until now I did not see the corruption problem (on the eee 1000 only). I did not fully used the machines though, I'll report back.

What does it do?

Comment 3 Michel Dänzer 2009-04-15 09:37:17 UTC

(In reply to comment #2)
> What does it do?

It disables an optimization which reduces pixmap migration overhead but which can expose bugs in the way other EXA code uses the damage tracking facilities.

Comment 4 Michel Dänzer 2009-05-09 10:53:26 UTC

I'm having a hard time reproducing this with EXA from current upstream xserver Git. Can you try that?

Comment 5 Nicolas Bigaouette 2009-05-09 19:22:25 UTC

I'm sorry I wont be able to test it... After trying the workaround, I switched to KMS+DRI2+UXA where I don't see this problem on two out of three machines: on the third one I have similar problem (with KMS+DRI2+UXA too).

I say similar and not same, because it could be something unrelated... I'll have access to that machine on monday, I'll report back...

Comment 6 Michel Dänzer 2009-05-10 07:11:50 UTC

(In reply to comment #5)
> I'm sorry I wont be able to test it... After trying the workaround, I switched
> to KMS+DRI2+UXA where I don't see this problem on two out of three machines: on
> the third one I have similar problem (with KMS+DRI2+UXA too).
> 
> I say similar and not same, because it could be something unrelated... I'll
> have access to that machine on monday, I'll report back...

UXA is an in-driver fork of EXA, any tests with UXA have no bearing on this report.

Comment 7 Nicolas Bigaouette 2009-05-10 09:16:59 UTC

That's why I said similar, and not same. It's probably something completely different.

Comment 8 Matt Turner 2010-12-02 19:24:23 UTC

Closing due to inactivity and that the problems the reporter was seeing at last update are probably different than what was originally reported. Please open a new bug report if you still have issues.

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.