[v4] linux-dmabuf: clarify DRM_FORMAT_MOD_INVALID

Submitted by Chia-I Wu on April 17, 2019, 4:40 p.m.

Details

Message ID 20190417164019.177074-1-olvaffe@gmail.com
State Accepted
Commit fb9b2a87317c77e26283da5f6c9559d709f6fdcd
Headers show
Series "linux-dmabuf: clarify DRM_FORMAT_MOD_INVALID" ( rev: 4 ) in Wayland

Not browsing as part of any series.

Commit Message

Chia-I Wu April 17, 2019, 4:40 p.m.
DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf.
It provides legacy support and makes it easier to replace wl_drm.

v3: DRM_FORMAT_MOD_INVALID must be advertised to be supported (which
    requires a version bump)
v4: no version bump, but a note for now

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
---
 .../linux-dmabuf/linux-dmabuf-unstable-v1.xml    | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

Patch hide | download patch | download mbox

diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
index 154afe2..b43e81c 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,16 @@ 
         binds to this interface. A roundtrip after binding guarantees that
         the client has received all supported format-modifier pairs.
 
+        For legacy support, DRM_FORMAT_MOD_INVALID (that is, modifier_hi ==
+        0x00ffffff and modifier_lo == 0xffffffff) is allowed in this event.
+        It indicates that the server can support the format with an implicit
+        modifier. When a plane has DRM_FORMAT_MOD_INVALID as its modifier, it
+        is as if no explicit modifier is specified. The effective modifier
+        will be derived from the dmabuf.
+
         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"
@@ -197,6 +206,11 @@ 
         compression, etc. driver-specific modifications to the base format
         defined by the DRM fourcc code.
 
+        Warning: It should be an error if the format/modifier pair was not
+        advertised with the modifier event. This is not enforced yet because
+        some implementations always accept DRM_FORMAT_MOD_INVALID. Also
+        version 2 of this protocol does not have the modifier event.
+
         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.

Comments

I hope this captures the discussion: clarify DRM_FORMAT_MOD_INVALID and a note

On Wed, Apr 17, 2019 at 9:40 AM Chia-I Wu <olvaffe@gmail.com> wrote:
>
> DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf.
> It provides legacy support and makes it easier to replace wl_drm.
>
> v3: DRM_FORMAT_MOD_INVALID must be advertised to be supported (which
>     requires a version bump)
> v4: no version bump, but a note for now
>
> Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> Reviewed-by: Simon Ser <contact@emersion.fr>
> ---
>  .../linux-dmabuf/linux-dmabuf-unstable-v1.xml    | 16 +++++++++++++++-
>  1 file changed, 15 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..b43e81c 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,16 @@
>          binds to this interface. A roundtrip after binding guarantees that
>          the client has received all supported format-modifier pairs.
>
> +        For legacy support, DRM_FORMAT_MOD_INVALID (that is, modifier_hi ==
> +        0x00ffffff and modifier_lo == 0xffffffff) is allowed in this event.
> +        It indicates that the server can support the format with an implicit
> +        modifier. When a plane has DRM_FORMAT_MOD_INVALID as its modifier, it
> +        is as if no explicit modifier is specified. The effective modifier
> +        will be derived from the dmabuf.
> +
>          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"
> @@ -197,6 +206,11 @@
>          compression, etc. driver-specific modifications to the base format
>          defined by the DRM fourcc code.
>
> +        Warning: It should be an error if the format/modifier pair was not
> +        advertised with the modifier event. This is not enforced yet because
> +        some implementations always accept DRM_FORMAT_MOD_INVALID. Also
> +        version 2 of this protocol does not have the modifier event.
> +
>          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.
> --
> 2.21.0.392.gf8f6787159e-goog
>
Hi,

Can you commit this patch for me, if all looks good?

On Wed, Apr 17, 2019 at 9:41 AM Chia-I Wu <olvaffe@gmail.com> wrote:
>
> I hope this captures the discussion: clarify DRM_FORMAT_MOD_INVALID and a note
>
> On Wed, Apr 17, 2019 at 9:40 AM Chia-I Wu <olvaffe@gmail.com> wrote:
> >
> > DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf.
> > It provides legacy support and makes it easier to replace wl_drm.
> >
> > v3: DRM_FORMAT_MOD_INVALID must be advertised to be supported (which
> >     requires a version bump)
> > v4: no version bump, but a note for now
> >
> > Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
> > Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> > Reviewed-by: Simon Ser <contact@emersion.fr>
> > ---
> >  .../linux-dmabuf/linux-dmabuf-unstable-v1.xml    | 16 +++++++++++++++-
> >  1 file changed, 15 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..b43e81c 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,16 @@
> >          binds to this interface. A roundtrip after binding guarantees that
> >          the client has received all supported format-modifier pairs.
> >
> > +        For legacy support, DRM_FORMAT_MOD_INVALID (that is, modifier_hi ==
> > +        0x00ffffff and modifier_lo == 0xffffffff) is allowed in this event.
> > +        It indicates that the server can support the format with an implicit
> > +        modifier. When a plane has DRM_FORMAT_MOD_INVALID as its modifier, it
> > +        is as if no explicit modifier is specified. The effective modifier
> > +        will be derived from the dmabuf.
> > +
> >          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"
> > @@ -197,6 +206,11 @@
> >          compression, etc. driver-specific modifications to the base format
> >          defined by the DRM fourcc code.
> >
> > +        Warning: It should be an error if the format/modifier pair was not
> > +        advertised with the modifier event. This is not enforced yet because
> > +        some implementations always accept DRM_FORMAT_MOD_INVALID. Also
> > +        version 2 of this protocol does not have the modifier event.
> > +
> >          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.
> > --
> > 2.21.0.392.gf8f6787159e-goog
> >

Hi,

On Wed, 1 May 2019 at 09:53, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> On Wed, 24 Apr 2019 10:07:47 -0700 Chia-I Wu <olvaffe@gmail.com> wrote:
> > Can you commit this patch for me, if all looks good?
>
> I was almost already pushing this, but Daniel said he wants to have
> a good look first.

Indeed, I hadn't followed the discussion on the list so I wanted to
pick that up before pushing. I've read through it though and am happy
with it, so I've pushed it with my R-b.

Thanks for the patience!

Cheers,
Daniel
On Thu, May 2, 2019 at 4:36 AM Daniel Stone <daniel@fooishbar.org> wrote:
>
> Hi,
>
> On Wed, 1 May 2019 at 09:53, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > On Wed, 24 Apr 2019 10:07:47 -0700 Chia-I Wu <olvaffe@gmail.com> wrote:
> > > Can you commit this patch for me, if all looks good?
> >
> > I was almost already pushing this, but Daniel said he wants to have
> > a good look first.
>
> Indeed, I hadn't followed the discussion on the list so I wanted to
> pick that up before pushing. I've read through it though and am happy
> with it, so I've pushed it with my R-b.
>
> Thanks for the patience!
Thanks.  I will update Mesa when I get around to it.
>
> Cheers,
> Daniel