11:42 pq: zamundaaa[m], what do we list as the parametric<->ICC connection implementation?
11:45 zamundaaa[m]: pq: KWin has parametric->ICC transformations
11:46 zamundaaa[m]: The reverse would also be trivially constructed, but it's not used in KWin (yet)
11:47 pq: zamundaaa[m], landing color-management today does feel a bit rushed to me, but let's see how it looks. We also seem to lack a LGTM.
11:47 emersion: enough ack but missing a review?
11:48 zamundaaa[m]: I put a reviewed-by in my last comment
11:49 zamundaaa[m]: Though someone that hasn't contributed to the protocol itself might be more fitting, I think enough people have looked at it by now :)
11:50 emersion: i've skimmed through the protocol but haven't read in detail
11:50 zamundaaa[m]: pq: I don't particularly care if it's today, but it should be very soon. It's been waiting long enough.
11:50 emersion: i also have some non-important nits
11:50 emersion: probably not worth addressing (e.g. interface name for creator being quite long)
11:51 emersion: and surface_feedback being more consistent than feedback_surface (see linux-dmabuf)
11:52 emersion: some clarfications could be added regarding what a compositor should advertise in the image desc info events
11:52 emersion: (right now nothing stops them from sending nothing)
11:52 emersion: (should they send raw values if they send named primaries?)
11:53 zamundaaa[m]: They should send everything that applies
11:53 pq: orowith2os[m], I think grayscale displays can theoretically be reprsented with all the three primaries and white point being the same CIE xy point. Of course, that results in a non-invertible color transformation matrix, which would probably need special consideration.
11:53 zamundaaa[m]: But yeah it would be good to make that more explicit
11:53 emersion: so, name alongside raw values?
11:53 zamundaaa[m]: emersion: yes
11:54 emersion: should or must?
11:54 emersion: the risk is a client not understanding (some) named TFs/primaries?
11:56 zamundaaa[m]: emersion: must I'd say
11:57 pq: orowith2os[m], eInk is very slow to update, and has a relatively small set of possible colors, possibly best described as an enumeration (a palette). We don't have protocol to communicate a palette, but compositors can always approximate RGB colors with the palette. Poorly, perhaps. Color-management protocol might be able to represent some aspects of the limited color selection, but I don't think it would be
11:57 pq: a full solution as is.
11:57 zamundaaa[m]: Spelling out that it must send the closest applicable parametric info if an ICC profile is sent would also be good
11:57 pq: orowith2os[m], we might need to add the concept of a "paletted image description".
11:57 zamundaaa[m]: Otherwise clients that only do parametric would potentially have to drag in an ICC parser
11:58 wlb: weston Merge request !1678 opened by Daniel Stone (daniels) drm: Remove workaround for ancient Mesa GBM issue https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1678
12:01 pq: I haven't read start-to-end through the color-management protocol in a long time, but I'm not sure I feel I need to. I'd probably just spot something to delay it even further. :-p
12:04 pq: zamundaaa[m], re: parametric from ICC; I'd rather not, because if the end user sets up an ICC profile, they likely expect it to be used in full. Output image descriptions are used only by clients that insist doing their own color management. If they cannot handle ICC, they likely cannot do it at a user-acceptable level.
12:06 zamundaaa[m]: pq: the compositor will do the transform from that closest parametric to the ICC profile
12:07 zamundaaa[m]: If the compositor doesn't support parametric, then yeah it doesn't really matter
12:07 pq: but the client intends to do all color management itself, but surprisigly doesn't
12:08 pq: It's really not the same if a client needs to resort to an approximation of the ICC profile.
12:09 zamundaaa[m]: It's not about approximating the ICC profile
12:09 zamundaaa[m]: It's about knowing the gamut that the app can target
12:10 pq: parameteric may not adequately represent the gamut
12:10 zamundaaa[m]: That's okay
12:10 pq: it's not okay for app that need to do their own color management, users expect better
12:11 zamundaaa[m]: Games for example will never support ICC profiles, but they do commonly support rendering to some gamut
12:11 pq: ahh, I see, that kind of use
12:12 pq: okay, I can agree with that
12:14 pq: I was about to say, that ICCv4 (and ICCv2?) define a fallback ordering for the contained tags: use this foremost, but if you cannot then use that, then that, finally that.
12:15 pq: each step of fallback reduces quality in the ICC workflow, but like you said, a compositor can compensate for some of that.
12:16 pq: so it's possible to get the parametric values straight from the ICC profile if the tags are there, IIRC
12:17 zamundaaa[m]: Yes, that's what KWin does
12:18 pq: or maybe you can't... ISTR e.g. LCMS2 classifies a profile as a matrix-shaper by the presence of the matrix-shaper tags rather than the lack of other tags.
12:18 zamundaaa[m]: Except for the TRC, where we just tell the client gamma 2.2 because compositing happens in that space
12:20 pq: that sounds more like the surface preferred image description rather than an output image description, but we also don't have protocol for arbitrary curves other than the ICC file.
12:21 pq: Would it work if the parametric approximation was allowed for preferred image descriptions, but disallowed for output image descriptions?
12:21 pq: of ICC profiles
12:37 wlb: weston Merge request !1679 opened by Erico Nunes (enunes) WIP: Vulkan renderer https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1679
12:47 zamundaaa[m]: pq: for me at least, sure, as I think clients shouldn't use the output image description anyways... but I'm not sure what you hope to achieve with that?
12:47 emersion: why do we have output image desc again?
12:48 pq: a guarantee that an application that chooses to use an output image description actually gets the real output image description rather than an approximation.
12:48 pq: Output image descriptions are for e.g. measurement tooling (display profiling).
12:49 zamundaaa[m]: pq: that's not the case with KWin, and won't be for a while at least
12:49 pq: Also for color-critical apps that insist on doing color management themselves, like, say, Krita, Darktable
12:50 zamundaaa[m]: Actually, can't be in all cases, because ICC profiles don't have a reference luminance?
12:52 pq: That's true. I guess an ICC characterized monitor need to have its reference luminance fixed to the expectation of ICC.
12:54 pq: ICC uses only relative luminance though, so reference white level doesn't matter as long as it doesn't change. It becomes monitor calibration, like monitor contrast adjustment.
12:55 zamundaaa[m]: Anyways, for the output image description, if you send ICC and a parametric approximation, there client still gets the real output image description
12:56 zamundaaa[m]: It's just that clients that can't make any sense of the profile also have something to use instead
12:56 pq: yes, and one could argue that any app wanting to use an output image description should know to never use the approximation.
12:57 pq: if the approximation is good enough, then one should not be looking at an output image description
12:58 pq: I'd like to avoid sending data which has no justified use.
12:58 zamundaaa[m]: Fair enough. I won't complain about giving clients a(nother) good reason to avoid the output image description
12:59 pq: the difference between preferred and output image description has been far too vague, I've seen complaints about it, so this is a very useful discussion
13:00 emersion: another question: should the parametric creator max_ccl/fall be echoed back in info events?
13:00 emersion: there they have a target_ prefix
13:01 emersion: is there a reason for the difference in naming?
13:01 pq: it's a subtle semantic meaning
13:02 zamundaaa[m]: emersion: you can't call get_information on a parametric or icc image description created by the client
13:03 pq: when a client uses an image description, cll and fall describe the content it will post. When a server-create image desctipion carries cll or fall, they are the targets what the client should aim for if it uses the image description.
13:03 pq: that too, yeah
13:03 emersion: oh…
13:03 emersion: i missed that
13:20 wlb: weston/main: Daniel Stone * drm: Remove workaround for ancient Mesa GBM issue https://gitlab.freedesktop.org/wayland/weston/commit/0c31f7dfd28a libweston/backend-drm/drm-gbm.c
13:21 wlb: weston Merge request !1678 merged \o/ (drm: Remove workaround for ancient Mesa GBM issue https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1678)
13:54 gntm: hello, I just like to share my repo with a small compositor, variation of tinywl I've been working on, integrating it with scenefx... is it possible? It's experimental yet
13:56 soreau: gntm: you might ask in #wlroots on liberachat.. there's a list of compositors you could request being added to
13:57 pq: gntm, if you want to send an annoucement to wayland-devel mailing list, go ahead.
13:57 soreau: https://gitlab.freedesktop.org/wlroots/wlroots/-/wikis/Projects-which-use-wlroots
13:58 pq: gntm, just subscribe first so your email gets through without manual moderation.
13:59 gntm: soreau: thanks, I'll try that
13:59 gntm: pq: thanks too, I'll do that
14:00 soreau: gntm: bonus points if you post a video link too :)
15:22 pq: How about I push the historical color-management branch into wayland-protocols as history/color-management? If I have access.
15:26 emersion: that sounds good to me
15:26 emersion: i can do that if you don't have access
15:33 pq: remote: GitLab: You can only use an existing protected branch ref as the basis of a new protected branch.
15:34 emersion: let me create that branch for you
15:34 wlb: wayland-protocols Simon Ser pushed a new branch history/color-management https://gitlab.freedesktop.org/wayland/wayland-protocols/tree/history/color-management
15:34 pq: thanks!
15:35 emersion: force-push enabled
15:36 wlb: wayland-protocols/history/color-management: Pekka Paalanen * 128 commits https://gitlab.freedesktop.org/wayland/wayland-protocols/compare/bd6289c14148a28ddbf147c75a017abdfd19c5be...79ce1c161f6a0f98038f34e60596e3cf350e65bb
15:36 pq: it worked!
15:37 emersion: nice
15:37 pq: I can update it once the MR lands, unless someone beats me to it.
15:38 pq: well, some scripts failed
15:39 pq: remote: remote: /srv/kemper.freedesktop.org/not-for-git/wayland/update-github.sh: 11: shift: can't shift that many
15:42 emersion: yeah, it does that always when you manually push
15:42 emersion: the GitHub repo doesn't exist anyways so shrug
15:42 pq: ok
16:12 pq: Right, I need to leave now, sorry we couldn't land it today I guess. I'll be back on Monday.
20:34 emersion: i feel like i've asked this before, but i don't remember the answer:
20:34 emersion: what exactly does the "Colorspace" KMS connector property do?
20:34 emersion: it seems like it only deals with "colorimetry" when HDR_OUTPUT_METADATA is also set
20:35 emersion: but it's not super clear to me what "colorimetry" means here
20:35 zamundaaa[m]: emersion: it sends the primaries the signal for the display should be interpreted with
20:35 emersion: seems like weston has a knob to set it from the config file and does nothing special
20:35 emersion: ah…
20:36 emersion: but HDR_OUTPUT_METADATA also has primeries right?
20:36 zamundaaa[m]: That's mastering display primaries, to help the display do tone mapping
20:36 emersion: oh, i see
20:36 emersion: that's not spelled out in the docs
20:37 emersion: thanks!
22:25 orowith2os[m]: would anybody happen to be able to comment on Firefox under Wayland with Zink having some protocol errors?
22:26 orowith2os[m]: specifically, trying to create surface syncobjs for surfaces that already have one
22:26 orowith2os[m]: on sway, tearing control objects, same situation
22:26 orowith2os[m]: and then also a "release or acquire point set with no buffer attached" error
22:27 orowith2os[m]: probably some weird interaction between mesa/zink and firefox, but wanted to see if anybody had any insight
22:29 emersion: hm, sounds weird…
22:30 orowith2os[m]: I can reliably reproduce it with Mesa 23.3.1 and newer (haven't tried older), Firefo 134
22:32 orowith2os[m]: switching workspaces and going back to firefox (such that it doesn't get the ability to update frames for a minute) seems to help in the syncobj error
22:32 mclasen: thats a mesa problem
22:34 orowith2os[m]: thought so, if anybody wants to help out, we'll be in #zink
22:41 karenw: How come the tablet-v2 protocol still has objects named 'zwp_*' despite being stable? Shouldn't it be 'wp_*'?
22:45 d_ed[m]: karenw: It could be, but pragmatically that makes a huge workload whilst not accomplishing anything
22:45 d_ed[m]: so we have a bit of a mix right now
22:49 karenw: Fair. It would mean a v3 and making compositors upgrade for no reason but neatness on the protocol side.
23:48 karenw: What hapens if I call set_fullscreen on a toplevel that does not report the fullscreen capability? The compoisotr just responds with a no-op configure and/or no reply, but it's not an error?