00:58 Company: it's gonna make a lot of people very unhappy if that doesn't work with the GTK offloading stuff
00:59 Company: because there's tons of apps that dynamically switch between subsurfaces and GTK compositing rather frequently
01:00 Company: rounded corners do that to people
01:06 JoshuaAshton: good to know that it's not just us that needs this then
01:07 JoshuaAshton: I think it's fine if it doesn't make the initial pass for the protocol (something something feature/scope creep) tho
01:21 Company: I've designed that whole stuff under the assumption that GTK's compositing code is identical to the compositors
01:21 Company: it's shaders all the way down, so we can just make sure we use the same ones
02:02 zamundaaa[m]: You can't assume subsurfaces do the same thing as compositing even without color management
02:02 zamundaaa[m]: The scaling algorithm with viewporter is implementation defined for example, and so is the blending function
08:18 wlb: weston Issue #877 opened by diegonieto (diegonieto) Screen capture in a single output https://gitlab.freedesktop.org/wayland/weston/-/issues/877
10:37 wlb: wayland Issue #440 opened by Julian Orth (mahkoh) Re-using interfaces across protocols https://gitlab.freedesktop.org/wayland/wayland/-/issues/440
10:42 swick[m]: zamundaaa: the end goal should always be to make it possible for offloading to be entirely transparent
10:43 pq: JoshuaAshton, yes, please chime in on https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/23 , https://gitlab.freedesktop.org/swick/wayland-protocols/-/issues/11 , https://gitlab.freedesktop.org/swick/wayland-protocols/-/issues/12 , and things linked from there. The reference white is WIP, https://gitlab.freedesktop.org/swick/wayland-protocols/-/merge_requests/44 .
10:43 swick[m]: but yeah, we don't even properly communicate premult, YCbCr conversion, subsampling position, etc etc
10:43 swick[m]: long way to go
10:44 swick[m]: the whole color management thing is going to make this much harder even
10:44 swick[m]: but eh, let's start somewhere
10:45 swick[m]: JoshuaAshton: the assumption in the protocol right now is that everything is SDR, except if PQ is chosen as TF because that ties itself to a specific viewing environment
10:46 swick[m]: but that also means that if you choose PQ, you can't just randomly chose other reference white levels because then it won't be PQ anymore
10:47 swick[m]: except if we explicitly communicate the min/max and reference white levels
10:47 swick[m]: which is exactly what !44 is trying to do
10:51 pq: swick[m], they were talking about sub-surfaces vs. client-side composition results being expected identical.
10:52 pq: and arbitraryly switching between those two. Not KMS off-loading.
10:54 pq: swick[m], right, IOW right now "PQ" means BT.2100/PQ system, while in the future once we communicate the levels "PQ" reduces to mean PQ TF. Right?
10:55 pq: I wonder if the same applies with HLG...
10:58 pq: Company, no, you definitely cannot ever switch between sub-surfaces and client-side composition while expecting the end result on screen to not change. KMS API has the transparent switching property, but Wayland design is based on not having that property.
11:02 swick[m]: uh, I should probably avoid saying "offloading". From the client perspective, offloading means pushing some compositing work to the compositor using subsurfaces, from the compositor perspective it means pushing work to KMS
11:03 swick[m]: yes, subsurface offloading doesn't have the property... now. I'm of the opinion that it should be the goal eventually
11:03 swick[m]: buy we're just figuring out how do composite stuff properly right now so it's just too early to make any guarantees
11:05 swick[m]: in the protocol you literally set the PQ transfer characteristics which, unlike all other systems, implies a certain luminance in the reference viewing environment
11:06 swick[m]: or to put it another way, there is no way to say "the PQ TF" without also implying "the PQ system"
11:08 swick[m]: to be fair, other systems also define absolute luminances in a reference viewing environment, but they don't couple it that closely and are often not defined with the same rigor
11:08 swick[m]: so just saying "SDR" for everything else is prooobably good enough
11:10 swick[m]: in general, I don't think it would be wrong to say "the TF implies an absolute luminance level for a specific code value in the reference viewing environment"
11:10 JEEB: and for the graphics white level, that's mostly for mapping SDR graphics white components onto HDR image.
11:10 JEEB: yea, mentioning the ref. viewing environment lets you say that
11:11 swick[m]: yeah, my point is that this is mostly true for all TFs but becomes really loosely defined in a lot of cases
11:11 swick[m]: which is why one would usually just lump them into the "SDR" category and be done with it
11:11 swick[m]: the details here don't matter that much
11:14 pq: I think it is a bad idea to define the exact mathematics of how every compositor will have to handle all types of content, pixel-composition-wise. Starting with e.g. scaling algorithms. This would also restrict KMS off-loading.
11:14 swick[m]: I think it would be a good idea in the long term to let the clients know which algorithms are used in the compositor to make it possible to match it
11:15 pq: I think a much more feasible goal is to create a single compositing library used by literally all compositors that make the promise.
11:15 pq: then we must re-design Wayland to be prescriptive
11:16 pq: and turn Wayland into a drawing API
11:16 swick[m]: not really. you just let the clients know about the algorithm used and have a "unknown" escape hatch. everything stays prescriptive.
11:16 pq: I don't see that as a good idea. We lose all the flexibility.
11:17 pq: you mean descriptive?
11:17 swick[m]: you don't loose any flexibility because you can just say "unknown"
11:18 pq: but "unknown" means clients won't work
11:18 swick[m]: you can still do whatever you want, it just gives clients the possibility of matching some compositors
11:18 swick[m]: yes
11:18 pq: then lots of people complain why each compositor is choosing whatever and not the other thing that they do
11:19 swick[m]: so? the situation is already true right now
11:19 pq: implying there is that possibility will probably make lots of people demand it
11:19 pq: no, it's not, because we do not even pretend it could be possible.
11:19 swick[m]: dunno, this just changes that you have to target one compositor and can start targeting groups of compositors
11:20 pq: we've always said that clients cannot guarantee to mimick compositor results. Do not switch between sub-surfaces and single-surface, if you expect the same result. That has been it from the day sub-surfaces were invented.
11:20 swick[m]: I mean, sure, you said that at some point
11:20 swick[m]: doesn't mean it always has to stay true
11:20 swick[m]: anyway, too far into the future to loose much thought over it
11:23 pq: I fear people don't understand the "far future", they demand it now
11:26 pq: what we should do is to make sure that there is no reason to *switch at runtime* between sub-surfaces and client-side composition on the same window while it's mapped.
11:27 swick[m]: you should talk with Company about how realistic that is
11:29 pq: how could that change anything?
11:30 pq: I so wish all this talk was in Gitlab or email, and not in IRC, too.
11:30 JEEB: meanwhile it seems like various SMPTE ST specs have become free on their site: the 2094 series for dynamic HDR metadata, ST2084 and ST2086 for the base static ones.
11:31 JEEB: f.ex. https://ieeexplore.ieee.org/document/7513361 , https://ieeexplore.ieee.org/document/9405553 and https://ieeexplore.ieee.org/document/9095450
11:32 swick[m]: neat
11:33 pq: swick[m], HLG does imply a specific luminance in the reference viewing environment with the reference display too. It just specifies the luminance generalization outside of that too, while PQ does not. But I think we should try the HLG generalization on PQ content as well.
11:34 JEEB: -10 being the D one and -40 being Samsung's HDR10+
11:34 JEEB: re HLG: apparently the image folk are defining their own version of it as well
11:34 pq: swick[m], yes, there is "only PQ TF" without the PQ system, then you explicitly define all the things that the PQ system would otherwise define.
11:35 swick[m]: eh, sure... the primaries, YCbCr stuff etc etc
11:35 swick[m]: but the TF implies a luminance on the reference display in the reference viewing environment
11:36 pq: I was specifically thinking of min/max/reference luminances.
11:36 pq: and the viewing environment
11:37 swick[m]: if you just take the curve and not the luminance at a certain signal level then it's just not the PQ TF anymore
11:37 swick[m]: they closely coupled this, unlike all other specs
11:37 swick[m]: but tbh, I don't think it matters
11:38 pq: one can still use PQ TF for encoding content for non-standard viewing environment and non-standard display luminance capabilities. The curve still gives you cd/m², and you still interpret that wrt. to the given viewing environment and display capabilities - they just happen to be not the reference ones.
11:38 swick[m]: yes, you can, but then it's not PQ anymore
11:39 swick[m]: which is completely fine
11:39 swick[m]: I don't think we disagree with anything, it's just a matter of naming
11:41 pq: yes, what to call the TF used in the PQ system
11:43 pq: color-management protocol extension currently conflates TFs and systems
11:50 swick[m]: in the sense that it implies an absolute luminance at some signal level in the reference viewing environment, yes
11:50 swick[m]: we could make them two separate things
11:51 swick[m]: let the TF only imply the actual curve, and have another property for the luminances and viewing environment
11:51 swick[m]: instead of having a sort of "override"
11:51 swick[m]: which !44 is trying to do
11:51 pq: right
11:52 pq: what to call the curve used by the PQ system, without confusing most people?
11:56 daniels: pqurve
12:12 pq: JEEB, thanks for those links. I wish I never need to study them, but I saved them. :-)
12:19 emersion: seems like some downstreams monkey-patch the upstream protocols :(
12:19 emersion: https://github.com/nxp-imx/wayland-protocols-imx/commit/a104fb66d1b899dc04077422c2204638675ee4a6
12:20 emersion: and that results in fireworks when compiling regular compositors against this ofc
12:21 pq: I wish I was surprised.
12:21 emersion: clearly i haven't done enough embedded stuff
12:22 pq: I haven't either, but I've heard the rumours of weston butchery.
12:24 pq: a double-facepalm for copying the docs of a different request and not bothering to even delete them.
12:24 emersion: :D
12:37 kennylevinsen: heh, a lazy botch - but it might not have been intentional, could just be that they didn't know that it was easy to do right with a vendor protocol
12:38 daniels: vendor downstreams are very much averse to creating new things, and very happy to hack up existing things
12:39 pq: because it's "less maintenance"?
12:41 daniels: some more creatively than others https://github.com/JeffyCN/rockchip_mirrors/blob/buildroot/package/weston/0021-HACK-xdg-shell-Support-setting-window-position.patch
12:41 daniels: https://github.com/JeffyCN/rockchip_mirrors/blob/buildroot/package/weston/0034-HACK-Support-setting-surface-flags-activate-and-alph.patch
12:42 kennylevinsen: from sitting on the other side of the table, usually it's just a matter of shipping feature XYZ with the least effort/by people not intimate with the projects they modify
12:45 kennylevinsen: you can hack something that exists without spending the time to understand it... but in this case it's not really harder to just fork the protocol or make an addition. :/
12:45 kennylevinsen: s/make an addition/make a supplementary protocol/
12:45 kennylevinsen: so I imagine they wouldn't have minded doing it right knowing that
12:47 daniels: yep
12:47 daniels: and both NXP and Rockchip are actually contributing stuff upstream, which is nice
12:47 daniels: there's some really useful stuff in the Rockchip tree in particular which I'd like to get upstream
12:48 daniels: as well as some terrifying-but-cool hacks like 'if the opaque region contains a (-1,-1,1,1) rect, then actually interpret the opaque region as a transparent region' which I don't want upstream in _that_ form, but having the functionality would be good
12:49 kennylevinsen: o.O
12:52 JEEB: pq: yea not sure how much those specifically show up in wayland since I think MS just meh'd and moved on to opaque buffers with the dynamic HDR things (incomplete API etc)
12:52 JEEB: the ST2084 and ST2086 stuff IIRC contains the calculation method of luminance etc so in that sense those could be more useful day-to-day
12:54 JEEB: 2084 being https://ieeexplore.ieee.org/document/7291452 and 2086 being https://ieeexplore.ieee.org/document/7291707 , although the latter is marked as superceded?
12:55 JEEB: ah there is a 2018 edition which I was not able to find from the IEEExplore? https://pub.smpte.org/pub/st2086/st2086-2018.pdf
12:58 pq: oh, those are free now as well, cool
12:59 pq: that SMPTE logo is funny btw... one could read it as "film in, SMPTE does magic, pixel garbage out" :-p
13:00 JEEB: :D
13:00 JEEB: indeed
13:01 emersion: "enhance!"
13:01 JEEB: rainbow https://upload.wikimedia.org/wikipedia/commons/4/48/Daala_Rainbow_Vomit_Tiger.png
14:16 wlb: weston/main: Leandro Ribeiro * tests: move functions that create ICC profiles to lcms_util.c https://gitlab.freedesktop.org/wayland/weston/commit/ac3e41640227 tests/ color-icc-output-test.c lcms_util.c lcms_util.h
14:16 wlb: weston/main: Leandro Ribeiro * tests: add helpers to create unique filenames https://gitlab.freedesktop.org/wayland/weston/commit/d29f904bec28 tests/ weston-test-client-helper.c weston-test-client-helper.h weston-test-runner.c weston-test-runner.h
14:16 wlb: weston/main: Leandro Ribeiro * tests: make use of helpers to create unique filenames https://gitlab.freedesktop.org/wayland/weston/commit/bac9060d5429 tests/ color-icc-output-test.c drm-writeback-screenshot-test.c internal-screenshot-test.c weston-test-client-helper.c weston-test-client-helper.h
14:16 wlb: weston Merge request !1453 merged \o/ (Test suite changes related to ICC profiles https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1453)