Bug 33929

What kernel are you using?  Please attach your xorg log and dmesg output.

I'm using kernel-2.6.37 on x86_64

Created attachment 43027 [details]
dmesg output

Created attachment 43028 [details]
Xorg.0.log

Created attachment 43029 [details]
just opening previously opened .doc file

screen start to slightly corrupt

Created attachment 43030 [details]
switching to another workspace then back: screen is now fully corrupted after redrawing

Created attachment 43031 [details]
switching to last workspace

note in red surrouned areas: some blue pixels moving along selected workspace both where desktops/workspaces are displayed in gnome bar and in middle of screen

*** Bug 34013 has been marked as a duplicate of this bug. ***

I forgot to say there's no difference between october snapshot & 6.14 in Xorg.0.log beside the supported card list and one new line ("SwapBuffers wait for vsync: enabled" if I remember right)

There might be more dups according to https://bugs.freedesktop.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=PLEASETEST&content=color%20tiling&product=&query_format=specific&order=bug_id%20DESC&query_based_on=

Indeed using 'Option "ColorTiling" "false"' fixes this bug

Created attachment 43095 [details] [review]
Update GPU copy pitch in exaModifyPixmapHeader_mixed

Does this xserver patch help?

I think the following bugs are probably related:
bug 33929
bug 33952
bug 33943
bug 33963

*** Bug 33943 has been marked as a duplicate of this bug. ***

That fixes it indeed

Except that now mplayer now misteriously die when going forward

I think I'm seeing the same bug. After login via KDM the whole screen looks scrambled, similar to attachment 43031 [details] (switching to last workspace) in this bug.

It started after upgrading from xf86-video-ati-6.13.2 to 6.14.0 and can be fixed by adding "ColorTiling" "false".

I'm using kernel 2.6.38-rc3/4 with KMS on a RV370 (RV370 5B60 [Radeon X300 (PCIE)]), compositing in KDE is off, the X-Server is 1.9.3.902.

Should I try the GPU-copy-pitch patch against that version or would 1.9.99.901 be better?

(In reply to comment #15)
> Except that now mplayer now misteriously die when going forward

'going forward' as in fast forwarding the video, or what? Any evidence that this is directly related to this bug/patch at all, or at least any information about mplayer's death?


(In reply to comment #16)
> Should I try the GPU-copy-pitch patch against that version or would 1.9.99.901
> be better?

Shouldn't matter.

well, the segfault only happens when using the patched xserver.

I was using "mplayer -vo gl" (which thus do invoke some EXA paths I think?) due to bug #32871 where colors got corrupted with XV after suspending/resuming.

mplayer -vo gl always segfaulted while using that server, segfault disappeared once downgrading to previous version.

The segfault happened when:
- using any key to move forward
- using -ss to move forward

I hadn't the debug package at the time and I hadn't the time to dig further but I'll today once back at home.
I'll check if other frontends (x11, xv, ...) have the same issue or not and get a debug trace

First, while the bug doesn't happen anymore with oowriter, I've found a new way to reproduce it: start "links -g" (the CLI/GUI navigator), and just type o in order to open a new dialog and voila, screen is garbaged again :-(

As for mplayer, I had the segfault while running it from a older screen session with a different user, it would play a few frames then segfaults when I try to move forward.
I cannot reproduce anymore, either it just segfault after complaining about the bogus x11 cookie or it runs smoothly after running xhost in another termanal.
Anyway the "links -g" issue is more pressing :-(

(In reply to comment #17)

I'm still seeing the problem after upgrading to vanilla xserver-1.9.4. After adding the GPU-copy-pitch patch to that server, KDE works normal again. So for me the patch seems to fix it. Thanks!

I also tried mplayer and had no problems after applying the patch. Both -vo xv and -vo gl worked, including seeking. But my setup is probably not directly comparable to Thierry's.

(In reply to comment #20)
Torsten, could you try installing "links", it's a small package that is provided in most distro (at least in Debian, Fedora, Mandriva), then run "links -g" then type "g" in order to open the "go to URL" dialog ?
Does it result in your screen to be garbaged again?

(In reply to comment #19)
> First, while the bug doesn't happen anymore with oowriter, I've found a new way
> to reproduce it: start "links -g" (the CLI/GUI navigator), and just type o in
> order to open a new dialog and voila, screen is garbaged again :-(

I can't seem to reproduce any problem with links2 -g. Which graphics 'driver' is your links using, and which window/compositing manager(s) are you using when the problem occurs?

I'm using:
- Mandriva Linux 2010.2 with backported xserver-1.9.4 + rebuild drivers
 (from Mandriva Linux Cooker (~~ Fedora Rawhide))
- kernel-2.6.37
- gnome-2.30
- no composite

both links & links-hacked garbage the screen, either when opening a dialog or when opening on the menu bar through F10
links offers x & fb drivers, thus it must be using the x one.
links-hacked offers x dreamcast fb DirectFB drivers. It must uses the x driver I guess.
Note that I must be the last links-hacked users since that fork is unmaintained for years.

For both, using 'Option "ColorTiling" "false"' fixes this bug
Without that, both links & links-hacked garbage the screen like oowriter uses to do, which implies there's maybe another code path that is hitten and shows the same bug as before. Any idea?

Here's the Mandriva spec files:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/links-hacked/current/SPECS/links-hacked.spec?revision=533273&view=markup
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/links/current/SPECS/links.spec?revision=533227&view=markup

I just tested kernel-2.6.38-rc4.
Same garbaged screen.
Same fix with disabling colortiling

Sorry I had downgrading xserver :-(
I confirm that both links & oowriter works fine with xserver-1.9.4+patch on kernel-2.6.38.
Sorry for the alarming noise :-(
/me putting the brown paper bag on my head :-(

Dupe of bug 33497?

I would do the reverse since:
- more people have commented here
- more info was provided here
- screenshots were provided here
- devs provided a fix here

Please try the patch

(In reply to comment #21)

Not sure, if this is still relevant, but links -g works fine for me. (2.6.38-rc4, xserver-1.9.4 with the GPU-copy-pitch-patch, KDE with compositing disabled)

*** Bug 33952 has been marked as a duplicate of this bug. ***

*** Bug 34157 has been marked as a duplicate of this bug. ***

Does the patch is still valid after all the pitch align fixes commits that landed in trunk?

Patch fixes it for me on:
xorg-server 1.9.4 + patch
xf86-video-ati from git master a9a59717d11af37a2dda5555f6a83c5b65449527.

So can the fix be commited into git ?

*** Bug 34452 has been marked as a duplicate of this bug. ***

*** Bug 34441 has been marked as a duplicate of this bug. ***

*** Bug 34521 has been marked as a duplicate of this bug. ***

Finally got around to double-checking that this shouldn't cause regressions elsewhere and submitting the fix to the xorg-devel mailing list for review.

Patch merged

*** Bug 35035 has been marked as a duplicate of this bug. ***

*** Bug 35075 has been marked as a duplicate of this bug. ***

What about also patching -ati to disable Color Tiling by default when xorg-server < 1.9.4.901 (the first official release with the fix)?

This to workaround the issue when using an old xorg-server with newer -ati, e.g. under Ubuntu 10.10 (it has 1.9.0).

Created attachment 53075 [details] [review]
check for xserver 1.9.4.901 to enable tiling by default

How about this?  As Michel suggested, a runtime check would probably be better, but I'm not sure how complicated that would be.

*** Bug 42086 has been marked as a duplicate of this bug. ***

(In reply to comment #42)
> How about this?  As Michel suggested, a runtime check would probably be better,
> but I'm not sure how complicated that would be.

I pushed your patch and a followup patch to turn it into a runtime check.

*** Bug 42058 has been marked as a duplicate of this bug. ***

*** Bug 42056 has been marked as a duplicate of this bug. ***