Daniel Stone <[email protected]> writes: > On 28 July 2017 at 16:51, Keith Packard <[email protected]> wrote: >> Michel Dänzer <[email protected]> writes: >>> Declaring where? Once a pixmap is created, it only has a depth, no >>> format, so there's nothing to base on that e.g. CopyArea between two >>> pixmaps of the same depth is undefined. >> >> I think we'd need some extension request which provides the format data >> and other attributes. We can define the transformation of underlying >> data into depth-based pixel data to match core drawing. >> >>> I'm getting less and less convinced that any reference at all to formats >>> in the context of pixmaps in the DRI3 specification is a good idea. >> >> Well, if we want to deal with YUV or compressed data, then we'd better >> find a way to describe the contents of the buffer returned by >> DRI3BufferFromPixmap. >> >> However, it would also be 'nice' if the underlying raw data could be >> accessed over the wire (ala PutImage/GetImage). Perhaps a different >> extension which talks about new formats (including deep color?) and >> provides for Get/Put semantics? > > Yeah. Support for YUV in all its varied and wonderful forms, extended > RGB primaries/encodings (DCI.P3/etc/etc) would sure be nice to have at > some stage, but conflating it with a specific buffer-creation > mechanism seems to be the wrong place to do it. (See, e.g. the HDR > work.) > > I think Michel is right here, and we're best off keeping the DRI3 > extensions as a very pure addition of the buffer storage details > (tiling/compression). How to then interpret the Pixmap that creates > can be a separate extension which deals with colourspaces, in a way > which also works for SHM content, works for NVIDIA, etc.
If we can successfully talk modifiers and the aux planes just using depth and bpp without a fourcc, I agree that this is the right way to go for now. VC4's modifier is fine and well-defined based just on bpp (and this should be the case for VC5 as well).
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
