2009/11/27 Michel Dänzer <[email protected]>: > On Mon, 2009-11-23 at 22:17 +0100, Maarten Maathuis wrote: >> - Setting pitch before exaCopyDirty* is not needed. > > Hmm, I thought it was at least at some point, that's why I added > those... But your patch seems to work fine for me with mixed pixmaps, so > the parts specific to those seem fine. > > >> diff --git a/exa/exa.c b/exa/exa.c >> index 023288c..16f39f6 100644 >> --- a/exa/exa.c >> +++ b/exa/exa.c >> @@ -323,10 +323,17 @@ ExaDoPrepareAccess(PixmapPtr pPixmap, int index) >> >> has_gpu_copy = exaPixmapHasGpuCopy(pPixmap); >> >> - if (has_gpu_copy && pExaPixmap->fb_ptr) >> + if (has_gpu_copy) { >> + /* This can be NULL, but the driver prepareAccess call should >> + * take care of that. */ >> pPixmap->devPrivate.ptr = pExaPixmap->fb_ptr; >> - else >> + pPixmap->devKind = pExaPixmap->fb_pitch; >> + } else { >> + /* For mixed pixmaps this can be NULL, but that will be fixed >> + * later in exaPrepareAccessReg_mixed(). */ >> pPixmap->devPrivate.ptr = pExaPixmap->sys_ptr; >> + pPixmap->devKind = pExaPixmap->sys_pitch; >> + } > > However, I'm a little concerned about this part, as it also affects the > other schemes. E.g. a classic driver may not have a PrepareAccess hook > at all.
I said *may* be NULL, a gpu pixmap in a classic driver should always have a valid fb_ptr without a prepare access hook. In the past this wasn't the case for the frontbuffer and scratch pixmaps but this was fixed several months ago iirc. It's the driver pixmaps which may not have a fb_ptr, but they ofocurce have a prepare access hook. > > > -- > Earthling Michel Dänzer | http://www.vmware.com > Libre software enthusiast | Debian, X and DRI developer > _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
