Bad caching of the scratch pixmap

[Chris Wilson]

On Sat, Apr 13, 2013 at 10:27:00AM -0400, Daniel Drake wrote:
> Hi,
> 
> At http://dev.laptop.org/ticket/12542 we are seeing a problem where on
> OLPC XO-1.75 and XO-4, after rotating the screen with RandR, pixmaps
> often get drawn badly.
> 
> e.g. launching the following via xinit shows the problem:
> 	#!/bin/bash
> 	xrandr -o left
> 	xrandr -o normal
> 	./pixbuf.py
> 
> where pixbuf.py is a simple pygtk app that draws an image pixbuf on the
> screen. In this case the image does not show, it is either all-black or
> heavily corrupted in some way.
> 
> The hardware here is a vivante GPU embedded into a Marvell ARM SoC.
> The DDX is http://dev.laptop.org/git/projects/xf86-video-dove/
> This calls into a "galcore" GPU driver on the kernel side via libgfx
> http://dev.laptop.org/git/olpc-kernel/tree/drivers/gpu/galcore?h=arm-3.5
> Sadly libgfx is proprietary (grumble) - sorry.
> 
> The DDX implements its own pixmap management (via CreatePixmap2) and RandR
> rotation is done with EXA (we support composite operations including
> a transformation matrix that results in rotation). The CreatePixmap2
> implementation creates some kind of GPU object to track the pixmap.
> 
> Adding this patch solves the issue:
> http://lists.x.org/archives/xorg-devel/2011-June/023004.html
> http://lists.x.org/archives/xorg-devel/2011-June/023008.html
> 
> Does it sound likely that we are hitting the same type of issue
> described there (is there any easy way to verify this)? If so, can we
> move forward with this patch? It looks like it was previously half-acked:
> http://lists.x.org/archives/xorg-devel/2011-June/023014.html

Given the same fix works, it does sound like a very similar issue. The
difference is that the DDX is under control of the creating the scratch
pixmap in your case and should be well aware of the lifetime constraints
and so remember to decouple the GPU object when it destroys the screen
pixmap. So the bug is really in the driver and this just happens to
workaround the bug by forcing the release when as noted in the bug
report, the driver is likely to need to take even more precautions with
an old framebuffer.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre