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 <[email protected]> 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 <[email protected]> wrote: > >> DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf. >> >> Signed-off-by: Chia-I Wu <[email protected]> >> --- >> .../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 >> >>
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
