On Fri, 2009-11-27 at 11:37 +0100, Maarten Maathuis wrote: > 2009/11/27 Michel Dänzer <[email protected]>: > > On Mon, 2009-11-23 at 22:17 +0100, Maarten Maathuis wrote: > > > >> 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.
Okay thanks, ACK sent. -- 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
