00:03 Company: I don't mind using file descriptors (well, I do mind a bit as long as we limit them to 1024 per process)
00:04 Company: I do mind requiring applications having to write complex code to use them
00:06 Company: I also do mind every wayland protocol using fds differently for basically the same thing: sending a bunch of bytes between processes
00:07 Company: so you can't have a good abstraction, but instead have to implement a slightly different 100 lines of code each time
00:09 Company: dnd/clipboard basically wants a pipe, but this one wants a memfd - but we can't spec a memfd, we instead want "must be readable and seekable and is defined by sending the offset"
00:10 Company: and then you have to define tons of special error conditions because all the fds are different and who knows what kind of error the other side is gonna get from reading a random fd
00:10 kennylevinsen: Company: just use your existing allocation for wl_shm purposes
00:11 kennylevinsen: the requirements are the same, no new code needed
00:13 Company: no worries, GTK has at least 2 copy/pasted (different) implementations of memfd usage
00:13 kennylevinsen: the wording is a bit awkward, basically just wants to say "should work with mmap and pread" - not sure why you'd ever want to read instead of mmap, but whatever
00:14 Company: one using memfd_create() and the other syscall (__NR_memfd_create,...)
00:14 kennylevinsen: well maybe there's room for some cleanup, but it seems like you have all the code you need already then
00:14 Company: I guess the old one is whatever krh wrote when he invented the wayland backend and the new one is a copy form mutter or weston
00:15 Company: my point is less about my ability to write that code
00:15 Company: it's about the unnecessary complexity and forward maintenance
00:16 kennylevinsen: you can feel that way, but I just can't agree. fd's are needed for efficiency and seem like en entirely reasonable unix-idiomatic design choice...
00:17 Company: I did not complain about using fds
00:17 kennylevinsen: correction, mmapable fds
00:18 Company: the icc profile code definitely doesn't need mmapable fds
00:18 Company: nobody is gonna throw gigabytes per second of icc profile data at a compositor
00:19 kennylevinsen: i definitely would not want to waste time in a copy loop of large data structures on both ends when it is trivially avoided by just mmapping
00:20 kennylevinsen: The same reason that keymaps are strictly declared to be mmapable
00:31 ascent12: For a unix program, making a shm file is not weird/complex at all.
00:32 ascent12: I think the protocol buffer was like 4KiB or somewhere around that. sending an icc profile literally could be too big for it
07:20 MrCooper: zzag: the way I like to think about it is: committing the parent of a synchronized sub-surface creates/amends an implicit transaction with the pending state of the parent and the cached state of the child; if the parent is itself a synchronized sub-surface, this transaction becomes its cached state
07:23 MrCooper: zzag: in your example, committing C results in the cached state of C being a transaction with state for C and/or D; this transaction doesn't get committed before B is committed (which results in a transaction with state for B and/or C and/or D) and then A is committed (which commits a transaction with state for A and/or B and/or C and/or D)
07:24 MrCooper: zzag: the transaction committed when committing A then isn't applied until all buffers attached in it for A/B/C/D have become idle)
07:25 zzag: MrCooper: okay thanks, that answers my question
07:27 MrCooper: zzag: notice how this may result in 3 independent transactions for cached sub-surface state in your example, so a single per-surface "lock" for cached sub-surface state cannot handle this correctly
07:56 MrCooper: zzag: also note that the only mutter-specific part is waiting for buffers to become idle, otherwise this is a general description of how synchronized sub-surfaces work
07:59 zzag: MrCooper: yeah, I've been just wondering what other surfaces mutter locks. Locking child subsurfaces is unnecessary though, right?
07:59 zzag: i.e. it should be enough to just lock all sync ancestor parent surfaces?
07:59 MrCooper: per above, it's unavoidable
08:02 MrCooper: the cached state of a synchronized sub-surface is "locked" until its parent is committed
08:04 MrCooper: hmm, it might be clearer to say "state changes" instead of just state for all of the above
08:04 MrCooper: attaching a buffer being one example of a state change
08:05 zzag: sure. what I meant is that parent state cannot be applied until one of its descendant subsurfaces doesn't have idle buffer
08:06 zzag: locking descendant subsurfaces might be redundant because their state will be applied when parent state is applied
08:06 zzag: although I guess it depends on how subsurfaces are implemented
08:07 MrCooper: not sure what you mean by that; all buffers attached in an implicit transaction resulting from recursive synchronized sub-surface commits have to become idle before the transaction can be applied
08:07 zzag: i.e. whether transactions are reused to implement cached state
08:07 MrCooper: I'm afraid it sounds like you still haven't fully grokked the above description :)
08:09 MrCooper: the implicit transaction for cached sub-surface state is reused until the parent surface is committed, at which point it becomes part of the parent's cached state (if the parent is itself a synchronized sub-surface)
08:10 MrCooper: then the next commit of the original sub-surface creates a new implicit transaction for its cached state
08:12 MrCooper: this principle repeats recursively with nested synchronized sub-surfaces
08:12 zzag: MrCooper: I got that. I was talking about the general principal that the parent state cannot be applied until one of its sync subsurfaces doesn't have idle buffer and locking child subsurfaces is unnecessary
08:13 zzag: either way, thank you for clarifying how mutter handles it
08:13 MrCooper: s/one/all/
08:13 zzag: yeah, sorry for the typo
08:14 zzag: also s/doesn't/don't/ :p
08:14 MrCooper: "locking" for synchronized sub-surface state and for buffers not being idle is independent, can't skip one for the other
08:16 MrCooper: and a single per-surface "lock" for synchronized sub-surface state can't work correctly with nested synchronized sub-surfaces
08:16 MrCooper: no way around keeping track of the implicit transactions
08:17 zzag: why? parent surface won't apply new state and thus no sub-surfaces will be committed
08:17 zzag: s/will be committed/apply new state either/
08:18 MrCooper: committing sub-surfaces creates new implicit transactions though
08:18 MrCooper: which are independent of the committed transaction which is "locked" by buffers not being idle yet
08:38 MrCooper: zzag: the example in https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4040#note_2010264 might be illustrative
08:41 zzag: MrCooper: yep, that's what I mean by not applying parent state until all its subsurfaces have idle buffers
08:43 MrCooper: that is true, doesn't reduce the overall complexity though
09:05 pq: kennylevinsen, pread'ing an fd avoids the SIGBUS horrors of mmap, when it happens to be feasible.
09:05 pq: kennylevinsen, also pread can be done O_NONBLOCK - poll for readable after EAGAIN, unlike mmap access.
09:13 ascent12: The client could give you an fd that doesn't work with poll though
09:13 ascent12: I assume memfds/shm doesn't work with poll
09:13 pq: I assume they'd never block either
09:14 ascent12: I've written hack clients that pass a reference to a normal file before, which worked
09:15 ascent12: The more I think about it, preading it maybe isn't too bad of an idea
09:16 kennylevinsen: my wallpaper and lockscreen clients pass bitmap files directly off the disk too
09:16 kennylevinsen: pq: yeah SIGBUS kinda sucks but we're not avoiding that any time soon
09:17 pq: zzag, how about an example on your A -> B -> C -> D sync'd subsurface chain: update D1, update C1, update D2, update B1, update D3, update C2, update D4, update A1. What states should be current after all that?
09:17 ascent12: I'm trying to think if OpenGL has a way you can pread it into a buffer without an extra copy. Vulkan doesn't seem like it would be hard.
09:17 pq: kennylevinsen, I am avoiding it, by intending to use pread for ICC files :-)
09:18 kennylevinsen: I definitely wouldn't want to spec our way out of being able to mmap, copy loops in the compositor (bloody xwayland copy/paste integration) gets me irrationally upset :P
09:18 pq: and passing files straight from disk of course works, but it causes a risk for the compositor that reading the file (pread or mmap) might block for a bit.
09:19 kennylevinsen: if you parse it streaming with pread that's fine by me
09:19 pq: kennylevinsen, I'm definitely keeping the requirement to be able to mmap, yes.
09:20 pq: we also limit ICC files to 4 MB in the protocol, which I think is fine for Weston to allocate and copy, as long as fd access does not block.
09:21 pq: it's just definitely too much to push as bulk data through the Wayland socket
09:22 pq: ascent12, um, what does OpenGL or Vulkan have to do with ICC files?
09:22 ascent12: I was just thinking about sharing data in general, i.e. wl_shm
09:22 zzag: pq: A1 -> B1 -> C1 -> D1
09:23 pq: this is very specificly about ICC files
09:23 kennylevinsen: pq: even the smallest of wayland messages are too much for the Wayland socket with high-speed input devices :)
09:24 pq: zzag, right, I think. If you think about all the pending transactions between all the surfaces, I think you should find that you need to have transaction objects rather than looking at current and pending state on each surface, when further commits happen on arbitrary surfaces.
09:25 kennylevinsen: (that whole discussion was mostly about the client not being able to use a pipe being perceived as complexity. Even if not mmap'd you'd want to use pread anyway.)
09:26 pq: zzag, e.g. continue with: commit C, commit B, commit A; what is the current state on D?
09:27 pq: oh, I didn't understand someone wanted to use a pipe.
09:27 pq: for ICC files
09:28 kennylevinsen: yeah, the issue was with the seekable requirement and anonymous files being perceived as a resulting "unnecessary complexity" (quotes not to be rude, just to quote the opinion)
09:28 pq: we could do that instead of mmappable for ICC files, sure, but then you need the client to run a pipe writing loop and preferably not block itself completely on that.
09:29 pq: vs. just prepping a file, sending that over, and waiting for the event to say "ready"
09:30 pq: sure, copy/paste/dnd need that, but why would that be re-usable, if one can't make an anon file creation re-usable...
09:31 pq: just put the helpers in the toolkits you want your devs to use
09:31 kennylevinsen: even for in-memory profiles (something decoded from a compressed image file perhaps?), making an anonymous file seem pretty trivial and Gtk (the toolkit in question) would already have the code for wl_shm reasons :S
09:31 pq: yeah
09:32 pq: maybe not exposed in a re-usable form, but that shouldn't be a problem to refactor
09:46 MrCooper: pq: the term "current state" is a bit ambiguous though; it makes me think of the committed protocol state, whereas you meant the output state — maybe "applied state"?
10:19 pq: MrCooper, the state currently used the compositor for display and window management. Applied, yes.
10:23 MrCooper: for display, right, though window management is a bit more complicated; e.g. protocol errors due to "wrong surface size" need to be based on the current committed protocol state, otherwise there may be spurious errors if a transaction gets delayed
10:25 MrCooper: (you probably knew this, hope it may be useful for others though)
10:27 pq: good point
10:40 zzag: pq: A2 -> B2 -> C2 -> D3 if I understand your question correctly
10:41 pq: zzag, you're making me do the same exercise with pencil and paper - fair :-)
10:43 zzag: switching between sync and desync mode is another tricky place
10:44 zzag: but if the compositor tracks which state to apply when it's manageable, but still, would be nice if you didn't have to care about that case :p
10:50 pq: I counted A2, B2, C2, D4, meaning that D2 and D3 ended up being discarded.
10:52 pq: yeah, the relatively simple rules produce surprisingly complex tracking. I didn't foresee that, and I think Weston gets it wrong.
10:52 zzag: Oh, right. I counted C2 as the starting point for some reason
10:53 zzag: If you meant a new commit, then
10:53 zzag: A2 -> B2 -> C3 -> D4
10:53 pq: ah, yes
10:55 pq: I think it is possible at every "level" A, B, C, D to have a different state for D as a pending transaction. That's what I was trying to show.
10:56 pq: then depending the following commits, any one of those could end up on screen
10:57 pq: e.g. in that example, D3 state gets discarded by a commit to C
10:59 pq: discarding a transaction means sending presentation-time discarded event if one was requested
11:00 zzag: I don't think that it can be discarded
11:00 zzag: D3 and D4 would have to be merged
11:00 pq: ok, bad choice of words, merged, yes
11:01 pq: but it's still the presentation-time discarded event, because the frame is guaranteed to never show, even if the other state accumulates
11:56 pq: swick[m], I'm tempted to ask Simon Thompson which function he takes as the sRGB EOTF :-p
11:57 swick[m]: do it!
11:57 pq: lol
11:57 swick[m]: hilarity will ensue
12:01 swick[m]: pq: btw, I'm in the colorweb CG now so if you want to raise ant particular issue just let me know
12:01 pq: ooh, cool!
12:03 pq: swick[m], btw. will you take over the HDR static metadata correspondence, or should I formulate the follow-up question?
12:04 pq: hmm, maybe I should also ask Thompson about HLG vs. target color volume
12:04 pq: since he just explained how target dynamic range is a non-issue
12:06 swick[m]: pq: I'm not sure when I have time. Busy with some other stuff right now.
12:06 swick[m]: so if you find the time, go ahead, otherwise I'll do maybe in a few days
12:08 pq: I'm might not, I'm not sure what else we could learn
12:08 pq: at least now we know what we don't know
12:09 pq: We should have a PLUGE fullscreen app.
12:11 JEEB: hehe, the definition of srgb eotf still being a question I see 8)
12:12 JEEB: hlg apparently got some imaging version being defined. only saw it in passimg in jvet documents, but no difference of definiton
12:13 JEEB: or well, not no difference but rather "mentiomed but definition was not explained"
12:13 pq: JEEB, I've made my mind based on Troy Sobotka telling me to RTFspec, but I'm curious what professionals think. :-)
12:13 JEEB: :)
12:13 pq: I still need to reply to Troy in Gitlab
12:15 pq: I wonder if we'd need direct control of limited quantization range values in the video signal to properly implement PLUGE though...
12:15 pq: that's not really possible with KMS today
12:16 pq: not without sending full range and forcing a monitor to take it as limited range, ugh
12:17 swick[m]: which would not be a problem if we had colorops on the CRTC and separated the signalling completely from the colorops
12:17 pq: :-)
12:17 swick[m]: but yeah, right now, not so much
17:47 ids1024: Are relative pointer and pointer gesture events expected to be part of `wl_pointer::frame` blocks? Neither protocol says anything about `frame`, but it looks like XWayland does assume this for relative pointer: https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xwayland/xwayland-input.c?ref_type=heads#L904-906
17:50 vyivel: i'd expect them to be, would be nice to specify this
17:51 ids1024: Looks like Sway doesn't send `frame` for pointer gestures
19:55 wlb: wayland-protocols Merge request !245 opened by Ian Douglas Scott (ids1024) relative-pointer: Mention interaction with `wl_pointer.frame` https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/245