Please attach your xorg log and config.

Created attachment 18459 [details]
xorg.log

Created attachment 18460 [details]
xorg.conf

this bug is very similar in behaviour to bug 16845
	

similar but not quitte the same. i can see the video, but with odd colors mixed with it, with all players using Xv.. if i use textured video, the video plays without the garbled colors

Does it also happen without Option "BackingStore"?

Created attachment 18462 [details] [review]
Pass base offset into RADEONDisplayVideo() explicitly

Does this patch fix the problem? If not, please attach a log file captured after reproducing the problem with the patch applied.

ok, the patch fixes the bug, changing bug status to fixed.

unfortunatelly with latest git code 6cebfe257f7ddad855ee743e4eb899bd6fac7f46, the bug appears OCASIONALLY with xv, reopening

(In reply to comment #8)
> ok, the patch fixes the bug, changing bug status to fixed.

That should only be done once the fix is applied to Git.


(In reply to comment #9)
> unfortunatelly with latest git code 6cebfe257f7ddad855ee743e4eb899bd6fac7f46,
> the bug appears OCASIONALLY with xv, reopening

With the patch applied on top of that commit?

(In reply to comment #10)
> (In reply to comment #8)
> > ok, the patch fixes the bug, changing bug status to fixed.
> 
> That should only be done once the fix is applied to Git.

Yes, i updated to git and reapplied the patch. I thought the bug was fixed, unfortunately although is happens much less its STILL there.

Alex on IRC said it MIGHT be a memory allocation bug, and i tend to agree, since this bug can be triggered randomly in and out in the same X session .
> 
> 
> (In reply to comment #9)
> > unfortunatelly with latest git code 6cebfe257f7ddad855ee743e4eb899bd6fac7f46,
> > the bug appears OCASIONALLY with xv, reopening
> 
> With the patch applied on top of that commit?

Yes. Sorry for the closing and reopening, i should have done more tests (i should known better :P) before closing this bug.

(In reply to comment #11)
> 
> Alex on IRC said it MIGHT be a memory allocation bug, and i tend to agree,
> since this bug can be triggered randomly in and out in the same X session .

So the suspicion is it's a regression caused by Alex's patch bomb? :) If so, can you try the patch against commit a55e85f742d1334bf88e4681e553f025d2de38df?


Also, I was asking you to provide a log file captured after reproducing the problem with the patch applied.

(In reply to comment #11)
> Alex on IRC said it MIGHT be a memory allocation bug, and i tend to agree,
> since this bug can be triggered randomly in and out in the same X session .

I didn't say it was a memory allocation bug, I said the corruption could be caused by having to reset the overlay base depending on where the allocation was.  That said, it does make sense to rule out my patches.

with latest commit: d0d58b39e49c5ce00bc8bd12f721ad8c7f554b91
i cant reproduce this bug anymore. im not saying im 100% sure its gone, im just saying i cant seem to trigger it.

if no one else complains i think we can close it.

best regards

Is that still with the patch applied? I don't see anything in Git that could address this...

Its without the patch, i think the problem was only active if you enabled the backing store (which leads to a series of other problems) :P

With latest git (d82f2938...) I still see these coloured lines using XAA (EXA is fine). Last time I checked (see bug 16845) the patch here fixed the issue.

(In reply to comment #16)
> Its without the patch, i think the problem was only active if you enabled the
> backing store (which leads to a series of other problems) :P

That's unlikely to be directly related; you probably just got (un)lucky.

Anyway, I've pushed the patch as commit c359c2a31caf9f75b9fc6b6bcbc3e9dc1fe404ba, with the debugging output unconditional for now. Please don't reopen without attaching a log file captured after reproducing the problem with this fix.