Sharing a single wl_display (client) by multiple toolkits

[Pekka Paalanen]

On Mon, 25 Mar 2019 12:49:44 +0100
Jaroslaw Kubik <jarek at froglogic.com> wrote:

> On Monday, 25 March 2019 11:20:16 CET Pekka Paalanen wrote:
> > 
> > Hi,
> > 
> > sharing the connection is indeed possible, though currently not too
> > nice. There are several ways one could go about it in a toolkit. All
> > solutions depend on compositors sending the relevant event for all
> > proxies, there is no way a compositor can or even should differentiate
> > between proxies for the same underlying (global) object. A proxy can
> > only have one owner, so toolkits need to create their own wl_registry
> > and from that create their own proxies if they want to do something on
> > their own. This also puts some implications on protocol extension
> > design, mind.
> > 
> > One idea is arguably a hack: the first word pointed to by a wl_proxy
> > userdata could be a magic value, that allows the toolkit to identify
> > its own userdata.
> > 
> > Another option is for a toolkit to store all potentially confusable
> > userdata (or wl_proxy) pointers in a hash table, and then check the
> > hash table if the userdata of a wl_proxy is known.
> > 
> > I touched the topic in "Multiple input handlers" in
> > https://ppaalanen.blogspot.com/2013/11/sub-surfaces-now.html
> > It highlights another variant of the same problem: input 'enter'
> > events, which carry a wl_surface argument.
> > 
> > One more idea that might be interesting is to use
> > wl_proxy_get_listener() to check that the listener was installed by the
> > toolkit. If it was, then the userdata is owned by the toolkit as well.
> > An advantage of this is that the listener is often a static const, so
> > the overhead of tracking will be insignificant, and the method is
> > reliable unlike the magic value hack. The disadvantage is that it gets
> > more complicated if a toolkit has various listeners per object type.
> > 
> > Toolkits do not need to all agree to use the same method. Toolkits only
> > need to check if the proxy is owned by them. If even one toolkit does
> > not verify the proxy ownership, it cannot be co-used with any other
> > toolkit.
> > 
> > To recap, the problem is this:
> > 
> > - There are two toolkits using the same wl_display.
> > - Each toolkit creates its own wl_registry.
> > - Each toolkit binds its own wl_output globals, creating separate
> >   proxies owned by exactly one toolkit.
> > - When a compositor send wl_surface.enter(wl_output), it will actually
> >   send one 'enter' for every wl_output proxy that exists for the client
> >   and the specific wl_output.
> > - The toolkit who owns the wl_surface, will necessarily receive both
> >   'enter' events, and it needs to decide which one to use and ignore
> >   the rest.
> > 
> > It would be very cool to have this problem handled better by
> > libwayland-client. It might be possible to add more API to set and get
> > some kind of owner ID, e.g. a void*, which would be easy for toolkits
> > to use. However, if someone wants to work on this, I would like to see
> > justification on why using wl_proxy_get_listener() is not practical in
> > a real use case.
> > 
> > 
> > Thanks,
> > pq  
> 
> Hi,
> 
> So if I understood this correctly, each event should be sent multiple times,
> not only for each  receiving proxy, but also once for each instance of the
> argument proxies (within the same client). Is that correct?

Hi Jaroslaw,

yes, for the events where that can actually happen. Currently the known
root cause are globals which can be bound multiple times, producing
several wl_proxies that all refer to the same underlying thing, e.g.
wl_output or wl_seat.

It does not apply when the event argument always refers to a unique
underlying thing, like wl_surface.

> If so, then I
> see two issues with that design:
>  - It does not scale very well. While I cannot think of one, there may be an
> even that carries multiple proxy arguments. Since the server has no way of
> telling which proxies (within the same client) "belong together", it has no
> choice but to send each possible combination of argument proxies. This
> makes the server code unnecessarily complex and may increase the number
> of events sent too high;

Yes, which is why protocol extension designers need to take that into
account and avoid such designs.

>  - There is currently no wl_proxy_get_dispatcher function in the wayland
> client library. The toolkits that use dispatchers rather than listeners cannot
> use the suggested method of discovering "foregin" proxies. From what I
> have seen within the implementation, for now the pointer returned by
> wl_proxy_get_listener should be the same and therefore sufficient for
> comparison, but it is an artifact of current implementation and until it
> is documented cannot be relied upon.

I would welcome a merge request clarifying the documentation, that
wl_proxy_add_dispatcher and wl_proxy_add_listener are mutually
exclusive as they set the same member, and wl_proxy_get_listener
returns that very member. I don't think we could make it any different
anymore.

> The alternative with magic values in user data would require coordination
> of actual format of that data and assignment of magic values. It is unlikely 
> to become a widely accepted practice.

To be reliable, yes.

What is your proposal for a solution?

I do agree that sharing a wl_display is desirable and even necessary.


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/20190326/cc50ba86/attachment.sig>