13:00 <riteo> TIL, looking from yesterday's discussion, that events with global arguments (e.g. wl_surface::enter) get resent for each instance of the same underlying resource

13:00 <riteo> I'm curious, is this a libwayland thing or does the compositor need to do that themselves?

13:16 <vyivel> the latter

13:52 <riteo> I see

13:52 <riteo> thank you for clarifying!

21:15 <DemiMarie> Qubes OS is hiring a graphics developer with Wayland experience: https://www.qubes-os.org/news/2025/05/08/invisible-things-lab-hiring-linux-graphics-stack-developer/

21:30 <kekekeks> Great, GTK calls wl_surface_get_user_data when handling events from wl_data_device and feeds that pointer to GDK_IS_WINDOW

21:31 <kekekeks> Which does a chain of dereferencing operations

21:33 <kekekeks> i. e. it essentially checks if **userData == magic_constant and if that's not true calls g_type_check_instance_is_a

21:33 <kekekeks> It has this as an early escape - https://github.com/GNOME/glib/blob/39b5613e739c90ea9386ebdcb18916fbf23f5688/gobject/gtype.c#L3897

21:34 <kekekeks> So any lib that creates wl_surface instances on the same connection as GTK is essentially disallowed to attach user data to its wl_surface objects

21:34 <kekekeks> And that's not GTK's fault

21:35 <kekekeks> Because, how else it would be supposed to differentiate its surfaces when handling events from wl_data_device

21:35 <kekekeks> I suppose one could provide a user data struct with first 8 bytes set to zero

21:36 <kekekeks> Which would avoid crashes in GTK

21:36 <kekekeks> But it's something that seems to be broken by design on either protocol level or on client library level

21:36 <kennylevinsen> I'm not sure I follow, early escape just mean ignored object, no? also, GTK shouldn't really be confronted with such foreign surface, as it has no listeners on it (and unlike wl_output, it shouldn't be a surprise argument either)

21:38 <kekekeks> GTK listens on wl_data_device and wl_touch interfaces

21:39 <kekekeks> Those interfaces receive events for *all* wl_surface instances created by the same connection

21:39 <kennylevinsen> aaah, that's the point of concern

21:40 <kennylevinsen> fair, but again: early escape ignoring a surface gtk doesn't own seems fine

21:40 <kekekeks> https://github.com/GNOME/gtk/blob/3366f835251bd8671b63874e6bbd16022c8dfef1/gdk/wayland/gdkseat-wayland.c#L1673

21:40 <kekekeks> https://github.com/GNOME/gtk/blob/3366f835251bd8671b63874e6bbd16022c8dfef1/gdk/wayland/gdkseat-wayland.c#L1572-L1576

21:40 <kekekeks> There are no early escapes on wl_touch code path

21:41 <kekekeks> User data is being directly assigned to GdkSurface-typed field - https://github.com/GNOME/gtk/blob/3366f835251bd8671b63874e6bbd16022c8dfef1/gdk/wayland/gdkdevice-wayland-private.h#L35

21:43 <kennylevinsen> then either: 1. this is a GTK bug (the existing check suggests this was intended - maybe blame will till), or 2. GTK does not support sharing it's connection with something creating additional surfaces and require that the surfaces are made through GTK (Firefox unfortunately is known to create its own surfaces under GTK, but their code is a bit hairy to study/work with)

21:44 <kekekeks> From API design point of view I'd consider this to be wayland/libwayland-client problem, no other API for interacting with system's display server requires one to put special effort for "connection sharing" on every interaction

21:45 <kennylevinsen> either fits with what I previously said: coordinated sharing is possible, i.e. GTK as the owner of the display connection ultimately decides the rules for using its connection

21:46 <kennylevinsen> I wouldn't consider the issue to be a user data problem as much as just an unknown resource problem

21:47 <kennylevinsen> they could have used a hashmap of resources and freaked out on unknown resource, and the issue would be the same

21:47 <kekekeks> If this was considered during design, a slot-like system like with TLS could have been a thing

21:48 <kennylevinsen> that wouldn't solve unknown resources in general, and even if there was a slot that was used GTK could decide to assert on the presence of their value

21:48 <kekekeks> Anyway, the thing I'm trying to do seems to be not possible to implement

21:48 <kennylevinsen> what are you trying to do?

21:49 <kekekeks> wl_subsurface-based cross-toolkit embedding

21:56 <kennylevinsen> if the other toolkit can render a buffer and get input fed in it could work without sharing a connection

21:58 <kennylevinsen> embedding a surface using a different "toolkit" directly using the connection would probably require specific support from it...

21:58 <kekekeks> popups will be a problem

21:58 <kennylevinsen> but some of your observations might be worth noting somewhere, either for discussion or for documentation should others try to go that path

21:58 <kekekeks> since those need to be triggered from the same connection as the original window

21:59 <kennylevinsen> if the toolkit can render to a buffer it might also be able to ask for a popup window type, which the glue would then provide

21:59 <kekekeks> that would essentially require a gtk-based "backend" implementation

22:00 <kekekeks> since all of the input, dnd, etc, etc would need to go through GTK

22:00 <kekekeks> keyboard and IME is already a problem since wl_subsurface can't have keyboard focus

22:01 <kennylevinsen> it would require the nested toolkit to be able to just provide buffers and ask for e.g. particular surface types, while the embedder would create those however it likes and send the input it receives for them along

22:01 <kennylevinsen> if the main app is GTK, then yes it would be using GTK for that

22:01 <kekekeks> GTK has a rather peculiar way of doing GPU-based drawing

22:02 <kekekeks> it wants a separate OpenGL context per GdkWindow

22:02 <kekekeks> so buffer sharing will be tricky too

22:02 <kekekeks> Plus there can potentially be problems with pixel formats

22:03 <kekekeks> if one would want to e.g. present yuv content

22:03 <kennylevinsen> I'm no GTK expert, but buffers can be shared and imported for e.g. texturing. GTK does not allow you to take ownership of rendering of a surface, hence Firefox's somewhat wonky integration

22:06 <kennylevinsen> might be worth noting down the issues as others might hit them if trying to share a connection for other reasons, but yeah if the target is GTK then "not possible at the current time" seems like a sound conclusion - some of the GTK people in here might have some specific commentary

22:18 <kekekeks> I'll file an issue against GTK4, we kinda have to target GTK3

22:19 <kekekeks> Mkay, if there is no wl_surface associated user-data (nullptr) it later results in a bunch of scary error messages are g_object_ref and gdk_window_get_root_coords complain about the thing not being a window, but it doesn't seem to have a broader effect

23:10 <kekekeks> I'd presume that event "duplication" works in the same way for `tablet-v2` interface and having multiple copies of `zwp_tablet_v2` would trigger a tool proximity event for each of those, right?

23:16 <kekekeks> I guess one could write an LD_PRELOAD-wrapper for libwayland and "isolate" GTK from events with tag-less objects

23:17 <kekekeks> So it would only see wl_proxy objects that it either bound to via constructors or by receiving as new_id