[v3] linux-dmabuf: clarify DRM_FORMAT_MOD_INVALID

Submitted by Chia-I Wu on April 16, 2019, 8:18 p.m.

Details

Message ID 20190416201806.35729-1-olvaffe@gmail.com
State Superseded
Headers show
Series "linux-dmabuf: clarify DRM_FORMAT_MOD_INVALID" ( rev: 3 ) in Wayland

Not browsing as part of any series.

Commit Message

Chia-I Wu April 16, 2019, 8:18 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)

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
---
 .../linux-dmabuf/linux-dmabuf-unstable-v1.xml | 32 ++++++++++++-------
 1 file changed, 21 insertions(+), 11 deletions(-)

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..162ee17 100644
--- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
+++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
@@ -24,10 +24,11 @@ 
     DEALINGS IN THE SOFTWARE.
   </copyright>
 
-  <interface name="zwp_linux_dmabuf_v1" version="3">
+  <interface name="zwp_linux_dmabuf_v1" version="4">
     <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"
@@ -260,11 +269,11 @@ 
         cannot guarantee reasonable image quality in all cases are recommended
         to just reject all interlaced buffers.
 
-        Any argument errors, including non-positive width or height,
-        mismatch between the number of planes and the format, bad
-        format, bad offset or stride, may be indicated by fatal protocol
-        errors: INCOMPLETE, INVALID_FORMAT, INVALID_DIMENSIONS,
-        OUT_OF_BOUNDS.
+        Any argument errors, including non-positive width or height, mismatch
+        between the number of planes and the format, mismatch between the
+        plane modifiers and the format, bad format, bad offset or stride, may
+        be indicated by fatal protocol errors: INCOMPLETE, INVALID_FORMAT,
+        INVALID_DIMENSIONS, OUT_OF_BOUNDS.
 
         Dmabuf import errors in the server that are not obvious client
         bugs are returned via the 'failed' event as non-fatal. This
@@ -321,10 +330,11 @@ 
         by the implementation:
         - the client is terminated with one of the following fatal protocol
           errors:
-          - INCOMPLETE, INVALID_FORMAT, INVALID_DIMENSIONS, OUT_OF_BOUNDS,
-            in case of argument errors such as mismatch between the number
-            of planes and the format, bad format, non-positive width or
-            height, or bad offset or stride.
+          - INCOMPLETE, INVALID_FORMAT, INVALID_DIMENSIONS, OUT_OF_BOUNDS, in
+            case of argument errors such as mismatch between the number of
+            planes and the format, mismatch between the plane modifiers and
+            the format, bad format, non-positive width or height, or bad
+            offset or stride.
           - INVALID_WL_BUFFER, in case the cause for failure is unknown or
             plaform specific.
         - the server creates an invalid wl_buffer, marks it as failed and

Comments

I think it would be good to clarify that the "format" event is not sent
in this version? And maybe make it a protocol error to send a
format/modifier combination that wasn't advertised?

On Wednesday, April 17, 2019 2:05 PM, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> On Wed, 17 Apr 2019 05:45:41 +0000
> Simon Ser contact@emersion.fr wrote:
>
> > I think it would be good to clarify that the "format" event is not sent
> > in this version? And maybe make it a protocol error to send a
> > format/modifier combination that wasn't advertised?
>
> As I explained before, I wouldn't make the protocol error now, it's
> just more hassle. Compositors would still need to support v3 semantics
> when a client binds a v3. A note to fix this for when we break the ABI
> the next time is fine by me.
>
> I think the "format" event is already clear enough.
>
> What would be the benefit of implementing interface v4 across the board?

The guarantee that DRM_FORMAT_MOD_INVALID is sent by Mutter? But this
is arguably a Mutter bug.

> The v3 patch forgets to say the new rules apply to interface v4, which
> makes it look like they are retrofitted to all versions.

Yeah, I was waiting for more feedback before bringing this up. :)