06:31 wlb: wayland Merge request !337 opened by Francesco Guastella (romeoxbm) build: conditionally define tests in egl/meson.build when the 'tests' option is enabled https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/337
08:21 zzag: MrCooper: mutter will delay applying surface state until the committed buffer is ready. How does this work with subsurfaces? Let's say there's the following tree: A -> B -> C -> D. "A" is the main surface. If surface C is committed and its buffer is not ready, what will mutter do? Will it put A, B, and C in the same transaction? or C and D? or all of them?
08:22 zzag: B, C, and D are sync subsurfaces
08:59 ascent12: zzag: I don't know anything about their imeplementation, but a synced subsurface that is not ready should block its parent surface. It would violate the "every frame is perfect" thing otherwise.
09:47 pq: right, and a non-ready surface that has a sync'd sub-surface should block the sub-surface too if the sub-surface attempts an update.
09:49 pq: The usual rules apply too, so if C is committed, that update cannot become a transaction until B is committed, and then A is committed.
13:49 wlb: weston Merge request !1352 opened by Pritama Biswas (pritamabiswas) Set atomic_complete_pending as false at the time of disconnect https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1352
14:32 wlb: weston/main: Robert Mader * pixel-formats: Add P010/P012/P016 formats https://gitlab.freedesktop.org/wayland/weston/commit/3c9e9d721e9c libweston/pixel-formats.c
14:32 wlb: weston/main: Robert Mader * renderer-gl: Add YUV format descriptors for P010/P012/P016 https://gitlab.freedesktop.org/wayland/weston/commit/12744bcbeeac libweston/renderer-gl/gl-renderer.c
14:32 wlb: weston Merge request !1351 merged \o/ (Add support for P010/P012/P016 formats https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1351)
15:38 Company: swick[m]: what kind of fd is seekable, readable, portable, and can be created for random memory? memfd? Is that portable?
15:38 swick[m]: Company: what do you mean with portable?
15:38 Company:wondering how to implement support for wayland color for color_state_new_from_icc_bytes (GBytes *bytes)
15:39 Company: "works everywhere that wayland works" I guess
15:43 Company: I was assuming I could just write it into a pipe, but pipes aren't seekable
15:43 swick[m]: Company: then no, memfd is not portable
15:43 swick[m]: https://gitlab.freedesktop.org/wayland/weston/-/blob/main/shared/os-compatibility.c?ref_type=heads#L178
15:45 swick[m]: so, create a regular file on tmpfs if you can't use memfd
15:45 Company: that seems kinda awkward to require for everyone who wants to send an icc profile
15:45 swick[m]: why?
15:46 Company: but I guess Wayland has no generic way to send a bunch of bytes?
15:46 swick[m]: not without clogging up the pipe, no
15:46 swick[m]: glib-ified version https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/core/meta-anonymous-file.c
15:47 Company: wl_buffer(), but that's for image data
15:47 kennylevinsen: the other side might also want to mmap the the profile, rather than waste time reading it into a new buffer
15:48 Company: and I guess using wl_shm sucks for that, too
15:48 Company: I'm just thinking that this is an application requirement for any app that wants to use that part of the protocol
15:49 kennylevinsen: wl_shm wraps an fd with the same requirements
15:49 swick[m]: yeah, this is the same
15:49 swick[m]: and it's horrible we can't specify that it should be sealed
15:49 swick[m]: just because some OSes are horrible
15:50 swick[m]: so, even more horrible signal mess
15:51 kennylevinsen: Did talk about fixing the sealing/sigpipe/etc. hell server-side through the kernel end anywhere or did it die? I remember talk of a new mmap flag
15:51 swick[m]: didn't see anything new
15:51 Company: I wish there was code in libwayland that gave you a memory region to share with the compositor
15:52 swick[m]: Company: really, client side has nothing to complain about...
15:52 swick[m]: all the horribleness is in the compositor
15:52 Company: then the compositor can hand over the fd that the client gets to write the icc profile into!
15:52 swick[m]: Company: but sure, if you want to add something to libwayland, go ahead
15:52 kennylevinsen: Company: I mean it could be there, but libwayland shouldn't become a generic platform helper lib...
15:53 swick[m]: eh, too late
15:53 kennylevinsen: ... on the client-side at least
15:53 kennylevinsen: maybe one day we get to nuke the event lib from server
15:54 Company: kennylevinsen: i'm just thinking that the eog or whatever image viewer devs - who usually write python code - decide to send the icc profile for the image they just loaded to the compositor
15:54 Company: but then, they might just send the fd of the png file + the offset where the profile starts
15:55 kennylevinsen: Company: it would be quite silly to force the client to write this to an FD. It's quite likely that the compositor would want to mmap the profile, and quite likely that the profile is on disk and can be sent directly.
15:55 kennylevinsen: plus there's nothing hard about using shm or memfd
15:55 Company: apparently it's >100 lines of code littered with #ifdefs
15:55 kennylevinsen: wouldn't the ICC profile in case of eog be in the file on disk?
15:56 kennylevinsen: That's if you want all the bells and whistles, shm is portable but lacks sealing
15:57 kennylevinsen: re: eog, the current approach would let you just send an fd to the file and an offset to the ICC profile assuming it's in a readable format
15:58 swick[m]: indeed
15:58 Company: yeah, works for png probably
15:58 Company: if the file format is compressed, it'll stop working
15:59 Company: and there's all the races you can get into if the compositor and the app do stuff
15:59 kennylevinsen: What races?
16:00 kennylevinsen: The lifetime of the fd is well-defined, no?
16:00 Company: yeah, if you assume app developers have the same skills in lifetime management as compositor developers
16:01 kennylevinsen: anywho, basic shm example which is 75% "picking a name": https://github.com/emersion/hello-wayland/blob/master/shm.c
16:02 kennylevinsen: Company: Not closing an fd or modifying its content prematurely is a pretty simple requirement
16:02 dottedmag: Users may inadvertently do that, right? Overwriting the file while it's open.
16:04 kennylevinsen: sure, if you overwrite the image file that the image viewer and compositor are both reading from, they'll equally fail to read it. Seems like a sound error case, and IIRC the protocol defines errors for being unable to read?
16:05 Company: it just feels very cumbersome and brittle for "here's an array of bytes"
16:05 kennylevinsen: well, this is how all data is passed in wayland
16:06 dottedmag: keymaps are passed this way too, though in another direction
16:06 kennylevinsen: Because it's the only "smart" way to pass data on *nix
16:07 Company: that's why I said I wished libwayland had an API for "here's an array of bytes"
16:08 Company: so the code doesn't have to be "smart"
16:09 kennylevinsen: I get that, but then you could extend it to saying libwayland should have all sorts of other generic convenience things a Wayland client would need, and we'd prefer to keep stuff out...
16:10 kennylevinsen: We made the mistake of adding an event loop lib to the server for example under the same idea of "well you'll need it" - huge mistake :(
16:10 kennylevinsen: So if it's not a Wayland specific thing - and fds are certainly not - it's best done elsewhere, in whatever way you like
16:11 Company: it's pretty wayland-specific to me
16:11 Company: dbus can send an array of bytes for example
16:11 kennylevinsen: it's entirely generic Unix fds, with a handful of Unix ways if making it. Very Unix and not Wail and if you ask me.
16:12 kennylevinsen: You can call open(3) to get a compatible fd from a file, or shm_open(3) to make an anonymous file. POSIX.
16:13 kennylevinsen: s/Wail and/Wayland/ - I feel like my phone's autocorrect is doing this on purpose at this point
16:16 Company: this is not about files though, this is about byte arrays
16:16 kennylevinsen: That's an anonymous file
16:18 dottedmag: libanonfile anyone? :)
16:18 kennylevinsen: (just like your process heap is btw)
16:19 Company: now we figured it out, we just send an offset + size into the process heap!
16:20 kennylevinsen: lol I was just about to say that hahaha
16:20 kennylevinsen: bad idea of the day
16:20 Company: I'm all for that, because that's literally what a pointer is
16:21 Company: all the compositor has to figure out is how to read it, but that's not the client's problem
16:21 kennylevinsen: yeah - but also why making a new anonymous file to share is not weird
16:21 kennylevinsen: and sharing your heap would *definitely* have some if those races you mentioned :P
16:22 Company: I consider that very weird, because as an app developer I never have to do that
16:25 kennylevinsen: Odd that you'd say that considering how much it happens. Maybe because a toolkit is taking care of it most of the time? gdk, gtk, Mesa WSI...
16:26 kennylevinsen: we pass fds for copy/paste and dnd, shm, dmabufs, keymaps, etc.
23:59 ascent12: Company: dbus can theoretically work over TCP (as rare as that is), which is why it needs to be able to push bytes over the protocol. Wayland _always_ uses unix domain sockets, so there is no reason to not just use file descriptior passing for basically everything.
23:59 ascent12: I think the protocol buffers were made intentionally quite small so people didn't get any silly ideas.