Michel Dänzer <mic...@daenzer.net> writes: > [ Unknown signature status ] > On 26/07/17 06:20 AM, Eric Anholt wrote: >> Daniel Stone <dani...@collabora.com> writes: >> >>> DRI3 version 1.1 adds support for explicit format modifiers, including >>> multi-planar buffers. >> >> I still want proper 64-bit values, and I don't think the little XSync >> mess will be much of a blocker. >> >>> Signed-off-by: Daniel Stone <dani...@collabora.com> > > [...] > >>> + combined to specify a single logical source for pixel >>> + sampling: 'num_buffers' may be set from 1 (single buffer, >>> + akin to PixmapFromBuffer) to 4. This is the number of file >>> + descriptors which will be sent with this request; one per >>> + buffer. >>> + >>> + The exact configuration of the buffer is specified by 'format', >>> + a DRM FourCC format token as defined in that project's >>> + drm_fourcc.h header, in combination with the modifier. >>> + >>> + Modifiers allow explicit specification of non-linear sources, >>> + such as tiled or compressed buffers. 'modifier_hi' (the most >>> + significant 32 bits of a 64-bit value) and 'modifier_lo' are >>> + combined to produce a single DRM format modifier token, again >>> + as defined in drm_fourcc.h. The combination of format and >>> + modifier allows unambiguous declaration of the buffer layout >>> + in a manner defined by the DRM tokens. >>> + >>> + DRM_FORMAT_MOD_INVALID may be passed for 'modifier', in which >>> + case the driver may make its own inference as to the exact >>> + layout of the buffer(s). >>> + >>> + 'width' and 'height' describe the geometry (in pixels) of the >>> + logical pixel-sample source. >>> + >>> + 'strideN' and 'offsetN' define the number of bytes per logical >>> + scanline, and the distance in bytes from the beginning of the >>> + buffer passed for that plane until the start of the sample >>> + source for that plane, respectively for plane N. If the plane >>> + is not used according to the format and modifier specification, >>> + both values for that plane must be zero. >>> + >>> + Precisely how any additional information about the buffer is >>> + shared is outside the scope of this extension. >>> + >>> + If the buffer(s) cannot be used with the screen associated with >>> + 'pixmap', a Match error is returned. >>> + >>> + If the format and modifier combination is not supported by the >>> + screen, a Value error is returned. >> >> Should we be specifying how the depth of the Pixmap is determined from >> the fourcc? Should we be specifying if X11 rendering works on various >> fourccs, and between pixmaps of different fourccs? It's not clear to me >> what glamor would need to be able to do with these pixmaps (can I >> CopyArea between XRGB888 and BGRX8888? What does that even mean?) > > X11 pixmaps provide storage for n bits per pixel, where n is the pixmap > depth. CopyArea between pixmaps just copies the bits in the source to > the destination verbatim. Note that this is only possible if both > pixmaps have the same depth.
Right. So is the plan that XRGB888 to BGRX8888 (both depth 24) will actually shift around the bits during the copy?
signature.asc
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
