Created attachment 103033 [details] dmesg I cannot be sure when it started but I started to see graphics corruption on terminal emulator first using non-compositing WM (xfce/xfwm), and when you "print" new content it goes away, or move window ... ("refresh" the screen/area). Now I'm testing it with gnome shell, where I see a lot more issues and they happen more often on different windows (gnome-terminal, nautilus, ...), and after some time whole gnome shell lost all text on it and some other parts of the graphics (this second gnome shell "issue" (not sure is it graphics driver, or gnome-shell) doesn't go away after "refresh", so maybe it is not related or it is different problem)) Other strange thing is that everything "works" fine, no errors, crashes ..., nothing important in log files (from end-user perspective) ... (UPDATE: I was probably wrong, there is something in dmesg! (I think 'epiphany' segfault is nothing related a lot of bugs in webkit ... I can crash it on different computers ... (don't want to link that to hw. issue, I think everything is ok, a lot of other things work fine) Currently using fedora 20 (up-to-date linux 3.15.5, mesa-10.1.5-1.20140607, libdrm-2.4.54-1, xorg-x11-drv-intel from git '923e098' ) on gm45 I'll update this bug report with some screenshots 'later'
Created attachment 103034 [details] xorg log
Created attachment 103035 [details] xfce terminal corruption There are some white rectangles edited on this and next xfce screenshot to "mask" username/s
Created attachment 103036 [details] xfce terminal1
Created attachment 103037 [details] broken gnome-shell (maybe unrelated to this!?)
(In reply to comment #4) > Created attachment 103037 [details] > broken gnome-shell (maybe unrelated to this!?) Gut feeling is that is different since iirc those elements are drawn using cairo into an image buffer.
Created attachment 103038 [details] nautilus Maybe I was wrong about refreshing the image get fixed (or maybe not, not sure), it stays like this even if I move it, swiching workspaces fixes it (maybe different behaviour on compositing and non-compositing WM)
Related gen5? http://www.dodaj.rs/f/2P/tm/3s6ndfLv/2014-08-10-1407703762.png
It is worth checking to see if commit 48a33fc379b17eed195875222ad773c911d9dff1 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Sep 2 19:08:36 2014 +0100 sna/trapezoids: Use the corrected trapezoid origin for aligned boxes The rule for the origin of the CompositeTrapezoids routine is the upper-left corner of the first trapezoid. Care must be taken in case the trapezoid edge is upside down to consider the upper vertex. has any impact here. That's me being optimistic.
Sorry, I cannot test this on original machine anymore. I tested this on different system with gm45 (running KDE (kwin) with compositing), no issues with latest git (including commit 48a33fc379b17eed195875222ad773c911d9dff1 ) You are free to close this bug, I won't be able to respond on it later.
Thanks for the update. If you can track down the other reporter encourage him to reopen this bug, that would be useful. But until we can reproduce this, we will have to let it remain unresolved. Anytime you have an issue, please don't hesitate in filing new bugs - thanks again.
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.