linux-dmabuf and eglBindWaylandDisplayWl

Scott Anderson scott at
Thu Apr 9 22:42:28 UTC 2020

On 10/04/20 10:34 am, Matt Hoosier wrote:
> On Thu, Apr 9, 2020 at 2:51 PM Simon Ser <contact at 
> <mailto:contact at>> wrote:
>     On Thursday, April 9, 2020 9:41 PM, Matt Hoosier
>     <matt.hoosier at <mailto:matt.hoosier at>> 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


More information about the wayland-devel mailing list