[PATCH xserver 2/3] glamor: Accelerate up XY pixmap putimage a little

[Keith Packard]

Adam Jackson <ajax at redhat.com> writes:

> On Fri, 2016-09-30 at 22:44 -0700, Keith Packard wrote:
>
>> +    /* copy mode for the first plane to clear all of the other bits */
>> +    gcv[0].val = GXcopy;
>> +    gcv[1].val = gc->fgPixel;
>> +    gcv[2].val = gc->bgPixel;
>> +    ChangeGC(NullClient, temp_gc, GCFunction|GCForeground|GCBackground, gcv);
>
> You don't need to set GCFunction here, the scratch gc already has
> GXcopy set.
>
> You _do_ need to copy GCPlanemask from the source gc, because for
> XYPixmap PutImage that determines how many planes of data were given;
> if you let it stay as FB_ALLONES when it should only be, say, 0x3,
> you'll read in 30 planes of garbage.

That's true for GetImage, but the protocol doc is rather unclear about
PutImage. The only mention of 'plane-mask' in the PutImage spec is as a
relevant component in the GC. Xlib doesn't look at the plane mask; the
request length is computed with:

    bytes_per_dest = (unsigned long)ROUNDUP((long)req->width + req->leftPad,
					    dpy->bitmap_pad) >> 3;
    bytes_per_dest_plane = bytes_per_dest * req->height;
    length = bytes_per_dest_plane * image->depth;
    req->length += (length + 3) >> 2;

Looks like fb has a bug.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20161003/d6495b8b/attachment.sig>