I have these problems with Cape Verde Pro (HD 7750) card: 1. Graphics corruption when scrolling in gtk2/gtk3 apps (screenshot [1]) 2. Graphics corruption when moving windows in wm whithout compositing. Both gtk and qt apps are affected. No such artifacts when compositing enabled, e.g. in gnome 3. (screenshot [2]) 3. Missing notification icons of gtk2 apps in awesome wm. All of this things works great whithout glamor. Also no such problems with HD 6450 card with both EXA and glamor acceleration. Software: - mesa-9.2 from git - llvm-3.{3,4} from git - xorg-server-1.13.4, also tried 1.12* - xf86-video-ati-7.1.0 - glamor-0.5 - linux kernel 3.8* including latest 3.8.13 Also note, that with mesa-9.0* and mesa-9.1* Xorg segfaults at startup on this system when glamor enabled, but this is a subject for another bug report.
Created attachment 79494 [details] screenshot [1]
Created attachment 79495 [details] screenshot [2]
Created attachment 79496 [details] Xorg log
This graphics artifacts are persist until the window is redrawn.
Created attachment 79497 [details] Screenshot of notification area No claws-mail and gajim icons here.
> - glamor-0.5 Does current glamor Git work better? There have been some fixes which might be relevant.
(In reply to comment #6) Yes, glamor Git works good. But icons in notification area still missing.
(In reply to comment #7) > Yes, glamor Git works good. But icons in notification area still missing. I take it that's not the case with the 6450 card either?
(In reply to comment #8) It's also the case with the 6450 card. Furthermore with 6450 and vanilla glamor-0.5 I see the same graphics artifacts, so sorry for disinformation in comment 0.
Then it sounds like it's most likely a glamor issue. Might be interesting if someone could test this on an Intel GPU.
I too have notification icons missing. I use Xfce 4.10 on Debian 64-bit, xf86-ati, mesa, libdrm, glamor, kernel from git. Hardware: A8-5500 APU with Radeon 7560D IGP (ARUBA) If i use glamor i have certain notification area icons missing. What is missing: notification icons for Gigolo, virt-manager, Linphone, xfce4-notes and every icon put there by alltray. What is there (from what i use): notifications icons for Remmina, Skype, Jitsi (java), Audacious, Vlc The icons are just transparent, otherwise they take up space and can be interacted with. Other issues from what i have seen so far are the Libreoffice menu highlighted text color which is white instead of black. Interesting is that if i enable the xfce's own software compositing most of the iccons appear, except the alltrayed ones. But this introduces tearing especially when i drag windows around.
Nothing of the symptons could be reproduced with the latest glamor on Intel platform. Could you also update to latest glamor and try again?
(In reply to comment #12) > Nothing of the symptons could be reproduced with the latest glamor on Intel > platform. Could you also update to latest glamor and try again? I am on the latest glamor, mesa, xf86-ati built from git a few hours ago, kernel 3.12 rc6+ from git built a few days ago, A8-5500 APU (Radeon 7560D IGP). I still dont have certain icons in the tray on Xfce 4.10. If i use compositing (either the built in one or compton) i get most of them back except the icons that are put there by alltray which still show blank. EXA shows all icons. Icons put by Wine, Qt apps, Java, Gtk3 apps seem to work. But Gtk2 seem to be missing. For example the system default virt-manager compiled with gtk2 has transparent icon while a newer virt-manager that uses gtk3 has visible icon.
This issue is still standing with 64 bit kernel (now around 3.13 rc1), latest glamor, mesa, drm, llvm, xf86-ati from git on ARUBA (7560D) card on Xfce when desktop compositing is off. No GTK2 icons (neither 64 bit nor 32 bit apps can have icons there, for example Steam too has it missing). If its on, all icons show up except the ones created by alltray (kdocker's work though). When starting an app that has icon, the space is taken for a fraction of a second by some garbled pixels (sometimes other icons entirely with wrong colors or just garbled pixels). This lasts for a fraction of a second and then the space becomes transparent.
I started looking into this a little bit and may have found something interesting. When invoking glamor_set_composite_op in glamor_render.c, with op == 3, if one returns GL_FALSE, the notification icons appear. So having something like static Bool glamor_set_composite_op(ScreenPtr screen, CARD8 op, struct blendinfo *op_info_result, PicturePtr dest, PicturePtr mask) { GLenum source_blend, dest_blend; struct blendinfo *op_info; if (op == 3) { return GL_FALSE; } at the start of the function. This isn't the correct fix but could lead to the cause of the issue, I checked over op 3 and it appears to stand for PictOpOver. I'll work on comparing the code with what xf86-video-ati does to see if there is a discrepancy. I get the odd feeling the issue maybe with the destination picture format because op 3 works in other places, just not with the notification icons.
Created attachment 90591 [details] [review] fix for the issue with tray icons not appearing
I've attached a patch for anyone to try to see if it fixes the issue for them (it did for me). There were actually two issues with the original code I believe, the first is that the call to glamor_convert_gradient_picture wasn't properly referencing the coordinates of the source/mask pictures. The second, was that the updated references (x_temp/y_temp) were also improperly set, they should always be 0 because the temp pictures are new ones that start at (0, 0). The reason it worked in certain cases and it didn't in others (notably the tray icons) was due to the numbers working out based on the call to glamor_composite. In the cases that it did work extent->x1 would equal x_dest and extent->y1 would equal y_dest, making it so what was actually passed into glamor_convert_gradient_picture and the settings for x_temp/y_temp were correct. However, for the case when extent->x1 wouldn't equal x_dest and extent->y1 wouldn't equal y_dest (for example with the tray icons) then the wrong parameters get passed into glamor_convert_gradient_picture and x_temp/y_temp are set improperly.
I'm using xfce4 on an E2-1800 APU (HD7340 IGP). The patch fixed tray icon issues, LibreOffice menu highlights, as well as rdesktop screen update for me. I have not seen any undesirable side-effects. Please consider applying the patch to trunk.
I think I submitted it correctly to glamor@lists.freedesktop.org as seen at http://lists.freedesktop.org/archives/glamor/2014-January/000530.html
I just tried recent glamor git and it fixed the issue with notification icons. Thank you, Anthony!
I tried glamor git today (2ac2fc) and the issue does not appear to be fixed for me. I use Fedora Rawhide + GNOME 3, and the steam icon still becomes transparent very often. If I need to trigger it, usually it's sufficient to left-click on it, cancel the menu, and look again into the systray. Radeon R9 270.
Kamil, this looks like a common problem with gtk2 apps in gnome shell. It's unrelated to this bug.
Alexander, you might be right, I've booted with 'nomodeset' boot option and the problem persists even with the llvmpipe driver. I assume that confirms your assertion. It that case it's a recent regression in gnome-shell, I've never seen it on Fedora 20.
(In reply to comment #23) > It that case it's a recent regression in gnome-shell, I've > never seen it on Fedora 20. Currently I have this issue in gnome 3.8 with gajim and claws-mail. Icons are either cropped or completely invisible. For example, Claws Mail bug: http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2499
I can confirm that this issue is resolved with r600g - Radeon HD 8570D on xfce 4 using glamor compiled from git today.
And it seems it fixed the Libreoffice menu highlight issue too.
Fixed with http://cgit.freedesktop.org/xorg/driver/glamor/commit/?id=580aa0524a99ce80d3f556de4aa1a10b1f7f8de4
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.