[PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

[Daniel Stone]

On 28 July 2017 at 16:51, Keith Packard <keithp at keithp.com> wrote:
> Michel Dänzer <michel at 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