<div><div dir="auto">+ list</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 9, 2020 at 5:48 PM Matt Hoosier <<a href="mailto:matt.hoosier@gmail.com">matt.hoosier@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Thu, Apr 9, 2020 at 5:42 PM Scott Anderson <<a href="mailto:scott@anderso.nz" target="_blank">scott@anderso.nz</a>> wrote:<br></div><div><div class="gmail_quote"></div></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/04/20 10:34 am, Matt Hoosier wrote:<br>
> On Thu, Apr 9, 2020 at 2:51 PM Simon Ser <<a href="mailto:contact@emersion.fr" target="_blank">contact@emersion.fr</a> <br>
> <mailto:<a href="mailto:contact@emersion.fr" target="_blank">contact@emersion.fr</a>>> wrote:<br>
> <br>
>     On Thursday, April 9, 2020 9:41 PM, Matt Hoosier<br>
>     <<a href="mailto:matt.hoosier@gmail.com" target="_blank">matt.hoosier@gmail.com</a> <mailto:<a href="mailto:matt.hoosier@gmail.com" target="_blank">matt.hoosier@gmail.com</a>>> wrote:<br>
> <br>
>      > If I remember correctly, I've read various messages on the list<br>
>     here saying that eventually it would be preferred for EGL<br>
>     implementations would just use linux-dmabuf as their buffer factory.<br>
>     That would mean that EGL backends would now also want to register a<br>
>     zwp_linux_dmabuf_v1 global.<br>
> <br>
>     Mesa already binds to zwp_linux_dmabuf_v1 and uses it if possible.<br>
> <br>
>      > I'm wondering how the logistics on that would work. Normally, you<br>
>     can't register two globals having the same name in the compositor.<br>
>     Does this lead to a conflict between the EGL implementation's<br>
>     ability to enumerate a linux-dmabuf API for its own use, and the<br>
>     linux-dmabuf API that the overall compositor might offer?<br>
> <br>
>     Just to be clear: we're talking about the client side right?<br>
> <br>
>     It's fine to bind twice to the same global. This creates two<br>
>     independent objects.<br>
> <br>
> <br>
> No, I mean from the standpoint of a compositor implementer.<br>
> <br>
> -Matt<br>
<br>
Mesa does not implement zwp_linux_dmabuf_v1 on the compositor side. It's <br>
the compositor's job to do that, and they can use EGL or Vulkan <br>
extensions [1] to import them for rendering with, or otherwise use them <br>
with anything capable of consuming dmabufs.<br>
<br>
eglBindWaylandDisplayWL still only handles wl_drm.<br>
<br>
- Scott<br>
<br>
[1]:<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/vulkan/specs/1.2-extensions/html/vkspec.html#VK_EXT_external_memory_dma_buf" rel="noreferrer" target="_blank">https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VK_EXT_external_memory_dma_buf</a></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div dir="auto"><br></div></div></div><div><div class="gmail_quote"><div dir="auto">Okay, interesting that Mesa’s client will use Linux-dmabuf if the compositor happens to provide it, but the server-side EGL of Mesa offers wl_drm as a fallback.</div><div dir="auto"><br></div><div dir="auto">As a compositor author, do I have to account for the possibility that the EGL implementation may provide (squat on) the “zwp_linux_linux_dmabuf_v1” buffer factory itself, it is that strictly the prerogative of the individual compositor?</div></div></div>
</blockquote></div></div>