06:56wlb: wayland Issue #534 opened by groveer (Groveer) Why Isn't the debug_handler Method Exposed for Configuration? https://gitlab.freedesktop.org/wayland/wayland/-/issues/534
07:23wlb: wayland Merge request !466 opened by groveer (Groveer) log: expose wl_debug_handler for custom print debug message https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/466
10:05wlb: weston Merge request !1712 opened by Loïc Molinari (molinari) gl-renderer: Fix SHM RGB888 and BGR888 endianness https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1712 [Clients], [GL renderer], [Testing]
10:11swick[m]: zamundaaa: great blog post! https://zamundaaa.github.io/colormanagement/2025/03/31/about-brightness.html
10:12swick[m]: that was on my list for a while now, so I'm happy I can just point people at this :)
10:13swick[m]: but I also wonder if we can add it to the color-and-hdr repo somehow
10:15paulk: swick[m]: I'd be interested to know if it's actually correct to convert sRGB to Rec.709 with a linear operation that doesn't account for the gamma 2.2 to gamma 2.4 change
10:16paulk: because that's apparently what is done most of the time
10:17Company: that depends on your definition of "correct"
10:17Company: mathematically correct: no
10:18Company: good enough so people don't see the difference on an average monitor: yes
10:18swick[m]: also I guess you mean decoding a sRGB signal with BT.1886?
10:18paulk: well BT.1886 is used for both sRGB and Rec.709
10:18paulk: Company: yes I mean mathematically correct :)
10:18Company: good enough so people doing this for a living don't see this on a modern HDR monitor: uh oh
10:19paulk: hehe
10:19swick[m]: if you do decode sRGB with BT.1886 then there is a mismatch. it can be intentional.
10:19paulk: that being said it could be implemented with a LUT with little cost
10:20paulk: swick[m]: IIRC BT.1886 is the EOTF, not the OETF
10:20swick[m]: yes...?
10:20Company: (LUT works as long as you use 8bit or 10bit)
10:21paulk: swick[m]: well it's implied in sRGB that it's shows on BT.1886 monitor, isn't it?
10:21paulk: shown*
10:22paulk: so it's not about "decoding sRGB" it's really about the screen that's plugged in
10:22paulk: or did I misunderstand something?
10:22swick[m]: it's more subtle than that. you can't just decode any signal with any EOTF and expect it to produce something sensible
10:23swick[m]: i.e. if you decode a bt2100 signal with bt.1886 you get a pretty bad result
10:23paulk: right so that's why both sRGB and Rec.709 specify both the OETF and EOTF
10:23paulk: well bt2100 doesn't specify that that bt.1886 should be used
10:23paulk: so yeah if you're mixing two specs it's a mismatch
10:23paulk: we agree I think :)
10:24Company: best thing to do: get a bunch of bytes and a tool that can convert stuff correctly and then tag that data with all the different options
10:24Company: and see how much the results differ
10:24swick[m]: I'm unsure if sRGB specifies bt.1886 as possible EOTF
10:25paulk: swick[m]: AFAIK it's the only one that's specified
10:25JEEB: H.273 only mentions BT.1886 as the EOTF for specific ones that are video related, sRGB is not one of those values.
10:25swick[m]: but yeah, there can be multiple EOTFs to use for one signal. the important point then however is that they can have different reference viewing environments.
10:25JEEB: not to mention that previously the only interpretations for sRGB were piecewise VS gamma 2.2 (reference display)
10:25paulk: oh I see, didn't think about viewing environments
10:26swick[m]: which is why I'm saying that the mismatch between encoding and (different) decoding can be intentional to adjust the signal to the viewing environment
10:27paulk: okay, good to know!
10:27swick[m]: but it should indeed be specified that an encoding and decode can be used together
10:27swick[m]: and JEEB probably knows better which ones are specified to work together than me
10:29JEEB: https://www.itu.int/rec/T-REC-H.273-202407-I/en
10:29swick[m]: right, that suggests that using BT.1886 to decode sRGB is not specified and you probably shouldn't do that
10:30JEEB: the only place where I've heard of where sRGB might get decoded as BT.1886 is apple's "SDR content transfer function" override, which does indeed let you set BT.1886 as one of the EOTFs
10:31JEEB: but that is just an override
10:31paulk: so sRGB has its own EOTF then?
10:32swick[m]: gamma 2.2, yes
10:35JEEB: which definitely has not been clear to people since even MS implemented it piecewise ;)
10:35swick[m]: MS also implemented PQ without adapting it to the actual viewing environment
10:36JEEB: that's another common mis-thought ;)
10:36JEEB: "no the signal says it's 413 nits, so it must be delivered to display as 413 nits signal!!!!"
10:36swick[m]: you can almost do the opposite what MS is doing with color and you're on the right track
10:59zamundaaa[m]: swick: thank you! Took a while to write :)
10:59pq: zamundaaa[m], are you https://fosstodon.org/@Zamundaaa@discuss.tchncs.de ?
11:00pq: zamundaaa[m], an excellent post indeed
11:04zamundaaa[m]: pq: yes
11:18wlb: weston/main: Loïc Molinari * gl-renderer: Fix SHM RGB888 and BGR888 endianness https://gitlab.freedesktop.org/wayland/weston/commit/6bbc6c12565a clients/simple-shm.c libweston/pixel-formats.c tests/shm-buffer-test.c
11:18wlb: weston Merge request !1712 merged \o/ (gl-renderer: Fix SHM RGB888 and BGR888 endianness https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1712)
12:00yppy: are the unstable protocols that are implemented everywhere treated the same as staging now?
12:01yppy: ie. they won't be broken in the future if stabilized
12:02davidre: yes
12:02emersion: yeah, although we don't do a good job at migrating them to stable
12:02yppy: okay
12:02davidre: see for example dmabuf which didn't get a break removing the "z"
12:03yppy: that's fine i just think it should be documented
12:03yppy: since currently they say they will
12:03yppy: and the readme didn't make it clear to me
12:03yppy: anyway thx
12:04mclasen: it would be nice if the color coding in https://wayland.app/protocols/ reflected the actual stability of things
12:07zamundaaa[m]: yppy: there isn't really anything "now" about it, the warning has always been a bit misleading
12:08zamundaaa[m]: Once a protocol is merged, backwards incompatible changes can't ever be made to it, it can only be replaced
12:29jadahl: yppy: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/252 intended to make that more obvious
13:21karenw: There's now so many compositors on wayland.app, the `Compositor Support` section has a horizontal scrollbar. That's a lot of compositors
13:22kennylevinsen: the list is still very much incomplete
13:23psykose: why is louvre the library there when the others are compositors
13:23davidre: karenw: you need a wider monitor^^
13:23karenw: In the words of wikipedia "[This list] may never be able to satisfy particular standards for completeness."
13:25karenw: davidre: I don't think wider in the sence of a larger physical screen size, aspect ratio (16:10), or logical resolution (i.e. after DPI scaling) would meet my requirements for usability.
13:25karenw: I could set the dpi to some arbitary low figure though ;)
13:26davidre: Seems to fit at least on my bog standard 1080p one
13:27davidre: of course fonts also matter probably
13:28karenw: 1920x1080 at whatever dpi "125%" is in kwin.
13:29karenw: *1920x1200
13:38davidre: kentrl is now just copy pastaing old comments...
13:45wlb: weston/main: Pekka Paalanen * 8 commits https://gitlab.freedesktop.org/wayland/weston/compare/6bbc6c12565a8838270116d84044fa3c5d68c09d...b872c71820783ae5e582e9bbbca2133fee4235ed
13:45wlb: weston Merge request !1707 merged \o/ (libweston: introduce linalg.h https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1707)
13:46wlb: weston Issue #311 closed \o/ (Test harness re-design, step 2: asserts, checks, and runners https://gitlab.freedesktop.org/wayland/weston/-/issues/311)
14:14wlb: weston/main: Loïc Molinari * gl-renderer: Init output borders with transparent pixels https://gitlab.freedesktop.org/wayland/weston/commit/5a568568666f libweston/renderer-gl/gl-renderer.c
14:14wlb: weston Merge request !1711 merged \o/ (gl-renderer: Init output borders with transparent pixels https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1711)
15:05wlb: weston Merge request !1713 opened by Erico Nunes (enunes) clients/simple-egl: trivial cleanup fixes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1713
19:27emersion: pq: does it make sense to make configurable the render intent of an ICC profile used for an output, set in the config file?
21:45wlb: wayland Issue #535 opened by 64-bitman (64-bitman) Memory leak from wl_display_read_events when display connection is lost https://gitlab.freedesktop.org/wayland/wayland/-/issues/535