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

[Eric Anholt]

Daniel Stone <daniel at fooishbar.org> writes:

> 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.

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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170803/cad3dab3/attachment.sig>