10:59swick[m]: is pq on vacation?
14:47daniels: swick[m]: he's off atm, yeah; not sure if he's back this week or next
15:01swick[m]: daniels: alright, thanks
15:29emersion: > Full disclosure: I'm looking at per-surface-buffer-release stuff without syncobj
15:29emersion: ohhh
15:30emersion: daniels: do you have a client where this would be useful?
15:30emersion:would love to unlock this…
15:30daniels: emersion: not one I can discuss :\
15:30emersion: :/
15:30daniels: yeah ...
15:30emersion: imho it should be released as soon as the compositor doesn't need it anymore
15:31daniels: basically though, it's media frames coming out of a codec which need to be attached to a live output on one output, and a preview window on another output, both of which are separate surfaces
15:31emersion: yeah
15:31emersion: is it gst or not?
15:31daniels: yeah, it is gst
15:31emersion: pretty sure per-attach-release would be useful for gst but couldn't wrap my head around it last time i tried
15:31daniels: haha, it's been refactored to be a bit better recently, so maybe it's easier now ...
15:32daniels: but yeah, there are also non-gst paths for not-particularly-good reasons
15:32daniels: anyway, I'm with you: the release should only occur when the buffer is removed or replaced from that surface
15:32daniels: and when that state has fully become live in the compositor, i.e. it's not blocked by parent subsurface updates or something
15:33daniels: would it help any if I turned it into a generic surface-buffer-release protocol which happened to have syncobj on the side? or would that just derail something that's actually quite close to landing? :P
15:33emersion: hm, wdym?
15:34emersion: i was thinking of https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/137
15:34daniels: !
15:34daniels: I didn't even see that
15:34daniels: apparently I reviewed it two years ago. brilliant.
15:34emersion: :D
15:35emersion: wlroots-as-a-client needs it, so that's why i submitted this
15:37daniels: I'm trying to think of a way in which returning a new named object (rather than the wl_callback) would be insufficient, e.g. to make it more clear for syncobj to latch on, and completely failing ... I think it sounds completely fine to have a get_release that sends a wl_callback with implicit sync semantics, and for syncobj to be something separate for explicit sync
15:39daniels: so yeah, I think I'll try to implement !137 for Weston first followed by !90, but not sure if I'll be able to get a GSt implementation as well
15:39daniels: (the client in question is using GSt to drive the codecs, but does all the presentation itself after being handled dmabufs, because of *mumble* toolkit)
16:07emersion: daniels: hm actually i can't see where in gst the situation where the same buffer is submitted to multiple wayland sinks is handled…
16:07emersion: gst_buffer_get_wl_buffer() does not do any checks
16:08emersion: AFAIU it just overwrites GstWlBufferPrivate.current_gstbuffer?
16:15vyivel: when a wl_output is destroyed, should compositors send wl_surface.leave right before that?
16:17emersion: there was a wayland issue about that iirc…
16:19vyivel: can't find it
16:37emersion: https://gitlab.freedesktop.org/wayland/wayland/-/issues/350
16:43Company: GTK will do the wrong thing without leave event, too
16:45Company: though barely anyone uses monitors with GTK (including GTK itself) because monitor APIs are meh
17:31pq: swick[m], I've been off sick since Friday, will not be back this week.
17:34emersion: ow :( hope you get better soon!
17:39pq: just the seasonal flu, I guess