Bad caching of the scratch pixmap

[Daniel Drake]

On Wed, Apr 17, 2013 at 1:34 AM, Michel Dänzer <michel at daenzer.net> wrote:
> Possibly. E.g. I see that mrvlPrepareAccess() returns TRUE but doesn't
> set pPix->devPrivate.ptr.

Easy enough to add:    pPix->devPrivate.ptr = pPixSurf->pVirtAddr;

However, PrepareAccess() doesn't get called on this pixmap. Lets see why:

When the pixmap was created (in mrvlExaCreatePixmap2), because the BPP
of this pixmap is 1, it apparently cannot be accelerated. So no GPU
object is created, the pixmap memory is allocated using simple
malloc().

Then we reach exaModifyPixmapHeader_driver() which is called after the
pixmap is created. pPixData is NULL, so pExaPixmap->sys_ptr is set as
NULL too.

Later when we try to fill this pixmap (via exaPolyFillRect and so on),
we reach ExaDoPrepareAccess, which does:

    has_gpu_copy = exaPixmapHasGpuCopy(pPixmap);

    if (has_gpu_copy && pExaPixmap->fb_ptr) {
        pPixmap->devPrivate.ptr = pExaPixmap->fb_ptr;
        ret = TRUE;
    }
    else {
        pPixmap->devPrivate.ptr = pExaPixmap->sys_ptr;
        ret = FALSE;
    }

exaPixmapHasGpuCopy() calls into mrvlPixmapIsOffscreen(), which
returns FALSE, indicating that no acceleration is possible with this
pixmap.

So has_gpu_copy is FALSE and we set devPrivate.ptr to
pExaPixmap->sys_ptr, which is NULL.

Then we try to draw with that pointer, oops (the backtrace in the
previous mail shows that pixman is asked to draw to destination
address 0x0).

I cannot see a way to make sys_ptr have a non-NULL value in this case
without having implemented ModifyPixmapHeader.

Daniel