ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
navi has quit [Ping timeout: 480 seconds]
navi has joined #wayland
karenw has joined #wayland
feaneron has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
glennk has quit [Read error: Connection reset by peer]
glennk has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
glennk has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
kts has joined #wayland
dviola has quit [Read error: Connection reset by peer]
<bitblt>
has anyone made a wayland client that doesn't leak on shutdown according to valgrind?
<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
<psykose>
does it say lost or 'still reachable'
<psykose>
the latter is not a leak
gusnan has quit [Read error: Connection reset by peer]
feaneron has joined #wayland
feaneron has quit []
gusnan has joined #wayland
bindu_ has joined #wayland
<bitblt>
i found it
<bitblt>
it seems that proxies retrieved with wl_registry_bind() should be freed with the respective *_destroy() functions too
bindu has quit [Ping timeout: 480 seconds]
grinja2 has joined #wayland
<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
garnacho has quit [Remote host closed the connection]
<pq>
bitblt, correct, every object from libwayland-client must be explicitly destroyed.
garnacho has joined #wayland
sima has joined #wayland
<davidre>
Are tablet_pad.buttons and tablet_pad_group.buttons distinct, or does the groups event tell in which group the announced buttons are?
<davidre>
Might be nice to add a sentence to the protocol to clarify
<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
<vyivel>
which doesn't sound that useful tbh
<davidre>
oh yeah array vs number
<davidre>
I guess it makes it easier to answer "how many buttons has this pad"
<vyivel>
ah right
<vyivel>
because pad group buttons exclude compositor-reserved buttons
<emersion>
is there a good explanation regarding tone-mapping, especially how one can implement a basic version?
<pq>
emersion, that's a tough question. ITU-R BT.2408 I guess.
<pq>
*Report
<pq>
just pick "display referred mapping" and ignore the "scene referred mapping"
<pq>
It's a topic I'll be researching "soon".
<emersion>
i see, so the basic version is just multiply by 2.03 i guess
<emersion>
so i don't need to take into account any of the min/max/ref luminance?
<emersion>
nor max_ccl/max_fall?
rgallaispou has quit [Ping timeout: 480 seconds]
<emersion>
seems like HDR→SDR is in a different document
<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
<pq>
that essentially replaces the 2.03 factor
<pq>
min luminance you can ignore for starters
<emersion>
i see
<pq>
max luminance, well, hard-clipping is one way
<pq>
max_cll and max_fall can be ignored for starters, they might be used to e.g. tune the luminance scaling factor
rgallaispou has joined #wayland
<JEEB>
ah, tone mapping. always fun :3
<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
nerdopolis has joined #wayland
<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
<pq>
describe the content like maxFALL sense? or container?
<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"
rgallaispou1 has joined #wayland
rgallaispou1 has left #wayland [#wayland]
<pq>
so, e.g. for recorded content, an actual measurement of gamut boundaries, and not just the mastering nor container bounds?
user21 has joined #wayland
<pq>
zamundaaa[m], swick[m], has anyone started processing the review comments from darkblaze yet?
<pq>
I'll do that now.
<pq>
hmm...
<pq>
these are for the protocol from 2020
<pq>
oh dear, looks like they started reviewing commit by commit
<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
<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
<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
<pq>
zamundaaa[m], do you convert the Ct and Cp components to and from, too?
<zamundaaa[m]>
pq: yes
<zamundaaa[m]>
But you're right, for just tone mapping one could optimize that out
<pq>
I thought so, but now seeing I is in electrical domain makes me wonder.
<pq>
2408 had something about this IIRC
<pq>
no, that was another thing
<pq>
ok, I guess parts of the color differencing matrix roundtrip could be eliminated, but that's all?
<zamundaaa[m]>
yes
feaneron has joined #wayland
pavlushka has quit [Ping timeout: 480 seconds]
pavlushka has joined #wayland
sima has joined #wayland
tzimmermann has quit [Quit: Leaving]
pavlushka has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
Eighth_Doctor has quit [Ping timeout: 480 seconds]
colinmarc has quit [Ping timeout: 480 seconds]
exkc has quit [Ping timeout: 480 seconds]
outfoxxed[m] has quit [Ping timeout: 480 seconds]
akallabeth[m] has quit [Ping timeout: 480 seconds]
Orko[m] has quit [Ping timeout: 480 seconds]
Coelacanthus[m] has quit [Ping timeout: 480 seconds]
d_ed[m] has quit [Ping timeout: 480 seconds]
DemiMarie has quit [Ping timeout: 480 seconds]
davidre has quit [Ping timeout: 480 seconds]
swick[m] has quit [Ping timeout: 480 seconds]
kdn[m] has quit [Ping timeout: 480 seconds]
KamilAronowski[m] has quit [Ping timeout: 480 seconds]
iomari891 has quit [Ping timeout: 480 seconds]
zzxyb[m] has quit [Ping timeout: 480 seconds]
deknos82[m] has quit [Ping timeout: 480 seconds]
orowith2os[m] has quit [Ping timeout: 480 seconds]
leon-anavi has quit [Remote host closed the connection]
rasterman has quit [Remote host closed the connection]
DemiMarie has joined #wayland
DemiMarie is now known as Guest7166
davidre has joined #wayland
kdn[m] has joined #wayland
<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?
<yrlf>
such as wlr_screencopy.copy() or image_copy_capture_frame.attach_buffer()
<emersion>
the "other things" usually indicate whether release is sent or not or undefined
<emersion>
screencopy has a ready event
<yrlf>
ah, right
<yrlf>
I wasn't sure whether the ready event implies the compositor is fully done with the buffer. Thanks, now I know
<yrlf>
thanks for the pointer to the docs, found the relevant info
<emersion>
the newer ext-image-copy-capture protocol should be more explicit
Brainium has joined #wayland
<yrlf>
yep, that one explicitly mentions the release event not being used
<yrlf>
ext-image-copy-capture explicitly sends the correct drm device to use (dmabuf_device), but screencopy doesn't
<yrlf>
should I just use the main_device sent by linux_dmabuf_v1 feedback?
<emersion>
yea
<yrlf>
got it
Calandracas_ has joined #wayland
Calandracas has quit [Read error: Connection reset by peer]
KamilAronowski[m] has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
zzxyb[m] has joined #wayland
<emersion>
hm, so, are monitors in general ignoring Colorspace unless there is a HDR_OUTPUT_METADATA set as well?
<emersion>
it seems like my monitor doesn't behave differently with Colorspace = BT2020_RGB
<JEEB>
some might only work with BT.2020 primaries if transfer is set o PQ (or in rare cases, HLG)
<JEEB>
*set to
<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
<JEEB>
I've never had one so I've enjoyed the "poking in the dark"
<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
feaneron has joined #wayland
<zamundaaa[m]>
emersion: many of them do, yes
<emersion>
hm, sad
<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
<JEEB>
do I recall correctly that the transfer is part of the "HDR metadata" in DRM/KMS?