09:51 bitblt: hello there
09:52 bitblt: has anyone made a wayland client that doesn't leak on shutdown according to valgrind?
09:53 bitblt: I get some leaks inside wayland-client wl_registry_bind() -> proxy_create() that even when I do wl_registry_destroy() valgrind still shows that are not freed
09:57 psykose: does it say lost or 'still reachable'
09:57 psykose: the latter is not a leak
10:04 bitblt: i found it
10:04 bitblt: it seems that proxies retrieved with wl_registry_bind() should be freed with the respective *_destroy() functions too
10:05 bitblt: i was specifically missing wl_compositor_destroy(), xdg_wm_base_destroy() and wl_shm_destroy(), it seems that wl_registry_destroy() is not enough
11:22 wlb: weston Merge request !1680 opened by Michael Olbrich (mol) backend-headless: use weston_output_arm_frame_timer() https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1680 [Headless backend]
12:12 pq: bitblt, correct, every object from libwayland-client must be explicitly destroyed.
12:34 davidre: Are tablet_pad.buttons and tablet_pad_group.buttons distinct, or does the groups event tell in which group the announced buttons are?
12:35 davidre: Might be nice to add a sentence to the protocol to clarify
12:36 vyivel: zwp_tablet_pad_v2.buttons is just a number, which i presume means how many buttons there are in total across all pad groups
12:36 vyivel: which doesn't sound that useful tbh
12:37 davidre: oh yeah array vs number
12:38 davidre: I guess it makes it easier to answer "how many buttons has this pad"
12:38 vyivel: ah right
12:38 vyivel: because pad group buttons exclude compositor-reserved buttons
12:47 emersion: is there a good explanation regarding tone-mapping, especially how one can implement a basic version?
12:48 pq: emersion, that's a tough question. ITU-R BT.2408 I guess.
12:49 pq: *Report
12:49 pq: just pick "display referred mapping" and ignore the "scene referred mapping"
12:51 pq: It's a topic I'll be researching "soon".
12:55 emersion: i see, so the basic version is just multiply by 2.03 i guess
12:55 emersion: so i don't need to take into account any of the min/max/ref luminance?
12:55 emersion: nor max_ccl/max_fall?
12:57 emersion: seems like HDR→SDR is in a different document
12:58 pq: ref luminance would be good to use, all input images should be scaled so that their respective ref luminance maps to the output ref luminance
12:58 pq: that essentially replaces the 2.03 factor
12:58 pq: min luminance you can ignore for starters
12:59 emersion: i see
12:59 pq: max luminance, well, hard-clipping is one way
13:00 pq: max_cll and max_fall can be ignored for starters, they might be used to e.g. tune the luminance scaling factor
13:09 JEEB: ah, tone mapping. always fun :3
13:11 JEEB: reminds me how long it took for me to understand why on earth there was mastering display metadata that did not directly describe the video content
13:11 JEEB: but all that can be ignored in a basic implementation, after all last I tested windows was pretty much doing the simple clip-to-HDR-graphics-white way in the compositor as well
13:12 pq: describe the content like maxFALL sense? or container?
13:13 JEEB: maxFALL sense. but yes, I did then later understand that it was describing content indirectly by "if the mastering person didn't have this wide of a gamut or nits capability, then you don't necessarily have to care, either"
13:16 pq: so, e.g. for recorded content, an actual measurement of gamut boundaries, and not just the mastering nor container bounds?
13:28 pq: zamundaaa[m], swick[m], has anyone started processing the review comments from darkblaze yet?
13:31 pq: I'll do that now.
13:35 pq: hmm...
13:37 pq: these are for the protocol from 2020
13:46 pq: oh dear, looks like they started reviewing commit by commit
14:18 wlb: weston Merge request !1681 opened by Loïc Molinari (molinari) tests: Improve asserts https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1681 [Testing]
14:26 zamundaaa[m]: emersion: how to do tone mapping depends a lot on how much you trust the HDR metadata of content and the display, and how much overhead you want to accept for it
14:28 zamundaaa[m]: KWin converts everything to ICtCp and then applies a mapping curve depending on the reference luminance and max. mastering display luminance, which is so far good enough in practice
14:29 zamundaaa[m]: At least we haven't gotten any complaints except for when a game reported very wildly wrong HDR metadata, which was easy enough to detect
14:36 pq: zamundaaa[m], do you convert the Ct and Cp components to and from, too?
14:38 zamundaaa[m]: pq: yes
14:38 zamundaaa[m]: But you're right, for just tone mapping one could optimize that out
14:40 pq: I thought so, but now seeing I is in electrical domain makes me wonder.
14:41 pq: 2408 had something about this IIRC
14:45 pq: no, that was another thing
14:46 pq: ok, I guess parts of the color differencing matrix roundtrip could be eliminated, but that's all?
14:47 zamundaaa[m]: yes
20:16 yrlf: does wl_buffer::release get sent only after wl_surface attach/commit or does this event also get sent for other things that take wl_buffers?
20:17 yrlf: such as wlr_screencopy.copy() or image_copy_capture_frame.attach_buffer()
20:17 emersion: the "other things" usually indicate whether release is sent or not or undefined
20:17 emersion: screencopy has a ready event
20:18 yrlf: ah, right
20:19 yrlf: I wasn't sure whether the ready event implies the compositor is fully done with the buffer. Thanks, now I know
20:19 yrlf: thanks for the pointer to the docs, found the relevant info
20:20 emersion: the newer ext-image-copy-capture protocol should be more explicit
20:25 yrlf: yep, that one explicitly mentions the release event not being used
20:26 yrlf: ext-image-copy-capture explicitly sends the correct drm device to use (dmabuf_device), but screencopy doesn't
20:27 yrlf: should I just use the main_device sent by linux_dmabuf_v1 feedback?
20:27 emersion: yea
20:27 yrlf: got it
21:14 emersion: hm, so, are monitors in general ignoring Colorspace unless there is a HDR_OUTPUT_METADATA set as well?
21:14 emersion: it seems like my monitor doesn't behave differently with Colorspace = BT2020_RGB
21:15 JEEB: some might only work with BT.2020 primaries if transfer is set o PQ (or in rare cases, HLG)
21:15 JEEB: *set to
21:16 JEEB: in these cases it's useful to have either debug output from the TV where it shows the exact values over the wire, or some sort of man-in-the-middle dongle that logs the values
21:16 JEEB: I've never had one so I've enjoyed the "poking in the dark"
21:17 JEEB: since there is always the possibility that you're setting the value in DRM/KMS land, but then nothing gets pushed over the wire
21:19 zamundaaa[m]: emersion: many of them do, yes
21:19 emersion: hm, sad
21:19 zamundaaa[m]: In our GUI we don't expose them as separate options for that reason, and I left setting them separately as a cmd / config option
21:22 JEEB: do I recall correctly that the transfer is part of the "HDR metadata" in DRM/KMS?
21:23 emersion: yes
21:23 JEEB: right
21:32 wlb: wayland Merge request !450 opened by Sebastian Wick (swick) wayland-shm: Keep resized shm pool data mappings valid https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/450
21:35 wlb: wayland Merge request !451 opened by Sebastian Wick (swick) shm: Add helpers for accessing shm pools https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/451