linux-dmabuf and eglBindWaylandDisplayWl

[Scott Anderson]

On 10/04/20 10:34 am, Matt Hoosier wrote:
> On Thu, Apr 9, 2020 at 2:51 PM Simon Ser <contact at emersion.fr 
> <mailto:contact at emersion.fr>> wrote:
> 
>     On Thursday, April 9, 2020 9:41 PM, Matt Hoosier
>     <matt.hoosier at gmail.com <mailto:matt.hoosier at gmail.com>> wrote:
> 
>      > If I remember correctly, I've read various messages on the list
>     here saying that eventually it would be preferred for EGL
>     implementations would just use linux-dmabuf as their buffer factory.
>     That would mean that EGL backends would now also want to register a
>     zwp_linux_dmabuf_v1 global.
> 
>     Mesa already binds to zwp_linux_dmabuf_v1 and uses it if possible.
> 
>      > I'm wondering how the logistics on that would work. Normally, you
>     can't register two globals having the same name in the compositor.
>     Does this lead to a conflict between the EGL implementation's
>     ability to enumerate a linux-dmabuf API for its own use, and the
>     linux-dmabuf API that the overall compositor might offer?
> 
>     Just to be clear: we're talking about the client side right?
> 
>     It's fine to bind twice to the same global. This creates two
>     independent objects.
> 
> 
> No, I mean from the standpoint of a compositor implementer.
> 
> -Matt

Mesa does not implement zwp_linux_dmabuf_v1 on the compositor side. It's 
the compositor's job to do that, and they can use EGL or Vulkan 
extensions [1] to import them for rendering with, or otherwise use them 
with anything capable of consuming dmabufs.

eglBindWaylandDisplayWL still only handles wl_drm.

- Scott

[1]:
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VK_EXT_external_memory_dma_buf