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

Daniel Stone daniel at fooishbar.org
Fri Jul 28 07:14:45 UTC 2017


Hi Michel,

On 26 July 2017 at 07:21, Michel Dänzer <michel at daenzer.net> wrote:
> On 26/07/17 10:48 AM, Michel Dänzer wrote:
>> On 26/07/17 06:20 AM, Eric Anholt wrote:
>>> Daniel Stone <daniels at collabora.com> writes:
>>>> +   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.
>>>
>>> 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.
>
> This raises a question about multi-plane (e.g. YUV) formats, where
> different planes may have different resolutions. Is this functionality
> intended to be used for such formats? If so, how are X11 drawing
> operations to/from pixmaps created from such formats envisioned to work?

Honestly, I wasn't planning on attacking YUV right now, especially
render-to-YUV. Not least since that brings the complexity of wide vs.
narrow range and selection of primaries into play. I wouldn't expect
any server to advertise that as a supported format; one which would
had better have that figured out ...

Should we perhaps insert text specifically enforcing only RGB formats?

Cheers,
Daniel


More information about the xorg-devel mailing list