[PATCH] linux-dmabuf: clarify DRM_FORMAT_MOD_INVALID

[Chia-I Wu]

Moving the discussion to this patch...

This patch clarifies how implicit modifier can be supported, modelling
after Weston's behavior.  I can see three options

 1. DRM_FORMAT_MOD_INVALID means implicit modifier, and is always allowed
in buffer creation
 2. DRM_FORMAT_MOD_INVALID means implicit modifier, and a modifier event of
the value must be sent to indicate buffer creation with implicit modifier
is allowed
 3. DRM_FORMAT_MOD_INVALID is invalid and there is no implicit modifier
support

This patch picks option 1.

Option 3 makes legacy support impossible, and in turn makes wl_drm
deprecation take longer.

I've been thinking about moving away from implicit modifier as well so
option 2 might be a good compromise.  The protocol is also more consistent
in that one can create a buffer with a format/modifier pair only when the
pair is advertised via the modifier event.

On Tue, Apr 9, 2019 at 3:23 PM Chia-I Wu <olvaffe at gmail.com> wrote:

> Talked with Daniel offline.  I sent a different version to revive the
> format event.
>
> On Mon, Apr 1, 2019 at 10:41 AM Chia-I Wu <olvaffe at gmail.com> wrote:
>
>> DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf.
>>
>> Signed-off-by: Chia-I Wu <olvaffe at gmail.com>
>> ---
>>  .../linux-dmabuf/linux-dmabuf-unstable-v1.xml     | 15 ++++++++++++++-
>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>> b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>> index 154afe2..7c76441 100644
>> --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>> +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>> @@ -28,6 +28,7 @@
>>      <description summary="factory for creating dmabuf-based wl_buffers">
>>        Following the interfaces from:
>>
>> https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
>> +
>> https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt
>>        and the Linux DRM sub-system's AddFb2 ioctl.
>>
>>        This interface offers ways to create generic dmabuf-based
>> @@ -129,8 +130,13 @@
>>          binds to this interface. A roundtrip after binding guarantees
>> that
>>          the client has received all supported format-modifier pairs.
>>
>> +        For each supported format, DRM_FORMAT_MOD_INVALID (that is,
>> +        modifier_hi == 0x00ffffff and modifier_lo == 0xffffffff) is
>> implied
>> +        and may not be sent.
>> +
>>
> For option 2, this can be removed.

>          For the definition of the format and modifier codes, see the
>> -        zwp_linux_buffer_params_v1::create request.
>> +        zwp_linux_buffer_params_v1::create and
>> zwp_linux_buffer_params_v1::add
>> +        requests.
>>        </description>
>>        <arg name="format" type="uint" summary="DRM_FORMAT code"/>
>>        <arg name="modifier_hi" type="uint"
>> @@ -200,6 +206,13 @@
>>          This request raises the PLANE_IDX error if plane_idx is too
>> large.
>>          The error PLANE_SET is raised if attempting to set a plane that
>>          was already set.
>> +
>> +        Note that DRM_FORMAT_MOD_INVALID (that is, modifier_hi ==
>> 0x00ffffff
>> +        and modifier_lo == 0xffffffff) is always allowed and has a
>> special
>> +        meaning. It indicates that the modifier is derived from the
>> dmabuf fd
>> +        rather than explicitly specified. This use is discouraged and
>> may not
>> +        work if the dmabuf is imported to a different device than the
>> device
>> +        that allocated it.
>>
> For option 2, this can be moved to where the modifier event is defined.
The wording needs to be changed.


>        </description>
>>        <arg name="fd" type="fd" summary="dmabuf fd"/>
>>        <arg name="plane_idx" type="uint" summary="plane index"/>
>> --
>> 2.21.0.392.gf8f6787159e-goog
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190412/0d3df62e/attachment.html>