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.hoos...@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
pgpAFs6JyO62A.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
