<div><div dir="auto">On Thu, Apr 9, 2020 at 2:51 PM Simon Ser <<a href="mailto:contact@emersion.fr">contact@emersion.fr</a>> wrote:<br></div></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday, April 9, 2020 9:41 PM, Matt Hoosier <<a href="mailto:matt.hoosier@gmail.com" target="_blank">matt.hoosier@gmail.com</a>> wrote:<br>
<br>
> 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.<br>
<br>
Mesa already binds to zwp_linux_dmabuf_v1 and uses it if possible.<br>
<br>
> 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?<br>
<br>
Just to be clear: we're talking about the client side right?<br>
<br>
It's fine to bind twice to the same global. This creates two<br>
independent objects.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div dir="auto"><br></div><div dir="auto">No, I mean from the standpoint of a compositor implementer. </div><div dir="auto"><br></div><div dir="auto">-Matt</div></div></div>