[PATCH 4/4] exa: a few small pitch related changes

[Michel Dänzer]

On Fri, 2009-11-27 at 11:37 +0100, Maarten Maathuis wrote: 
> 2009/11/27 Michel Dänzer <michel at daenzer.net>:
> > 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