On 10/04/20 10:34 am, Matt Hoosier wrote:
On Thu, Apr 9, 2020 at 2:51 PM Simon Ser <cont...@emersion.fr
<mailto:cont...@emersion.fr>> wrote:
On Thursday, April 9, 2020 9:41 PM, Matt Hoosier
<matt.hoos...@gmail.com <mailto:matt.hoos...@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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
