Created attachment 58357 [details] Screenshot of corruption Various Gnome applications regularly have corrupted graphics. Empathy, Evolution and also Ubuntu Software Center are good examples. This has happened for a long time and also happens with a 3.2 kernel and git drivers (xorg-edgers). I have a Radeon 6850, Intel Core i5. Running Ubuntu 12.04 and it's kernel + xorg-edgers.
Only something being redrawn inside a window is corrupted, so I guess I suspect something EXA-related.
Created attachment 58359 [details] Xorg.0.log
Please attach your dmesg output.
Created attachment 58368 [details] dmesg
(In reply to comment #4) > Created attachment 58368 [details] > dmesg Did you capture this before or after the problem occurred? The EQ overflows in Xorg.0.log indicate the corruption could be due to the GPU locking up repeatedly, but there's no sign of that in dmesg...
That might have been an instance of https://bugs.freedesktop.org/show_bug.cgi?id=45366 But that lockup doesn't happen every time and this happens all the time, on almost every draw operation of some type in these Gnome applications.
So to clarify, no messages of any kind are shown in dmesg och Xorg-log for this graphics corruption.
I have the following in my rc.local: echo profile > /sys/class/drm/card0/device/power_method echo auto > /sys/class/drm/card0/device/power_profile
*** Bug 47573 has been marked as a duplicate of this bug. ***
Has anyone tried if this happens with the upstream 6.14.3 release, or possibly even older releases? If it doesn't, can someone bisect? I haven't seen this on any of my machines.
So if I start a bisect it's xorg-driver-ati I should test?
(In reply to comment #11) > So if I start a bisect it's xorg-driver-ati I should test? Whichever of that or xserver / kernel you can find a good snapshot for. But the X driver seems most likely at this point.
Created attachment 58906 [details] another screenshot
Created attachment 58907 [details] dmesg
Created attachment 58908 [details] Xorg.log
Hi, attached some additional resources because i have those artifacts too. I am using latest 3.3.0 kernel, latest Oneiric + xorg-edgers ppa too (git versions).
It's not ounly in Gnome, but also both KDE, Xfce4, so the name of the topic is wrong. As I wrote in deleted duplication (47573) last stable version of driver works correctly. Also I need to mention that bug not always present, it something like time intervals when it always present and time when it absent at all.
For those using mesa from git or a 3.3 kernel, these might be 2D tiling related. See bug 47765. To check, use mesa 8.0 or older and make sure to remove the ColorTiling2D option from your config if you are using it.
(In reply to comment #18) > For those using mesa from git or a 3.3 kernel, these might be 2D tiling > related. See bug 47765. To check, use mesa 8.0 or older and make sure to > remove the ColorTiling2D option from your config if you are using it. BTW, this is only relevant for the r6xx+ asics, not older asics.
I am using a ATI RV516 [Radeon X1300/X1550 Series] - so the cause must be something else and it does happen with stock oneiric version and edgers driver.
Actually I can reproduce this with Precise vanilla right now, only with Precise + edgers. Also if I have Precise + edgers and downgrade only libcairo I can't reproduce it...
Sorry, meant: Actually I CAN'T reproduce this with Precise vanilla right now, only with Precise + edgers.
(In reply to comment #22) > Actually I CAN'T reproduce this with Precise vanilla right now, only with > Precise + edgers. (In reply to comment #21) > Also if I have Precise + edgers and downgrade only libcairo I can't reproduce > it... This reminded me of bug 43841, which points to bug 43764, where the cairo commit triggering the corruption has been bisected, and there's an indication the problem might have been introduced with xserver 1.11. Can you reproduce the problem if you downgrade only xserver-xorg-video-radeon instead of cairo?
I've seen this once now with Empathy on cairo built from Git, but I haven't been able to reproduce it reliably. We really need help from those of you who can: Does it happen with xf86-video-ati 6.14.3?[0] If not, can you bisect? If yes, does it happen with xserver 1.10.x? If not, can you bisect? [0] Bug 47573 says it doesn't, but it's not clear if that was really (only) due to the X driver or rather due to cairo. Cairo newer than 1.10.x definitely seems needed to trigger the problem, so make sure the apps you're testing are always using that.
I'll look into this tonight! (CET)
> Can you reproduce the problem if you downgrade only xserver-xorg-video-radeon > instead of cairo? Well I can't do that because it depends on the xorg-abi, but I tried with a clean Precise and only upgraded libcairo and that was enough to trigger the problem.
(In reply to comment #26) > Well I can't do that because it depends on the xorg-abi, You could build any snapshot from upstream Git (or even a downstream Git upstream-* branch, via debcheckout xserver-xorg-video-radeon) against the system xserver-xorg-dev. > but I tried with a clean Precise and only upgraded libcairo and that was enough > to trigger the problem. What was the version of the xserver-xorg-video-radeon package installed?
*** Bug 48001 has been marked as a duplicate of this bug. ***
This looks related to bug 38904 and bug 43841.
*** Bug 43841 has been marked as a duplicate of this bug. ***
*** Bug 48002 has been marked as a duplicate of this bug. ***
It happens with 6.14.3, Precise xorg, latest cairo. We should make a matrix. :-) Precise normally has version 6.14.99~git20111219.aacbd629
Why is this marked as Radeon-specific? I have this exact same problem with Nouveau (nVIDIA ION-based system) on Ubuntu 11.10 + X.org Edgers. Also, only text seems to be corrupted, image areas are fine.
(In reply to comment #33) > Why is this marked as Radeon-specific? Because before your comment, all reports we'd seen were about radeon. > I have this exact same problem with Nouveau (nVIDIA ION-based system) on Ubuntu > 11.10 + X.org Edgers. Reassigning to EXA then. Now, can we please either get clarification from Andre on https://bugs.freedesktop.org/show_bug.cgi?id=43764#c2 , or someone else testing against xserver 1.10.x?
*** Bug 38904 has been marked as a duplicate of this bug. ***
(In reply to comment #34) > (In reply to comment #33) > > Why is this marked as Radeon-specific? > > Because before your comment, all reports we'd seen were about radeon. The rendering errors are so obvious I didn't think about that possibility, I'm sorry if I seemed harsh, it wasn't my intention at all. I'm also able to reproduce the corruption on a friend's laptop (Ubuntu 11.10 + X.org Edgers), with a Radeon Xpress 200 (X300 class GPU, system memory, IIRC). Curiously, Firefox (nightly, from the Mozilla Daily PPA), shows absolutely no signs of corruption, no matter what I throw at it (I'm almost certain those builds link Cairo statically, could this be related?). > > > I have this exact same problem with Nouveau (nVIDIA ION-based system) on Ubuntu > > 11.10 + X.org Edgers. > > Reassigning to EXA then. Thanks!
@comment 36: AFAIU, recently mozilla upstream added yet another hack to their local version of cairo, that made it API incompatible with upstream release. Also, as I noted in the Gentoo bug, workaround from bug 43764 ('Option "EXAPixmaps" "false"'), seems to work.
> Also, as I noted in the Gentoo bug, workaround from bug 43764 > ('Option "EXAPixmaps" "false"'), seems to work. Confirmed here, too. But it has at least these unwanted side effects; • -retro fails (is ignored) • emacs flashes on updates • things jump around in gecko browsers
I have the same issues with X.Org X Server 1.10.6 (only xf86-video-ati & xf86-input-evdev was recompiled [without version changes] in comparison to xorg-server 1.11.0). Any suggestions? As a side note: I don't remember that it was any "good" xorg/driver versions, but that issue has happened at first only with cairo built with --enable-xlib-xcb. So I don't know what exactly I should downgrade/bisect.
(In reply to comment #39) > As a side note: I don't remember that it was any "good" xorg/driver versions, > but that issue has happened at first only with cairo built with > --enable-xlib-xcb. So, does it only happen when using Cairo's new XCB backend? > So I don't know what exactly I should downgrade/bisect. Yeah, it's getting rather unlikely that this is a regression. The Cairo changes probably just exposed an existing bug. (In reply to comment #37) > Also, as I noted in the Gentoo bug, workaround from bug 43764 ('Option > "EXAPixmaps" "false"'), seems to work. Unfortunately, that doesn't narrow it down very much at all, as that's a pretty big hammer which prevents using the GPU for most operations. I presume Option "EXANoComposite" works around the problem as well?
> So, does it only happen when using Cairo's new XCB backend? It was before new compositor architecture/cairo commit af9fbd176b145f042408ef5391eef2a51d7531f8 After that corruption happens even with xlib backend.
@comment 40: again, as I said in the Gentoo bug, both x11 and x11-xcb are affected, but on xcb for some reason corruption is a bit less pronounced.
> So, does it only happen when using Cairo's new XCB backend? Originally it did, but then cairo’s xlib backend started showing the bug, too. The commit where that occurred talked about using XRENDER more completely. A test might be to compile cairo with --disable-xlib-xrender. > Yeah, it's getting rather unlikely that this is a regression. The > Cairo changes probably just exposed an existing bug. That seemed to be the diagnosis posted to cairo@ some time ago.
for me cairo 1.12.0 introduced the same rendering issue in gtk2 apps but it broke the fade effect from gdm after login, now being black. xorg-server 1.12.0.901 xf86-video-nouveau 0.0.16_git20120210-1 mesa 8.0.2-1 cairo 1.12.0-1 with xcb enabled
@comment 40 (sorry, missed it the last time): 'Option "EXANoComposite"' seems to work too (at least for the moment)
(In reply to comment #45) > @comment 40 (sorry, missed it the last time): > 'Option "EXANoComposite"' seems to work too (at least for the moment) ...oops, minor correction: while it does seem sufficient for firefox, there's still a slight, but still noticeable, random corruption in the vte-based terminal, I use
Created attachment 59413 [details] [review] EXA: Factor in composite region early on Would this patch happen to help?
For Debian people on amd64, testing the patch in comment#47 can be done using packages available at: http://people.debian.org/~kibi/packages/xorg-47266/ There are checksums there.
(In reply to comment #48) > For Debian people on amd64, testing the patch in comment#47 can be done using > packages available at: > http://people.debian.org/~kibi/packages/xorg-47266/ > > There are checksums there. If they're Ubuntu compatible, I'll give them a spin tomorrow. Thanks a lot!
Beware, last I checked (and if I recall correctly), Ubuntu is mixing 1.11 + 1.12 to get the input part of 1.12 into 1.11 ; so you probably want to be careful and wait for specific packages for Ubuntu.
(In reply to comment #50) > Beware, last I checked (and if I recall correctly), Ubuntu is mixing 1.11 + > 1.12 to get the input part of 1.12 into 1.11 ; so you probably want to be > careful and wait for specific packages for Ubuntu. Ok, will do, thanks for the heads-up.
If it doesn't help, could somebody try capturing a cairo trace demonstrating the problem? I'm still having trouble reproducing it reliably...
(In reply to comment #52) > If it doesn't help, could somebody try capturing a cairo trace demonstrating > the problem? I'm still having trouble reproducing it reliably... I also have trouble reproducing it, sometimes it takes hours of normal usage to happen. The easiest way to reproduce it (for me, at least) is starting a chat in Empathy. Sending a message or clicking somewhere inside the chat window is usually enough to corrupt the text.
(In reply to comment #53) > I also have trouble reproducing it, sometimes it takes hours of normal usage to > happen. For me, this happens 95% of the time when starting Firefox and opening Gmail. I will try the patch today evening (hopefully I can remember).
(In reply to comment #48) > For Debian people on amd64, testing the patch in comment#47 can be done using > packages available at: > http://people.debian.org/~kibi/packages/xorg-47266/ > > There are checksums there. I installed both xserver-common and xserver-xorg-core but problem persists even after restarting Xorg. I'm on Radeon HD 3400, using 'radeon' driver.
For me it happens 100% of the time when starting Iceweasel. I'll try the patched packages tonight if I have the time.
(In reply to comment #53) > The easiest way to reproduce it (for me, at least) is starting a chat in > Empathy. Which chat theme have you selected in Empathy?
(In reply to comment #47) > Created attachment 59413 [details] [review] [review] > EXA: Factor in composite region early on > > Would this patch happen to help? Tested on Arch linux - no improvements. (Radeon HD 5570)
(In reply to comment #57) > (In reply to comment #53) > > The easiest way to reproduce it (for me, at least) is starting a chat in > > Empathy. > > Which chat theme have you selected in Empathy? Sorry, I should have been more explicit, it's the default Ubuntu theme.
Created attachment 59429 [details] cairo trace `cairo-trace firefox` with gmail loading, font corruption was in the mail body. xorg-server-1.12.0 with exa-composite-region.diff xf86-video-ati-6.14.4 libdrm-2.4.33 OpenGL renderer string: Gallium 0.4 on AMD RS780 OpenGL version string: 2.1 Mesa 8.1-devel (git-ead0a89) OpenGL shading language version string: 1.20 cairo latest git (HEAD is now at cc247c3 gl: Remove an unused variable) build with --enable-tee --enable-xlib-xcb
Created attachment 59430 [details] cairo trace This will be more usable, I think.
Created attachment 59431 [details] screenshot of corruption in cairo trace gimp screenshot of firefox.5062.lzma
Created attachment 59434 [details] [review] EXA: Fall back earlier and more thoroughly from exaGlyphs. Does this patch help?
(In reply to comment #59) > Sorry, I should have been more explicit, it's the default Ubuntu theme. Which one is that? I see in the Empathy preferences: 'Blue', 'Classic', 'Clean', 'Simple'.
Created attachment 59435 [details] Xorg.log with segfault Cannot reproduce corruption with the latest patch, but there is often segfaults. Check the bottom of Xorg.2.log in the attached file.
Created attachment 59437 [details] [review] EXA: Fall back earlier and more thoroughly from exaGlyphs. (v2) The previous patch had a crasher bug (not sure why I didn't hit it in my testing...), sorry.
Looks like fixed and no crashes this time.
Packages available at the same place, versioned as 2:1.11.4-1+kibi~59437
(In reply to comment #66) > Created attachment 59437 [details] [review] [review] > EXA: Fall back earlier and more thoroughly from exaGlyphs. (v2) > > The previous patch had a crasher bug (not sure why I didn't hit it in my > testing...), sorry. Thanks, this fixes it for me. Which version of xorg-server is this patch against? I had to apply it by hand as patch failed.
Well, while the patch from comment 66 seems to fix the parts, that 'Option "EXANoComposite"' worked around, that slight corruption that wasn't affected by that option is still present.
Created attachment 59454 [details] screenshot of a garbled GTK+ menu entry Applying the patch in comment 66 against xserver 1.12 leads to even more severe corruption here, permanently losing some text (e.g. in menu entries). See the attached screenshot, where between "Lesezeichen" and Hilfe" there should be an entry called "Extras" instead of the underscore. This is with the nouveau driver.
I spoke too soon, the patch in comment #66 improves things a lot but I'm still getting little bits of corruption in Sylpheed. Before I could reliably trigger the problem just by going to the bbc news web page with Firefox. I've not seen the problem in Firefox since applying the patch.
...well, while the seems to be no corruption in firefox as for gui and most of the sites, I still have a site, where the corruption is quite significant, if you know how to trigger it. Go to http://byuu.org/bsnes/, scroll down to download/documentation links, then simply move the mouse over those links - they immediately become corrupted.
> http://byuu.org/bsnes/, download/documentation links, Those also show corruption w/o the patch but with EXANoComposite
I hit send too soon... The corruption on byuu.org/bsnes only occurs when using the page’s default stylesheet. That css includes: ,----< excerpt from http://byuu.org/style/style-default.css > | a { | color: #000; | text-decoration: none; | } | | a[href] { | color: #00c; | } | | a[href*="://"] { | color: #082; | } | | a[href]:hover { | color: #f00; | text-decoration: underline; | } `---- Turning on underline might be the trigger.
(In reply to comment #69) > Which version of xorg-server is this patch against? 1.12.0 > I had to apply it by hand as patch failed. Yay for pointless code re-indentation... (In reply to comment #46) > there's still a slight, but still noticeable, random corruption in the vte-based > terminal, I use Which terminal is that? Does it use GTK+ version 3 or 2?
BTW, these problems seem mostly triggered by Cairo now extensively using solid pictures instead of 1x1 repeated pictures. If someone wants to work on adding support for solid pictures to the drivers, that should avoid most if not all these problems and as a bonus give better performance.
(In reply to comment #77) > BTW, these problems seem mostly triggered by Cairo now extensively using solid > pictures instead of 1x1 repeated pictures. If someone wants to work on adding > support for solid pictures to the drivers, that should avoid most if not all > these problems and as a bonus give better performance. Am I wrong to assume only the Intel driver supports solid pictures? That would explain why I've never seen this corruption on two of my laptops (i945GME and Ironlake)...
(In reply to comment #78) > (In reply to comment #77) > > BTW, these problems seem mostly triggered by Cairo now extensively using solid > > pictures instead of 1x1 repeated pictures. If someone wants to work on adding > > support for solid pictures to the drivers, that should avoid most if not all > > these problems and as a bonus give better performance. > > Am I wrong to assume only the Intel driver supports solid pictures? That would > explain why I've never seen this corruption on two of my laptops (i945GME and > Ironlake)... I see the same corruption as comment 71 with a GM45. Software is linux 3.3.0, drm 2.4.33, intel 2.18.0, X 1.11.4, cairo 1.12.0.
(In reply to comment #79) > I see the same corruption as comment 71 with a GM45. Software is linux 3.3.0, > drm 2.4.33, intel 2.18.0, X 1.11.4, cairo 1.12.0. So much for my assumption. Maybe I was just lucky. :(
(In reply to comment #80) > (In reply to comment #79) > > I see the same corruption as comment 71 with a GM45. Software is linux 3.3.0, > > drm 2.4.33, intel 2.18.0, X 1.11.4, cairo 1.12.0. > > So much for my assumption. Maybe I was just lucky. :( That was a bug in UXA: commit fde8a010b3d9406c2f65ee99978360a6ca54e006 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Mar 30 12:47:21 2012 +0100 uxa: Remove broken render glyphs-to-dst
(In reply to comment #81) > That was a bug in UXA: > > commit fde8a010b3d9406c2f65ee99978360a6ca54e006 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Fri Mar 30 12:47:21 2012 +0100 > > uxa: Remove broken render glyphs-to-dst I'm using SNA (which rocks, by the way).
(In reply to comment #76) It's gtk+ 3.4.0/vte 0.32.0. The terminal itself is not important - the corruption happens even with vte stub. Just run midnight commander in a dir with a lot of entries or mutt with a large mailbox. If you PageUp/PageDown enough times, sooner or later you'll notice the problem.
...actually, just holding Shift and repeatedly selecting/deselecting text with the mouse is enough to see the problem.
(In reply to comment #68) > Packages available at the same place, versioned as 2:1.11.4-1+kibi~59437 Those packages give me the same issues as Sven Joachim in comment #71 described with Xserver 1.12, It was so bad (gnome terminal showed almost no text at all, it even did not show a window title name in the taskbar) I choose to revert back to the packages from sids repo. I have several boxes with radeon and nouveau drivers I see that corruption thing on all of them, but on the nouveau boxes it is way better. Just to confirm that this issue triggers differently on different hardware / drivers. regards Michael
(In reply to comment #85) > (In reply to comment #68) > > Packages available at the same place, versioned as 2:1.11.4-1+kibi~59437 > > Those packages give me the same issues as Sven Joachim in comment #71 described > with Xserver 1.12, It was so bad (gnome terminal showed almost no text at all, > it even did not show a window title name in the taskbar) I choose to revert > back to the packages from sids repo. Talking about a radeon (HD 5400), amd64 box here, almost forgot to mention. :) > I have several boxes with radeon and nouveau drivers I see that corruption > thing on all of them, but on the nouveau boxes it is way better. Just to > confirm that this issue triggers differently on different hardware / drivers. > > regards > Michael regards Michael
Let's focus on the corruption in this report; the performance problems are due to drivers not accelerating solid pictures, which should probably be addressed in the drivers.
Another oddity, on a system with cairo 1.12.0 when I try to view a powerpoint with Libre Office I can see the slides and edit them Ok, but if I try to view the slideshow (like I was giving the presentation for real) then the screen freezes and becomes unresponsive. If I click the mouse enough times I eventually get the black slide with "click to exit presentation...". It seems Libre Office is behaving as though it is showing the presentation but I can't see it, the screen stays the same as it was before when I was editing the slides. On an otherwise identical system with cairo 1.10.2 Libre Office behaves as expected, I get the slide show. I guess that when Libre Office is giving the presentation it uses a full screen overlay that uses cairo? I don't know if it's the same bug as this or a different bug in cairo 1.12.0 but it may be related.
(In reply to comment #88) > Another oddity, on a system with cairo 1.12.0 when I try to view a powerpoint > with Libre Office I can see the slides and edit them Ok, but if I try to view > the slideshow (like I was giving the presentation for real) then the screen > freezes and becomes unresponsive. That's definitely a separate issue. Not sure yet where the fault lies.
When I tried exa-glyphs-fallback-2.diff (attachment #59437 [details] [review]), amended for master, the font corruption in sm was worse: everything was reduced to one pixel or so tall. (But with correct leading.) I didn't bother trying ff given that. Non-gtk apps continued to work normally.
(In reply to comment #68) > Packages available at the same place, versioned as 2:1.11.4-1+kibi~59437 Here, the font corruptions stopped with these packages.
I posted a patch implementing basic acceleration of solid pictures for R3xx-R7xx at http://lists.x.org/archives/xorg-driver-ati/2012-April/022724.html . Right now, I'm having a hard time reproducing any of the problems described here with that patch, even using an unpatched xserver, but TBH I'm not sure why I can't reproduce some problems with iceweasel that I still could yesterday... Maybe some of you using cards supported by the patch can give it a spin.
(In reply to comment #92) > I posted a patch implementing basic acceleration of solid pictures for > R3xx-R7xx at http://lists.x.org/archives/xorg-driver-ati/2012-April/022724.html > . Right now, I'm having a hard time reproducing any of the problems described > here with that patch, even using an unpatched xserver, but TBH I'm not sure why > I can't reproduce some problems with iceweasel that I still could yesterday... > Maybe some of you using cards supported by the patch can give it a spin. I will try it (sunday, hopefully) on a friend's laptop (Radeon Xpress 200M), if the patch hits xorg-edgers. I've been quite successful reproducing the corruption on that machine while using gnome-terminal.
(In reply to comment #92) > I posted a patch implementing basic acceleration of solid pictures for > R3xx-R7xx at http://lists.x.org/archives/xorg-driver-ati/2012-April/022724.html > . Right now, I'm having a hard time reproducing any of the problems described > here with that patch, even using an unpatched xserver, but TBH I'm not sure why > I can't reproduce some problems with iceweasel that I still could yesterday... > Maybe some of you using cards supported by the patch can give it a spin. What cards are supported by the patch? The patch makes no difference for me. I can't remember exactly what model ATI card I have, (Radeon 6870?) lspci says it's a: VGA compatible controller: ATI Technologies Inc Device 6738 The terminal was unreadable when I first tried to copy and paste that...
(In reply to comment #94) > (In reply to comment #92) > > [...] for R3xx-R7xx [...] > > What cards are supported by the patch? See above. > VGA compatible controller: ATI Technologies Inc Device 6738 That's a Barts (Northern Islands family) card, which is not supported by the patch yet.
(In reply to comment #92) > I posted a patch implementing basic acceleration of solid pictures (...) It seems it fixes corruption in iceweasel for me. Also iceweasel feels a little bit snappier. Tested with patched xserver and RV535 [Radeon X1650 Series]. Patch applied against current xf86-video-ati git master.
(In reply to comment #92) > I posted a patch implementing basic acceleration of solid pictures for > R3xx-R7xx at http://lists.x.org/archives/xorg-driver-ati/2012-April/022724.html > . Right now, I'm having a hard time reproducing any of the problems described > here with that patch But this is a workaround, rather than a fix, right? It needs to be fixed in Cairo/XCB too.
Created attachment 59943 [details] [review] R3xx-r7xx
Created attachment 59944 [details] [review] evergreen-cayman
Created attachment 59945 [details] [review] r1xx
Created attachment 59946 [details] [review] r2xx
Created attachment 59948 [details] Crash fix for attachment 59944 [details] [review] Xorg crashes on cayman with patch from attachment 59944 [details] [review], attached patch fixes that for me. Good news is that i don't get any corruption with patched driver (it was very noticeable in gnome-terminal for me).
With the version of the solid patch sent to the list git-am(1)ed to master as of this afternoon I am unable to evoke any corruption on my RS880 in the usual suspects.
(In reply to comment #83) > (In reply to comment #76) > It's gtk+ 3.4.0/vte 0.32.0. > The terminal itself is not important - the corruption happens even with vte > stub. > > Just run midnight commander in a dir with a lot of entries or mutt with a large > mailbox. If you PageUp/PageDown enough times, sooner or later you'll notice the > problem. FWIW I had the corruptions happening with vte 0.28.2-r202, 0.30.1-r2 and gtk+ 2.24.10-r1, 3.2.4-r1 ~amd64 Gentoo hardened I've updated xf86-video-ati with the basic acceleration of solid pictures R3xx-r7xx patch updating now vte, glib, gtk+ and other parts and will let you know if I still encounter anything of that sorts thanks !
(In reply to comment #99) > Created attachment 59944 [details] [review] [review] > evergreen-cayman This crashes xorg-server for me. I get a black screen and a locked keyboard when the panel loads (I think it's the first thing that uses cairo) :/ (In reply to comment #102) > Created attachment 59948 [details] > Crash fix for attachment 59944 [details] [review] [review] > > Xorg crashes on cayman with patch from attachment 59944 [details] [review] [review], attached patch fixes > that for me. Doesn't fix the crashes for me :(
(In reply to comment #97) > But this is a workaround, rather than a fix, right? Technically yes, but a pretty good one at that. :) > It needs to be fixed in Cairo/XCB too. No, Cairo merely triggers bugs in EXA. Of course it would be great to fix those, if someone can figure out how to do it properly, but accelerating solid pictures in the driver should leave us in at least as good a place as we were in before; probably better, as Cairo 1.12 comes with some other performance improvements, and other toolkits/apps might benefit from this as well. That it happens to avoid the EXA bugs is sort of a nice bonus. :)
Created attachment 59966 [details] [review] evergreen/cayman
(In reply to comment #107) > Created attachment 59966 [details] [review] [review] > evergreen/cayman This also gives me a black screen and a locked keyboard when LXPanel starts
(In reply to comment #108) > This also gives me a black screen and a locked keyboard when LXPanel starts Alex's patches depend on mine, did you apply mine as well? If yes, check the X server's stderr output.
(In reply to comment #109) > Alex's patches depend on mine, [...] Mine being the R3xx-R7xx patch.
Patches from comments 98-101 for xf86-video-ati (on top of the xorg-server patch) seems to fix the corruption on an r200.
(In reply to comment #109) > Alex's patches depend on mine, did you apply mine as well? If yes, check the X > server's stderr output. Thanks, I didn't know that. Applying the patches from comment #92 and comment #107 works. Sadly it doesn't fix the problem with Libre Office Impress
(In reply to comment #112) > Sadly it doesn't fix the problem with Libre Office Impress See comment #89, which I take as meaning the intel driver is affected by that separate problem as well.
ArchLinux now has packages in our testing repo with Xorg-server 1.12.1 with the EXA fallback patch, Intel driver with the single commit fix and all poor mens Ati patches applied. Not sure if attachment 59948 [details] is additionally required.
the patch EXA: Fall back earlier and more thoroughly from exaGlyphs. (v2) applied to xorg-server 1.12 with nouveau made the font corruption worse. now i have missing letters in gnome-terminal. nouveau ddx driver is from git since 20120210
All radeon driver patches are now in xf86-video-ati Git.
(In reply to comment #113) > (In reply to comment #112) > > Sadly it doesn't fix the problem with Libre Office Impress > > See comment #89, which I take as meaning the intel driver is affected by that > separate problem as well. I have the same impress problem with nvidia drivers 295.40 for the record.
(In reply to comment #117) > (In reply to comment #113) > > (In reply to comment #112) > > > Sadly it doesn't fix the problem with Libre Office Impress > > > > See comment #89, which I take as meaning the intel driver is affected by that > > separate problem as well. > > I have the same impress problem with nvidia drivers 295.40 for the record. Did anyone report a separate bug for that? If not, please do!
(In reply to comment #118) > (In reply to comment #117) > > (In reply to comment #113) > > > (In reply to comment #112) > > > > Sadly it doesn't fix the problem with Libre Office Impress > > > > > > See comment #89, which I take as meaning the intel driver is affected by that > > > separate problem as well. > > > > I have the same impress problem with nvidia drivers 295.40 for the record. > > Did anyone report a separate bug for that? If not, please do! As the bug is already existing in debian bug database, I will suggest maintainer to do it and note the bug as forwarded upstream with the proper reference. Thanks for responding.
(In reply to comment #119) > (In reply to comment #118) > > (In reply to comment #117) > > > (In reply to comment #113) > > > > (In reply to comment #112) > > > > > Sadly it doesn't fix the problem with Libre Office Impress > > > > > > > > See comment #89, which I take as meaning the intel driver is affected by that > > > > separate problem as well. > > > > > > I have the same impress problem with nvidia drivers 295.40 for the record. > > > > Did anyone report a separate bug for that? If not, please do! > > As the bug is already existing in debian bug database, I will suggest > maintainer to do it and note the bug as forwarded upstream with the proper > reference. > > Thanks for responding. Just to be 100% sure: you want a bug in cairo or xorg?
> --- Comment #120 from Eric Valette <eric.valette@free.fr> 2012-04-24 08:54:11 PDT --- > Just to be 100% sure: you want a bug in cairo or xorg? > for the nvidia driver? neither.
(In reply to comment #117) > (In reply to comment #113) > > (In reply to comment #112) > > > Sadly it doesn't fix the problem with Libre Office Impress > > > > See comment #89, which I take as meaning the intel driver is affected by that > > separate problem as well. > > I have the same impress problem with nvidia drivers 295.40 for the record. I guess it might be interesting to also try xf86-video-fbdev for this use case and check whether it is affected or not.
(In reply to comment #121) > > --- Comment #120 from Eric Valette <eric.valette@free.fr> 2012-04-24 08:54:11 PDT --- > > Just to be 100% sure: you want a bug in cairo or xorg? > > > for the nvidia driver? neither. I dunno why you say this: the previous version of cairo did not exhibit this bug (at least did not change anything in libreoffice config). If it cannot accelerate (which I can understand) the default fallback should be at least to display something. You have a bug that affect all graphics cards and you assume its in the video driver and not in cairo.
Created bug 49118.
(In reply to comment #123) > display something. You have a bug that affect all graphics cards and you assume > its in the video driver and not in cairo. The *bug* is neither in libcairo nor in any gfx driver, the bug *is* in xorg (see headers of this bugreport and the whole bugreport posts itself). It just happens to be the case, that a new feature in libcairo makes that bug appear and a performance-wise sensible fix in at least the radeon drivers does prevent the bug from facing for now, but the *bug* is still there in xorg. No idea if the same kind of fix would work for nouveau and the others but that fix is just a "workaround" for the issue. That may not be important from a users point of view, but when it comes to assigning bugs and actually fixing code it is imperative to do it at the right place, obviously. What Julien tried to tell you there is this: "Whatever issues the nvidia driver may have, whatever bug in whatever code is visible with the nvidia driver is of no (deeper) interest here". Quite logical, as we can't do anything about it as the driver is closed source and ALWAYS adds an unpredictable element in the whole matter which foss devs try to avoid if possible. And a side note, some foss devs may even be a little bit biased there, as shocking as that might sound. ;) regards Michael
(In reply to comment #125) > (In reply to comment #123) > > display something. You have a bug that affect all graphics cards and you assume > > its in the video driver and not in cairo. ... but the actual fix did fix the openoffice problem even for radeon driver as you can notice in the comment. > > The *bug* is neither in libcairo nor in any gfx driver, the bug *is* in xorg > (see headers of this bugreport and the whole bugreport posts itself). And a side note, some > foss devs may even be a little bit biased there, as shocking as that might > sound. ;) Well I'm used to that including proving people they are wrong even if they feel they know everuthing beter than others ;-) And BTW, people confirm the bad intercation between cairo and impress
BTW see last comment in https://bugs.freedesktop.org/show_bug.cgi?id=49118
(In reply to comment #126) > (In reply to comment #125) > > (In reply to comment #123) > > > display something. You have a bug that affect all graphics cards and you assume > > > its in the video driver and not in cairo. > > ... but the actual fix did fix the openoffice problem even for radeon driver as > you can notice in the comment. > Did NOT fix he openoffice problem even for radeon driver as you can notice in one of the comment
(In reply to comment #126) > > The *bug* is neither in libcairo nor in any gfx driver, the bug *is* in xorg > > (see headers of this bugreport and the whole bugreport posts itself). And a side note, some > > foss devs may even be a little bit biased there, as shocking as that might > > sound. ;) > > > Well I'm used to that including proving people they are wrong even if they feel > they know everuthing beter than others ;-) And BTW, people confirm the bad > intercation between cairo and impress You did not prove anything. It still stands the bug seems to be in xorg and not in any gfx driver or libcairo, for now until proven otherwise. For the bad interaction between libcairo 1.12 and loimpress... I don't see how it is worse from what I experience on one box here with terminals, iceweasel, icedove, irc-client. And at least I read the analysis "Pauli" made in bug 49118 as a confirmation for the current assumption that xorg is at fault and that it may well be the same bug. On top of that in the Debian BTS both bugs (rather a dozen of bugs) are merged, confirming that it may well be the same bug too. (In reply to comment #128) > Did NOT fix he openoffice problem even for radeon driver as > you can notice in one of the comment Then there may be another issue apart from the up to now assumed broken EXA-pixmap-thingy in xorg. Or the workaround-fix in radeon does not work for that kind of usage of libcairo for loimpress. In general quite confusing. Lets hold back our semi-educated assumptions and allegations and let the devs do their work. This issue affects almost every user with recent libcairo on desktops, so the pressure is high enough for the devs already. regards Michael
(In reply to comment #129) > (In reply to comment #126) > You did not prove anything. It still stands the bug seems to be in xorg and not > in any gfx driver or libcairo, for now until proven otherwise. Fair enough. I was just unhappy to see all the debian bugs pointing to this bug that provides fixes for radeon driver and libcairo that do not fix the problem. > For the bad interaction between libcairo 1.12 and loimpress... I don't see how > it is worse from what I experience on one box here with terminals, iceweasel, > icedove, irc-client. And at least I read the analysis "Pauli" made in bug 49118 > as a confirmation for the current assumption that xorg is at fault and that it > may well be the same bug. On top of that in the Debian BTS both bugs (rather a > dozen of bugs) are merged, confirming that it may well be the same bug too. > > (In reply to comment #128) > > Did NOT fix he openoffice problem even for radeon driver as > > you can notice in one of the comment > Then there may be another issue apart from the up to now assumed broken > EXA-pixmap-thingy in xorg. Or the workaround-fix in radeon does not work for > that kind of usage of libcairo for loimpress. In general quite confusing. Lets > hold back our semi-educated assumptions and allegations and let the devs do > their work. This issue affects almost every user with recent libcairo on > desktops, so the pressure is high enough for the devs already. > > regards > Michael
(In reply to comment #129) > (In reply to comment #126) > You did not prove anything. It still stands the bug seems to be in xorg and not > in any gfx driver or libcairo, for now until proven otherwise. Fair enough. I was just unhappy to see all the debian bugs pointing to this bug that provides fixes for radeon driver and work around libcairo that do not fix the problem even for this radeon driver. > For the bad interaction between libcairo 1.12 and loimpress... I don't see how > it is worse from what I experience on one box here with terminals, iceweasel, > icedove, irc-client. I use both and do not experience theses problem with cairo 1.12 for the record... > And at least I read the analysis "Pauli" made in bug 49118 > as a confirmation for the current assumption that xorg is at fault and that it > may well be the same bug. On top of that in the Debian BTS both bugs (rather a > dozen of bugs) are merged, confirming that it may well be the same bug too. This implies that the bug is not in the glx drivers. Sorry but reading the message this was NOT clear at least for me. > This issue affects almost every user with recent libcairo on > desktops, so the pressure is high enough for the devs already. I do not want to make pressure. I just opened a bug for the impress slide show problem as requested because either the bug is in xorg itself and the current fixes proposed in this thread are only work around or the bug is elsewhere.
(In reply to comment #129) > And at least I read the analysis "Pauli" made in bug 49118 as a confirmation > for the current assumption that xorg is at fault To me it rather sounds like it's pointing at Cairo or libreoffice. > and that it may well be the same bug. It can't really be, as the intel and nvidia drivers don't use EXA. > On top of that in the Debian BTS both bugs (rather a > dozen of bugs) are merged, confirming that it may well be the same bug too. They need to be unmerged.
> > On top of that in the Debian BTS both bugs (rather a > > dozen of bugs) are merged, confirming that it may well be the same bug too. > > They need to be unmerged. Thanks. Will pass the message to debian openoffice/cairo maintainer.
Since I'm currently suffering quite badly from this bug on my Debian testing home desktop, I'd be happy to git bisect if someone told me which component to bisect, but is the current thinking that there's a bug in Xorg that has existed for a long time which is only now being exposed thanks to a change in cairo?
(In reply to comment #134) > Since I'm currently suffering quite badly from this bug on my Debian testing > home desktop, If that's using the radeon driver, the 1:6.14.4-2 packages have the workaround. > [...] is the current thinking that there's a bug in Xorg that has existed > for a long time which is only now being exposed thanks to a change in cairo? Yes.
No point in bisecting then! Will update to the "fixed" (well, bug avoiding) driver then. Thanks, Phil
The fix seems stable and solves the problem fully for me. Now I'm hoping that it has solved #45366 also nut I'll have to test a bit more first...
Hmm, sorry if this is unnecessary bug noise but I have the same (or a very similar) problem with screen corruption on my laptop using NVIDIA NVS 3100M, nouveau driver, cairo and mesa from git. There are random menu labels missing, terminal emulators are always corrupted (e.g. mc is unusable). What would be the proper way to report this? Should I reopen this bug or file a new one?
Shouldn't this still be open? If I understand correctly it has only been worked around in the radeon driver, but the root cause hasn't been fixed in xserver / EXA. It's still affecting nouveau users for instance
(In reply to comment #139) > Shouldn't this still be open? If I understand correctly it has only been worked > around in the radeon driver, but the root cause hasn't been fixed in xserver / > EXA. It's still affecting nouveau users for instance right.
On my machine the corruption is present with cairo git HEAD, also with cairo 1.12. There is no corruption with cairo 1.10.2. I guess I will try to bisect then.
OK, I've done the bisection using git bisect (it's great btw) and this is the commit that causes the corruption on my machine: af9fbd176b145f042408ef5391eef2a51d7531f8 Author: Chris Wilson <chris@chris-wilson.co.uk> 2011-07-30 18:28:21 Committer: Chris Wilson <chris@chris-wilson.co.uk> 2011-09-12 09:29:48 Parent: 0540bf384aed344899417d3b0313bd6704679c1c (ps: improve formatting of fallback image comment) Child: 65a954d5bab9ab6fed15bd98b7018aca2fc50107 (test-surfaces: compilation fixes) Branches: master, remotes/origin/master Follows: 1.11.2 Precedes: 1.11.4 Introduce a new compositor architecture
(In reply to comment #142) This has already been noted in bug 43764.
...and on a not quite related note: in cairo 1.12.2 release announcement, there's a note about it having a fix for a LibreOfice problem; perhaps it's the same one, that was mentioned in an earlier comment.
Please excuse a n00b question: Do Gnome 3 shell or Cinnammon menu use Cairo? Both have no menus unless I xrandr to a lower resolution. The same workaround solves corruption issue noted in this thread for me. I am in the process of learning how to apply a patch and will see if the one posted for this issue solves the menu problem as well. Pictures posted here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668828 Is Bug#43764 a duplicate? Thank you.
That bugs criticity just jumped hugely for me, as libcairo 1.10 is no more available in Debian Testing. On my configuration, almost all texts are complettly corrupted for Gtk application (firefoxe, gnometerm, thunderbird, eclipse, etc), making my system mostly unusable. Performance are also awfull, what was not the case with libcairo-1.10. I don't know if the bug is or not in libcairo, but *clearly*, that's something that appeared with libcairo-1.12, as it is the only modification on my system between yesterday and today. I don't use a Radeon card but a nvidia one. System info (pur Debian Sid): * 01:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 9300M GS] (rev a1) * xserver-xorg: 1:7.6+12 * xserver-xorg-core: 2:1.12.1-2 * xserver-xorg-video-nouveau: 1:0.0.16+git20120322+ab7291d-1 * libcairo2:amd64: 1.12.2-1 Hope it helps,
(In reply to comment #146) > That bugs criticity just jumped hugely for me, as libcairo 1.10 is no more > available in Debian Testing. For your downloading pleasure: http://snapshot.debian.org/package/cairo/ KiBi.
(In reply to comment #146) > On my configuration, almost all texts are complettly corrupted for Gtk > application (firefoxe, gnometerm, thunderbird, eclipse, etc), making my system > mostly unusable. Since the bug is in EXA, I suppose that disabling EXA would be a temporary workaround. Is there an option for that (or can xorg provide one)? For the nouveau driver, Option "NoAccel" "true" might be useful (see the nouveau(4) man page). I haven't tried.
(In reply to comment #147) > (In reply to comment #146) > > That bugs criticity just jumped hugely for me, as libcairo 1.10 is no more > > available in Debian Testing. > > For your downloading pleasure: > http://snapshot.debian.org/package/cairo/ Thanks, that helped, and so my system is usable again. I also discovered that libcairo2 1.10 is on squeeze backports.
I have a suspicion that this EXA bug is the same as I reported when testing openchrome driver. http://wiki.openchrome.org/pipermail/openchrome-devel/2011-September/000573.html The issue showed up now again with the current stable openchrome driver when they switched to EXA enabled by default. The v2 patch makes the corruption look different (white box) but does not fix it. NoAccel fixes it.
I'm pleased to report that recent changes to the Nouveau driver (I'm currently running git revision ace77b6) reduce the display corruption with cairo 1.12 to the point where the machine is usable again. However, it is not perfect: there are still some instances of corruption (for instance, large JPEGs are corrupted when downscaled to fit on the screen by Firefox) and the X server has crashed on me several times since I upgraded (seems to be an unrelated problem to do with suspend/resume).
(In reply to comment #151) > I'm pleased to report that recent changes to the Nouveau driver (I'm currently > running git revision ace77b6) reduce the display corruption with cairo 1.12 to > the point where the machine is usable again. However, it is not perfect: there > are still some instances of corruption (for instance, large JPEGs are corrupted > when downscaled to fit on the screen by Firefox) and the X server has crashed > on me several times since I upgraded (seems to be an unrelated problem to do > with suspend/resume). I too have this bug. I hope it is being fixed. Fresh install of 64 bit Debian 7.0, KDE 4.8.3 version. For me, text corruption is worst - by far - when using Iceweasel 10.0.5 on the gmail site. Text corrupts badly every few seconds. LibreOffice Writer 3.5.4.2 also has frequent problems. Chromium 18.0.1025.151 works on gmail with only a few corruptions. I turned off Desktop Effects, but that made no difference. Nvidia GT 430 card, but not using the Nvida closed driver. Other hardware: Dell Inspiron 530 Intel Core2 Quad processor Q8200 Yorkfield Socket LGA775 North Bridge – Intel G33 South Bridge – ICH9 8 GB RAM Mainboard: Foxcon DG33M03 Monitor: Samsung SyncMaster 2443bwx 1920x1200
I have also corruption with large jpegs wih current radeon on r280, sometimes it laeds to logouting when page is opened with large jpegs in iceweasel(in Xorg.0.log just says eq overflowing), pages for example: http://vincentsanders.blogspot.com/2012/07/travels-with-mr-brown.html
(In reply to comment #153) > I have also corruption with large jpegs wih current radeon on r280, sometimes > it laeds to logouting when page is opened with large jpegs in iceweasel(in > Xorg.0.log just says eq overflowing), pages for example: That doesn't sound like this bug but maybe e.g. bug 44099.
This has also been seen with xf86-video-geode (uses EXA) on OLPC XO-1. I'd be happy to test patches or provide info needed to help with the X problem being exposed. (Also hopeful we might see an accelerated solid picture path being added to geode soon, but that is uncertain.) Michel, you seem to be the person who edged closest to fixing the X issue; is there anything I can do to help?
(In reply to comment #155) > Michel, you seem to be the person who edged closest to fixing the X issue; is > there anything I can do to help? I haven't actively worked on this in almost half a year, and I hardly remember details of my investigations beyond what's recorded here. I'm not sure how useful it would be to fix the EXA bug without accelerating solid pictures anyway, as apps triggering the bug would probably be very slow.
Comment on attachment 59437 [details] [review] EXA: Fall back earlier and more thoroughly from exaGlyphs. (v2) Those of you who are still hitting this, please test the patch from bug 55723.
Tried the patch on xserver 1.13... seems to have fixed all corruption for me. Everything else seems to be working fine too.
I also tried the patch on xserver 1.13 and it fixed the graphic corruption problems I was having in Firefox. I appear to still have some graphic corruption problems in LibreOffice, though, but I lack the knowledge to check whether it is due to EXA, Cairo, or LibreOffice itself. In general, as the text is redrawn, it whites out until one clicks somewhere on the page and most of the text becomes visible once again. I recompiled the X server without the patch just to make sure that this wasn't a regression introduced by the patch, and I verified that the bug was present before I applied the patch. One way or another, this patch seems to make the situation better. I am also unable to find any notable regressions introduced by it. For the record I have an Nvidia GTX 560 and am using Nouveau as the driver.
Created attachment 69139 [details] [review] Backported to xserver-1.13.0 The patch wouldn't apply for me, so I reapplied it by hand to xserver-1.13.0, here it is. Now, testing on OLPC XO-1.5 using the chrome video driver, I no longer see any text corruption in the GNOME fallback applications menu. However, the textual parts of some of the menu items are not appearing.
*** Bug 55723 has been marked as a duplicate of this bug. ***
commit 1ca096d5e07221025c4c4110528772b7d94f15ee Author: Michel Dänzer <michel.daenzer@amd.com> Date: Mon Oct 29 12:57:54 2012 +0100 EXA: Track source/mask pixmaps more explicitly for Composite fallback regions.
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.