03:48 mooff: could I ask some questions that'll help me with a potential project
03:48 mooff: does Wayland use a socket-compatible protocol, or more of a direct ABI?
03:50 mooff: how big is the surface area to hook something like GDK up to Wayland?
03:52 mooff: I'd like to hook GTK4/GDK up to an existing web Wayland compositor, called "greenfield", through a wasm interface
06:26 wlb: weston Issue #757 opened by yishan yang (yayowd) cannot start up when upgrade weston to 12.0 https://gitlab.freedesktop.org/wayland/weston/-/issues/757
07:01 RAOF: mooff: It's not *entirely* clear what you're asking; particularly, GDK already *has* a Wayland backend.
07:02 RAOF: But for the question that is clear: yes, Wayland describes a (unix-)socket protocol; there's no* requirement that either end links to any particular library.
07:04 RAOF: The asterisk there is: if you want to use other libraries that talk Wayland - such as, say EGL or Vulkan - you'll need to be able to provide the types and the ABI that they use.
07:05 mooff: RAOF: i fear that connecting that Wayland backend to a JS Wayland compositor through the WASM bridge wil involve impl'ing a wide range of syscalls
07:05 mooff: i hoped someone Wayland-versed could allay or confirm those fears
07:05 mooff: or whether it can be as simple as hooking up a binary socket
07:06 mooff: i don't know much about the Wayland protocol
07:06 RAOF: If you want to connect a Wayland client to a compositor, that just requires that you provide a socket, yes.
07:06 mooff: ooh!
07:07 RAOF: Although that socket is going to need to be capable of passing file descriptors.
07:07 mooff: i didn't know there was an out-of-band way to send fds over POSIX sockets
07:07 mooff: is that the case? or do you just mean OS-defined file descriptor integers?
07:08 RAOF: man 7 unix, and SCM_RIGHTS.
07:08 mooff: (going through write() as normal data)
07:08 mooff: thanks..
07:08 kennylevinsen: mooff: it's a Unix domain socket which had the ability to send fds
07:09 mooff: that doesn't sound impossible to wire through Emscripten. better luck if it's already implemented, though.
07:10 mooff: alright that sounds much more doable than implementing a range of protocol-specific functions to cover a big C interface
07:11 mooff: that's exactly the help i was looking for, saves me lot of time trying to see through abstractions
07:14 mooff: what's the minimum number of descriptors required to render a single client?
07:14 mooff: if 1, then it could be stubbed.
07:17 dottedmag: mooff: Unbounded.
07:17 dottedmag: Well, techncally the limit is ~2^32
07:19 kennylevinsen: well 1 for the display socket, but many fds will be transferred over it.
07:20 emersion: dottedmag: not even that, FDs can be closed and re-opened
07:21 dottedmag: emersion: Yeah, I meant ~2^32 active at any given time, due to protocol IDs.
07:54 pq: mooff, if I'm not totally confusing people here, you want to chat with zubzub.
08:07 mooff: thanks.
08:08 mooff: hey, zubzub (!)
08:11 mooff: #gtk haven't balked at the idea, so maybe we can get this done.
10:28 mooff: ah, zubzub, you are udevbe. checking your wares for first time since we emailed in 2021.
10:54 DodoGTA: Is it possible to use OpenGL pbuffers on Wayland?
11:08 kennylevinsen: DodoGTA: I assume https://bugs.freedesktop.org/show_bug.cgi?id=105995 is still relevant for that
11:09 kennylevinsen: use an FBO instead
11:49 pq: I do sense a slight confusion between pbuffer and pixmap EGL surfaces there, but using a FBO is a good idea anyway.
11:50 pq: OTOH, I did get pbuffer support added in Mesa for EGL Surfaceless by asking for it.
11:51 kennylevinsen:certainly had a degree of confusion there
11:52 mooff: i know "some" of these words..
11:53 pq: Pixmap is a some kind of winsys buffer, that the winsys can copy from or maybe draw into. Wayland has no draw operations at all, and it has no concept of such "pixmap" either.
11:53 pq: pbuffer OTOH is a purely client-side concept that needs nothing from the winsys, so it could exist on EGL Wayland platform if someone bothered to hook it up.
11:57 kennylevinsen: So we have neither, but the latter could exist...
11:58 pq: I don't know if someone hooked up pbuffers or not.
11:58 pq: The only thing pbuffers gives you AFAIK is the use of EGL SwapBuffers API.
11:59 pq: and an EGLSurface to play with
12:00 pq: it can be a workaround for cases where EGL implementation refuses to make a context current without any EGLSurface - that would be some proprietary EGL at most, not Mesa
12:02 pq: if you really have to have an EGLSurface off-screen, then pbuffer is fine, but otherwise I think it's useless nowadays.
12:04 kennylevinsen: aaah, fair enough. I do vaguely recall running into them inside firefox, but never dug into what the heck they were for. Thanks for explanation.
14:13 wlb: weston Merge request !1250 opened by Marius Vlad (mvlad) libweston/weston-log: Add a iterator helper for debug scope https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1250 [Core compositor]
15:16 wlb: weston Merge request !380 closed (libweston: Expose weston_output_damage() in libweston)
18:31 Sallly: Come Visit us @ irc.twistednet.org channel #twisted
18:35 wlb: weston Merge request !1162 closed (Draft: color: add tone mapping WIP)
18:43 Sylvia: Come Visit us08 09i13r03c07.06t11w02i10s04t08e12d09n13e03t07.06o11r02g 10c04h08a12n09n13e03l07 06#t11w02i10s04t08e12d09
19:49 wlb: weston Merge request !1251 opened by Marius Vlad (mvlad) libweston/backend-headless: Remove cleanup_after_cairo() https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1251 [Testing], [CI], [XWayland]