linux-dmabuf and eglBindWaylandDisplayWl

[Pekka Paalanen]

Hi Matt,

you already got the answer, but here are some other details I want to
note explicitly.


On Thu, 9 Apr 2020 14:42:17 -0500
Matt Hoosier <matt.hoosier at gmail.com> wrote:

> Hi,
> 
> Historically, many EGL implementations have registered a private wl_drm
> buffer factory for use internally by the implementation's Wayland backend,
> as part of the setup work done go eglBindWaylandDisplayWl().

Yes, and I think it makes sense to keep on using
eglBindWaylandDisplayWl() in compositors when the EGL implementation
supports it, because it's a sign that the EGL implementation client side
might not support zwp_linux_dmabuf. But, it is also possible to not use
eglBindWaylandDisplayWl() and still have everything working if the
client side does use zwp_linux_dmabuf. E.g. a Vulkan-only compositor
should be possible.

> Separately, compositors have started to implement explicit support for the
> zwp_linux_dmabuf_v1 buffer factory, independent of the GPU backend.
> 
> 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 talk has been about the Wayland client side only.

I suppose it would be nice to have a write-up on what EGL extensions
compositors will use to implement zwp_dmabuf_linux themselves.

> That would mean that EGL backends
> would now also want to register a zwp_linux_dmabuf_v1 global.

That, as said by others, I think is intended to not happen.

> I'm wondering how the logistics on that would work. Normally, you can't
> register two globals having the same name in the compositor.

Technically you can. The usual examples are wl_seat and wl_output
interfaces that can routinely have multiple globals advertised. Nothing
stops you from doing it with other interfaces in your compositor.

It only creates a problem in the clients if the protocol extension
designer did not take this possibility into account and give some
information to let the clients choose the right global to refer to, if
it even matters. Clients that do not expect an interface to have
multiple global instances might just pick the first or last one
advertised. Of course, clients could also malfunction if the code made
bad assumptions.

> 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?

Yes, kind of. If both the compositor and server-side EGL implementation
register zwp_linux_dmabuf global each, you wouldn't really know which
one clients will pick. Both should work, but might work differently.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200422/8d94aecf/attachment.sig>