On 28 July 2017 at 16:51, Keith Packard <kei...@keithp.com> wrote: > Michel Dänzer <mic...@daenzer.net> 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. Cheers, Daniel _______________________________________________ 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