On Fri, 29 Oct 2010 03:49:06 +0100, Peter Clifton <pc...@cam.ac.uk> wrote: > Hi guys, > > Just a heads-up here. I don't use many QT apps, so I don't know when > this first started occurring, but with "late" drivers, (all known drm > kernel fixes merged), I noticed the following corruptions. I'm not sure > who's bug this is.. it could well be a QT problem of course. > > I first noticed it when running mutter / gnome-shell, but last two > screen-shots were made within metacity (without compositing). > > Not really enough for a bugzilla report me thinks (for now at least), > but I thought I'd show people in case it jumped out at anyone.
Looks very much like that on expose the pixmap is drawn to uninitialised, i.e. the background paint went astray. Maybe it was never emitted, it never arrived or the driver screwed up. Please do file a bug, just so that I'm reminded of what to look out for and we can start collecting information on triggers. > I also saw a crash recently watching a flash video where the corruption > (after a DPMS blank I think), looked like a tiling error. (I > _tentatively_ think). I've not been able to reproduce that problem > though, although I do have a GPU error log from when it hung in that > last case. Just the common-or-garden swapbuffers-on-modeset hang. It's a race between userspace doing a wait-on-scanline on the pipe and KMS disabling that pipe. In theory, recent kernels (2.6.36) have extra protection to close one race and to hopefully fixup it up after it occurs. Not a complete solution though. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
