<div dir="ltr"><div><div>In the prior version, "modifier" events could be used to advertise either formats or modifiers. For example, they could be used to advertise formats that have no modifiers, by setting the modifier_hi/lo to DRM_FORMAT_MOD_INVALID.<br></div></div><div><br></div><div>In this version, "format" events are used to advertise formats and "modifier" events are used to advertise modifiers.</div><div><br></div><div><div><div>The prior patch describes the behavior of weston, and this version describes the behavior of mutter.</div></div></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 10, 2019 at 12:20 AM Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 9 Apr 2019 15:22:13 -0700<br>
Chia-I Wu <<a href="mailto:olvaffe@gmail.com" target="_blank">olvaffe@gmail.com</a>> wrote:<br>
<br>
> Format events are used to return supported formats while modifier<br>
> evetns are used to return supported modifiers for each supported<br>
> format.<br>
> <br>
> For example, if an implementation is based on EGL, it may send one<br>
> format event for each format returned by eglQueryDmaBufFormatsEXT,<br>
> and one modifier event for each modifier returned by<br>
> eglQueryDmaBufModifiersEXT.<br>
<br>
Hi,<br>
<br>
sorry, but I did not understand this rationale at all. Could you<br>
explain it thoroughly, please?<br></blockquote><div>Say a compositor supports a list of formats. For each format, there is a list of supported modifiers. The list of supported modifiers for a format can be empty because, not every implementation supports explicit modifiers.</div><div><br></div><div>Currently, mutter sends a format event for each supported formats. It also sends a modifier event for each supported modifiers of a format. When a format does not support any explicit modifiers, no modifier event is sent for the format.</div><div><br></div><div>On the other hands, weston does not send format events at all. It only sends modifier events. When a format does not support any explicit modifier, weston sends a modifier event with modifier_hi/lo set to DRM_FORMAT_MOD_INVALID.</div><div><br></div><div>Both implementations support formats that have no explicit modifiers. But when it comes to buffer creation, modifier_hi/lo is required again. It is unclear how to create a buffer for such formats.<br></div><div><br></div><div>This patch tries to clarify these issues, leaning toward mutter's behavior.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Thanks,<br>
pq<br>
<br>
> <br>
> Signed-off-by: Chia-I Wu <<a href="mailto:olvaffe@gmail.com" target="_blank">olvaffe@gmail.com</a>><br>
> ---<br>
> .../linux-dmabuf/linux-dmabuf-unstable-v1.xml | 20 +++++++++++++------<br>
> 1 file changed, 14 insertions(+), 6 deletions(-)<br>
> <br>
> diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml<br>
> index 154afe2..736cc2b 100644<br>
> --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml<br>
> +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml<br>
> @@ -24,10 +24,11 @@<br>
> DEALINGS IN THE SOFTWARE.<br>
> </copyright><br>
> <br>
> - <interface name="zwp_linux_dmabuf_v1" version="3"><br>
> + <interface name="zwp_linux_dmabuf_v1" version="4"><br>
> <description summary="factory for creating dmabuf-based wl_buffers"><br>
> Following the interfaces from:<br>
> <a href="https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt" rel="noreferrer" target="_blank">https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt</a><br>
> + <a href="https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt" rel="noreferrer" target="_blank">https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt</a><br>
> and the Linux DRM sub-system's AddFb2 ioctl.<br>
> <br>
> This interface offers ways to create generic dmabuf-based<br>
> @@ -113,10 +114,8 @@<br>
> For the definition of the format codes, see the<br>
> zwp_linux_buffer_params_v1::create request.<br>
> <br>
> - Warning: the 'format' event is likely to be deprecated and replaced<br>
> - with the 'modifier' event introduced in zwp_linux_dmabuf_v1<br>
> - version 3, described below. Please refrain from using the information<br>
> - received from this event.<br>
> + For each buffer format that the server supports, this event must be<br>
> + sent before any 'modifier' event for the same buffer format.<br>
> </description><br>
> <arg name="format" type="uint" summary="DRM_FORMAT code"/><br>
> </event><br>
> @@ -130,7 +129,11 @@<br>
> the client has received all supported format-modifier pairs.<br>
> <br>
> For the definition of the format and modifier codes, see the<br>
> - zwp_linux_buffer_params_v1::create request.<br>
> + zwp_linux_buffer_params_v1::create and zwp_linux_buffer_params_v1::add<br>
> + requests.<br>
> +<br>
> + Note that DRM_FORMAT_MOD_INVALID (that is, modifier_hi == 0x00ffffff<br>
> + and modifier_lo == 0xffffffff) is not a valid modifier in this event.<br>
> </description><br>
> <arg name="format" type="uint" summary="DRM_FORMAT code"/><br>
> <arg name="modifier_hi" type="uint"<br>
> @@ -200,6 +203,11 @@<br>
> This request raises the PLANE_IDX error if plane_idx is too large.<br>
> The error PLANE_SET is raised if attempting to set a plane that<br>
> was already set.<br>
> +<br>
> + Note that DRM_FORMAT_MOD_INVALID (that is, modifier_hi == 0x00ffffff<br>
> + and modifier_lo == 0xffffffff) is always allowed and has a special<br>
> + meaning. It indicates that the modifier is derived from the dmabuf fd<br>
> + rather than explicitly specified.<br>
> </description><br>
> <arg name="fd" type="fd" summary="dmabuf fd"/><br>
> <arg name="plane_idx" type="uint" summary="plane index"/><br>
<br>
</blockquote></div></div>