07:13 pq: emersion, if that's about removing working ABI from a stable library that is evidently also being used in the wild, then how could it be possible? I'm not sure if that's what you're referring to. "Removing" does include "make not work". We can come back to that once we cannot find any user of it anymore, new or *old*. But even it would techincally be a violation of stable ABI rules.
07:15 pq: JoshuaAshton, from that code block, it is impossible for me to see if you are using column- or row-major layout.
07:17 pq: JoshuaAshton, re: scRGB; That's exactly what I'm talking about. I simply cannot assume that scRGB would never be used for bigger than BT.2020 gamut. Instead, the protocol requires applications to be explicit about the actual gamut, or they get the BT.709 gamut. If you as an application *know* it will never be bigger than BT.2020, you are free to say that via protocol when you know nothing else.
07:19 pq: JoshuaAshton, I do not have the luxury of not caring about HLG. Lucky you.
07:19 pq: JoshuaAshton, can you elaborate those industry opinions about HLG? who and why?
07:21 pq: JoshuaAshton, was that only game and game engine developers, or also broadcasting companies?
07:22 pq: or broadcasting tech suppliers or such
07:25 emersion: pq: a build option off by default is not nearly as dramatic
07:25 pq: yes, but what would that achieve?
07:26 pq: it doesn't allow us to drop code, and no distribution would be able to turn it on
07:27 emersion: BSDs for instance might be able to drop once all compositors in their repo have migrated away
07:28 pq: ok
07:29 pq: are there still BSD flavors that do not have working wl_event_loop implementation?
08:03 wlb: wayland Issue #376 opened by Pekka Paalanen (pq) It sounds like wl_surface.damage was deprecated https://gitlab.freedesktop.org/wayland/wayland/-/issues/376 [Protocol]
10:28 pq: Huh. Building libdisplay-info as a Weston meson subproject results in a DSO that exports no symbols. That's not intentional, is it?
10:31 emersion: that doesn't seem correct
10:32 emersion: fwiw i've used libdisplay-info as a wlroots/gamescope subproject without issues
10:32 pq: wonder if some build/link flags from weston leak into display-info that breaks it
10:33 pq: it worked as a static lib, naturally
10:35 emersion: if you add_global_arguments(), it would leak indeed
10:36 emersion: but add_project_arguments() shouldn't
10:36 emersion: project options might leak
10:36 emersion: (you can override these per-subproject)
10:38 pq: I don't see anything odd in the command to link the DSO, and -Wl,--version-script,/home/pq/git/weston/subprojects/display-info/libdisplay-info.map is there too.
10:40 emersion: pq, -fvisibility=hidden
10:40 emersion: in add_global_arguments()
10:40 pq: ooh
10:40 emersion: weston should really use project args here
10:40 pq: yes
10:41 pq: thanks!
10:42 pq: aml and neatvnc don't hit the problem, because they use visiblity=hidden themselves already
10:43 emersion: np!
10:43 emersion: yea that makes sense
11:35 pq: and libdisplay-info
11:54 ifreund: anyone know of real-world clients that unmap and remap their xdg-toplevels?
11:54 ifreund: just trying to get an idea of what semantics clients expect that to have
11:55 ifreund: e.g. should I persist compositor-specific window management state or reset it and behave the same as if it were a new toplevel on re-map
11:57 davidre: ifreund: What do you think of? Clients that delete and create new xdg_toplevels from the same wl_surface?
11:58 ifreund: davidre: clients that commit an empty buffer to the surface (unmapping it) and then do a new initial configure sequence
11:58 ifreund: I really don't see why we chose to allow this in the protocol to be quite honest
11:59 ifreund: but maybe there's a use-case I'm not aware of that justifies the complexity
12:05 wlb: weston Merge request !1229 opened by Pekka Paalanen (pq) Draft: Integrate libdisplay-info (optional at first) https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1229 [Build system], [CI], [DRM/KMS backend]
16:33 emersion: zamundaaa: where did you find the BT.709 to BT.2020 matrices?
16:41 JEEB: i think both itu and arib have a document for that process
16:42 JEEB: they are usually taken step by step tho
16:43 JEEB: so fist matrix to idemtity matrix, and then to the one you need
16:43 JEEB: *first
16:58 zamundaaa[m]: emersion: I convert from BT.709 to XYZ, and then from XYZ to BT2020
16:59 zamundaaa[m]: atm I use pretty much 1:1 the same code as https://github.com/ValveSoftware/gamescope/blob/master/src/shaders/colorimetry.h#L117
20:57 emersion: ack, for some reason i thought you found the final matrix somewhere
20:57 emersion: but seems easy enough to generate (and cleaner)