12:44 <DemiMarieObenour[m]> My compositor and the daemon it talks to basically map Wayland onto X11. Can I map Wayland subsurfaces onto X11 child windows, or does that way lie glitchy graphics and sad users?

12:45 <DemiMarieObenour[m]> My intuition is that mapping X11 child windows onto Wayland subsurfaces is easy, but X11 subsurfaces just do not have the needed atomicity guarantees. Is this accurate?

13:15 <wlb> wayland Issue #201 closed \o/ (wl_display_terminate does not exit wl_display_run event loop when called from idle event https://gitlab.freedesktop.org/wayland/wayland/-/issues/201)

13:15 <wlb> wayland/main: Damian Hobson-Garcia * server: stop wl_display event loop from any context https://gitlab.freedesktop.org/wayland/wayland/commit/d564823cfdbd src/wayland-server.c tests/display-test.c

13:15 <wlb> wayland Merge request !175 merged \o/ (server: stop wl_display event loop from any context https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/175)

13:19 <wlb> wayland/main: Build #419968 failed after 3 minutes 55 seconds https://gitlab.freedesktop.org/wayland/wayland/pipelines/419968

14:25 <soreau> DemiMarieObenour[m]: I've hacked weston to do this, so it's possible, but IIRC resizing was horrible

14:26 <DemiMarieObenour[m]> soreau: Did transparent subsurfaces work?

14:26 <soreau> actually, here it is https://github.com/soreau/weston/tree/xwpsb

14:30 <soreau> and transparent surfaces can work afaik, you just need to create X windows with full 32bit depth

14:32 <DemiMarieObenour[m]> Was that backend rootful or rootless?

14:32 <DemiMarieObenour[m]> soreau: What about subsurfaces?

14:33 <soreau> I figure subsurfaces should map to OR windows

14:34 <soreau> https://github.com/soreau/weston/blob/xwpsb/libweston/xwps-backend.c#L849

14:34 <DemiMarieObenour[m]> soreau: As opposed to X11 child windows?

14:35 <DemiMarieObenour[m]> Would you mind expanding on “resizing was horrible”?

14:36 <soreau> DemiMarieObenour[m]: I'm not sure about subsurfaces specifically, maybe the relation should be children

14:36 <DemiMarieObenour[m]> soreau: Asking because I am not sure if transparent X11 subsurfaces actually work.

14:37 <soreau> but really this is a big hack that I doubt is on-topic for this channel

14:38 <DemiMarieObenour[m]> soreau: Do you mind if I direct-message you?

14:38 <soreau> sure

18:16 <DemiMarieObenour[m]> ManMower: My current thought for `wl_fixes` is that `wayland-scanner` will need to special-case `wl_registry`, so as to not emit `wl_registry_destroy` at all. Instead, `libwayland-client` would need to contain a hand-written implementation that does the right thing. Additionally, `libwayland-client` would need to obtain this information somehow, perhaps by binding to `wl_registry` itself, even though that would be a (slight)

18:16 <DemiMarieObenour[m]> regression on older servers.

18:17 <DemiMarieObenour[m]> Alternatively, `libwayland-client` could handle `wl_registry` specially, but that might lead to thread-safety problems.

18:33 <ManMower> I really don't like special casing that in the scanner at all - but I'm just one voice in the crowd

18:33 <DemiMarieObenour[m]> I don’t either, but the alternative seems worse.

18:34 <ManMower> the alternative being just leaking a handful of bytes and ignoring the theoretical problem for another decade? :D

18:34 <DemiMarieObenour[m]> honestly, if the registry destructor was the only problem, I would be prepared to call it a day

18:35 <DemiMarieObenour[m]> my main goal is actually dealing with the zombie object situation, which I think is a bit less theoretical

18:36 <ManMower> I think cases people have actually hit in non-contrived real world code are mostly sorted, but there are definitely still ways someone can footgun with custom protocol

18:36 <DemiMarieObenour[m]> ManMower: Will `wl_data_device` cause any objects to be leaked after the zombie MR is merged?

18:36 <ManMower> I feel like maybe we could validate protocol harder to prevent people from doing that, but then old protocol that has the capacity to explode but hasn't yet is suddenly not scannerable and... sigh

18:37 <DemiMarieObenour[m]> Allow people to override the checks with `--force`?

18:37 <ManMower> I have very strong doubts that MR will be merged, let's call that an RFC for now. I don't think it adds any new leaks, but now that you call out that specific case I'll have to sit down and think about it :)

18:38 <ManMower> hmm, that's a level of grossness I'd be willing to accept. but I don't know if anyone else would - and I also don't know that making the scanner "smarter" would actually help, I'm just thinking out loud

18:40 <DemiMarieObenour[m]> RFC idea: require every interface to have either at least one destructor event (and no requests of any kind), or at least one destructor request (and no destructor events)

18:43 <ManMower> hehe my knee jerk reaction is "yes please"

18:43 <DemiMarieObenour[m]> From what I can tell, so long as there are no interfaces that are (a) created by the server and (b) create new server-side objects themselves, the problem is solvable

18:44 <ManMower> yeah, I think that's right. that's certainly where I went to contrive an icky test case

18:44 <DemiMarieObenour[m]> So check that every server-generated object (with `new_id` in an `<event>`) is of an interface defined in the same file, and itself either has a destructor event, or has no events of any kind that create objects.

18:48 <DemiMarieObenour[m]> If one wanted to go even further, another option would be to state that *every* interface must have a destructor request named `destroy`, with a hard-coded list of exceptions

18:49 <ManMower> I've gotta BAIL in a minute, it's thanksgiving weekend here and we've got a bunch of family stuff planned.

18:49 <DemiMarieObenour[m]> Happy thanksgiving!

18:49 <ManMower> thanks! :)

18:49 <DemiMarieObenour[m]> You’re welcome!

18:51 <DemiMarieObenour[m]> BTW on further thought I think any server-generated object is bad, unless it is guaranteed to have either a destructor event, or a destructor request with no side effects.

18:52 <DemiMarieObenour[m]> The “no side effects” part is important because it means that libwayland-client can safely call its destructor automatically.

19:06 <wlb> wayland-protocols Issue #65 opened by () Accessibility protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/65

19:12 <any1> Just joined. Are we discussing that annoying race where server created objects cause clients to crash when the server deletes them and creates new ones because they reuse object ids so the client gets confused?