11:12 <kekekeks> Hi. Quick question: do I understand correctly that each wl_display::get_registry establishes an "id namespace" of sorts, so if one creates a wl_surface using wl_compositor from one instance of registry, then when getting events it will always receive global object ids from the same registry?

11:14 <kekekeks> i. e. if one writes a toolkit-agnostic lib and asks for wl_display, can it be assumed that it's lib's sole responsibility to manage wl_proxy lifetimes for objects created using its own wl_registry and the main toolkit will never see the same set of wl_proxy objects unless those were explicitly transferred?

11:18 <vyivel> kekekeks: global object ids are shared, you'll get the same ones with each registry

11:19 <vyivel> well, not "shared", each global just has one id not tied to any registry

11:19 <kekekeks> So, how does libwayland-client determines which wl_proxy to use when an event arrives?

11:20 <kekekeks> Consider the following scenario:

11:21 <kekekeks> - A library gets loaded into a GTK-application that has bound its own listerner to global wl_output objects

11:21 <kekekeks> - The library gets the registry and gets an id of a wl_output

11:21 <kekekeks> - The library calls wl_output_add_listener

11:22 <vyivel> a proxy is mirrored by a resource on the server side

11:22 <vyivel> the compositor will send events to each resource

11:22 <kekekeks> What will arrive as an argument to wl_surface::enter event?

11:23 <vyivel> one wl_surface.enter for each resource iirc

11:23 <vyivel> yes

11:24 <kekekeks> So wl_surface would see multiple wl_output objects that represent the same output object, right?

11:24 <vyivel> correct

11:28 <kekekeks> So it's not safe to make _any_ kind of assumtions about the `data` argument, right?

11:29 <kekekeks> Correction: about wl_proxy_get_user_data return value for event arguments

11:30 <kekekeks> Since it's not known who is the owner of wl_proxy

11:32 <vyivel> https://lists.freedesktop.org/archives/wayland-devel/2019-March/040344.html

11:33 <kekekeks> Mkay, so connection sharing isn't really supported

11:33 <kekekeks> Since e. g. GTK relies on set_user_data for global objects right now

11:35 <vyivel> you can store user data externally in a hashmap or smth

11:35 <kekekeks> _I_ certainly can

11:36 <vyivel> there's also wl_proxy_set_tag() which i just remembered about

11:36 <vyivel> so you can tag a proxy and then check if it belongs to you or some other part of the program

11:39 <kekekeks> How new_id identifiers are handled if there are multiple proxies?

11:40 <kekekeks> E. g. if one binds to zwp_tablet_manager_v2's events and receives tablet_added event

11:41 <kekekeks> Will each proxy bound to zwp_tablet_manager_v2 receive its own zwp_tablet_v2 identifier?

11:41 <vyivel> yes

11:42 <vyivel> you write a small program that does something like that and check events with WAYLAND_DEBUG

11:42 <kekekeks> So what GTK does here (https://github.com/GNOME/gtk/blob/d78d8dafffab7eafc3de7f31c4ee0781be0b0656/gdk/wayland/gdkseat-wayland.c#L3789-L3806) is safe and one can create their own zwp_tablet_manager_v2 binding and listeners

11:43 <vyivel> i believe so

11:51 <kekekeks> So, a language binding should generally assume that it "owns" wl_proxy objects that it got from event arguments with "new_id" and ones it has created manually. To check that it "owns" an given wl_proxy it should utilize wl_proxy_get_tag

11:55 <vyivel> sounds right yeah

12:16 <kekekeks> So, for GTK handling wl_surface::enter this way (https://github.com/GNOME/gtk/blob/d78d8dafffab7eafc3de7f31c4ee0781be0b0656/gdk/wayland/gdksurface-wayland.c#L830-L834) is an incorrect libwayland-client usage, right?

12:17 <kekekeks> Since it assumes that it has a relevant GdkMonitor record that it has seen from its own registry listener

12:19 <kekekeks> So if a 3rd party client reuses the same connection, binds to wl_registry, creates a proxy for wl_output, GTK's window->monitor association would be broken

12:20 <kekekeks> I. e. it's not possible to query for wl_output properties without breaking GTK in some way

13:13 <kennylevinsen> kekekeks: assuming you don't mean a third party *client* but just that the same gtk-using process reuses libwayland client and display connection, association wouldn't be broken for wl_output's that GTK knows, just duplicate output objects it won't know - it might just yield a NULL GdkMonitor or something

13:13 <kekekeks> It's about code running in the same process reusing the same wl_display object

13:14 <kekekeks> GTK doesn't seem to expect extra wl_output objects existing on the same wl_display

13:15 <kekekeks> And it's the first event handler I've checked, there might be more instances of this

13:17 <kekekeks> Is multiple libraries or event toolkits utilizing the same connection a supported scenario wayland/libwayland-client were designed for or is that just something that happens to sometimes work fine?

13:21 <kekekeks> *event

13:21 <kekekeks> *even

13:40 <kennylevinsen> a Wayland display connection is not meant to be shared in a arbitrary and uncoordinated fashion, but some coordinated sharing is possible - in your case if GTK is upset, consider filing an issue/sending a patch to ignore unknown wl_outputs

13:42 <kennylevinsen> I personally see it as a bit of a hack whenever a display connection ends up having more than one wl_registry instance, a result of lack of cooperation between the display owner and whatever is trying to extend some functionality

15:49 <dcz_> is anyone allowed to merge experimental MRs once the waiting time completes?