08:40pq: yshui`, attaching two buffers before committing is described in protocol spec: only when pending surface state is committed, the buffer will become used. Hence, the overridden buffer will not be getting releases, because never came into use.
08:41pq: DemiMarie, I don't know.
12:22pq: excessive join/quits
14:07ukiran: hello
14:08ukiran: swick, pq, I have few doubts about the color representation protocol
14:09ukiran: as this protocol is used to perform the format conversion from YUV to RGB using the code points exposed through interfaces
14:10ukiran: this is based on the ITU-H.273 document.
14:10ukiran: Similar to that, are there any standards which does the conversion from RGB to YUV ?
14:19JEEB: ukiran: H.273 technically specifies XYZ to {RGB,YCbCr,YCgCo,ICtCp,ITPv2} and vice versa. biggest problem seems to mostly be the cases where EOTF and OETF are not the same thing, such as the old BT.709|BT.2020 transfer function entries.
14:20JEEB: they have notes for those where f.ex. BT.1886 should be utilized for EOTF while OETF is the marked one
14:31ukiran: The Color primary code point values mentioned are with the reference of XYZ color space ?
14:49JEEB: ukiran: so matrix is the thing you need to apply to get to the point where you can handle primaries (basically "identity matrix" meaning that depending on the primaries value it's either RGB or XYZ). and in primaries one of them is XYZ which is in many workflows the "end point" until you convert then to another thing, and transfer is what you need to apply to get to/from linear
14:49JEEB: I think H.273 (which is freely available) defines this rather well
14:50JEEB: and the other primaries generally are defined in the XYZ meaning
14:50JEEB: for example your bog standard sRGB being identity matrix, BT.709 primaries and sRGB transfer
14:55JEEB: or well, technically H.273 defines the code points which then refer to these different things and describe how the image should be interpreted
14:55JEEB: aka CICP (common independent code points)
15:34pq: JEEB, color-representation deliberately does not carry the colorimetry CICP fields. :-)
15:34pq: color-management does
15:34pq: a summary of the split is in https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/cicp_h273.md#wayland-protocols
15:37pq: ukiran, there is no difference between YUV->RGB and RGB->YUV. Both use the same matrices and stuff. This is not like the TransferCharacteristics mess.
15:37pq: ...except for the "constant luminance" variants...
15:38pq: color-representation alone is insufficient for the constant luminance variants, those need also color-management to carry the rest of the CICP fields.
15:40pq: JEEB, sounds like you were talking about ColourPrimaries and TransferCharacteristics when the question was about MatrixCoefficients.
15:43pq: I'm so grateful that H.273 put names on those things.
15:44pq: would be nice if it suggested names for the actual code points, too
16:09yshui`: @pq, that is not what I asked. I probably phrased it poorly 😅
16:13yshui`: so my current understanding is like this: the client attaching a wl_buffer to a wl_surface gives the compositor a "token" so to speak, which it can use to access the content of the buffer. when the compositor is done, it sends out a wl_buffer.released to give up that token.
16:13yshui`: and when the buffer naturally drops off the surface, the client would receive a released event as well.
16:15yshui`: so right now I only have one thing that's unclear. if the client attaches a buffer to a sync subsurface, commits the subsurface but not the parent, can the compositor access the buffer? and does the compositor need to send released for that buffer?
16:19MrCooper: yes and yes
16:22MrCooper: in a nutshell, buffer attach + commit transfers ownership of the buffer to the compositor, buffer release event transfers it back to the client
16:24yshui`: even if it is just committed to the cached state of a sync subsurface?
16:24yshui`: i would prefer it to be this way because it's easier to keep track of.
16:25wlb: weston Merge request !1183 opened by Michael Olbrich (mol) backend-drm: don't try to commit an empty state https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1183
16:28MrCooper: yshui`: yes, the only way for the client to get back ownership is via the release event
16:29MrCooper: even if it's "just committed to the cache", the compositor may need to keep ownership for when the parent surface is committed
16:34JEEB: pq: I just tried to give a general overview of H.273 since it seemed like ukiran had an understanding that it only touched YCbCr<->RGB
16:34JEEB: the wayland protocol is more limited, yes
16:34JEEB: (that specific one)
20:15yshui`: MrCooper: i see. nice. thank you.
22:29_DOOM_: How would I register my wayland client as a system tray?
22:37wlb: weston Issue #729 opened by Tomasz KÅ‚oczko (kloczek) 11.0.1: test suite is failing https://gitlab.freedesktop.org/wayland/weston/-/issues/729
22:40_DOOM_: Or how would I make a system tray in a wayland client?
22:46kennylevinsen: _DOOM_: dbus, https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/
22:46_DOOM_: kennylevinsen: Thank you
23:03tommybomb: I'm developing a command runner like bemenu. Right now I have the application launch, but in sway it's forcing it as a tiled application. Should I be using "wlr_layer_shell_v1" to properly launch it as an overlay? Or is there another way of going about this?
23:05emersion: you could set a fixed sized on your window if you wanted to make it floating by default
23:08tommybomb: Sorry, what method & protocol would that be?
23:11tommybomb: xdg_shell set_max_size?
23:11tommybomb: (on the toplevel)
23:12emersion: set_max_size and set_min_size with the same size on both
23:18tommybomb: That appears to have done the trick, thanks.
23:27RAOF: tommybomb: Yeah, if you want to be chrome (ie: something that decorates the desktop / an application), you'll need t ouse something like layer_shell.
23:36tommybomb: ok, thanks figured as much
23:50yshui`: hmm, i thought the surface pending state is like a shadow state, which the requests operate on. and then on commit, the current state is simply replaced wholesale by the pending state. but that's not the case, right?
23:51yshui`: pending state is like an accumulation of changes, which is then applied to the current state on commit.
23:51yshui`: like if you do damage, set_buffer_transform, damage, both damage should use the new buffer transform on commit.
23:51yshui`: is that right?