Sharing a single wl_display (client) by multiple toolkits

[Scott Anderson]

On 22/03/19 8:37 am, Jaroslaw Kubik wrote:
> Hi,
> 
> Does wayland-client support sharing a single connection object between
> unrelated pieces of code? Such feature could be useful for integrating
> multiple toolkits (ie. showing GTK widget in a Qt application). I am trying
> to get something similar (but less spectacular) done at the moment, and
> I am facing the following issue: When two unrelated pieces of code
> (ie. GTK and Qt) use the same wl_display and both create a proxy to a
> global object (ie. wl_output), then from the server perspective both these
> proxies are indistinguishable. When sending events like wl_surface.enter,
> the server has to pick a single wl_resource as an argument. That  wl_resource
> is bound to a specific wl_output proxy on the client side. If the server
> chooses wrong, then the window created and managed by Qt will receive
> wl_surface.enter event with wl_output proxy instance that belongs to GTK.
> It will attempt to access it's user-data and crash because it's not the data
> it is expecting.
> 
> In the above scenario the server has no way of knowing which of the proxies
> are expected as parameters in any given case. And the client has no way of
> "discovering" equivalent proxies in case it would like to straighten it out.
> This leads me to believe that the design of the wayland protocol makes it
> impossible to share a connection object between unrelated code and that
> use-case is simply not supported.
> 
> Is that correct? Are there any plans to address this?
> 
> Best Regards,
> Jaroslaw Kubik

Hi,

Wayland can handle this perfectly fine. Separate sections of code can 
create their own wl_registries and bind their own wl_globals 
independently of each other, including using different versions of each 
global. The only requirement is that they use the same wl_display 
object, otherwise they will actually be two separate clients to the 
compositor.

For example, the EGL and Vulkan Wayland platform is implemented this 
way, where you give it a reference to your wl_display and wl_surface, 
and it handles setting up and committing the buffer separately from 
anything else.

If some global is bound multiple times, you will receive an event on 
each of them and there won't be any mix up regarding user-data, so you 
don't need to worry about whether the right global gets used.

Scott