07:03 JoshuaAshton_: swick[m]: The problem is that no end knows that it's bogus without actually doing analysis on the content which isn't possible unless it is done AOT. It's not as simple as saying "we should never set this in Gamescope/Proton". People can use video players, web browsers, etc in Proton or with Gamescope. I've already explained that you should not use this data for gamut mapping for a multitude of reasons, yet you still seem persistent
07:03 JoshuaAshton_: with the fact that you can. At this point I am past caring arguing about this. It's clear that I am not going to change your mind. If every interaction between us is going to turn into a whole fiasco, then I don't see any reasonable way that we can work together on any color management or Wayland protocol stuff in the future. I'm really really tired of the petty drama that always crops up.
10:01 swick[m]: You still seem to believe that we simply don't understand what you're trying to say and if people understood it, they would all agree. I understand what you're saying. Repeating yourself 5 times doesn't make your arguments more convincing and giving an ultimatum just shows that you're not capable of having reasonable discussions.
10:01 swick[m]: Whenever you don't get your way, you get personal and attack people, trying to frame yourself as a victim of toxic people. The idea that you are part of the problem is never coming to you. I'm cooperating with so many people and a lot of them have and had different views about a lot of things but only with you it always ends badly and I don't treat you any differently from others.
10:09 karolherbst: I don't want to repeat myself: enjoy your weekend
12:50 wlb: weston Issue #838 opened by Jean-Francois BETTE (jf.bette) Launching application in Weston Kiosk from systemd service https://gitlab.freedesktop.org/wayland/weston/-/issues/838
14:51 pq: There is no legitimate use case at all for *asking* the latest valid (input) serial, and asking would be racy in itself anyway.
15:10 pq: JoshuaAshton_, we are very much letting compositors decide policy. Maybe I misunderstood you, but it seems to me you are demanding that we write the spec so that compositors need to ignore metadata. Maybe you also you have read "should" as "must"? There is no "must". MDCV is not the only thing they can use to improve tone mapping by the spec wording either.
15:14 pq: JoshuaAshton_, I'd like to point out that color management is a topic that seems to ruin everyone who touches it. You awesome enthusiasm and energy is working against you here, because everyone else has already more or less burnt out by the previous too energetic and/or too you're-doing-it-wrong screaming people.
15:14 pq: *Your
15:16 pq: Unfortunately, some of those screaming people are sometimes well-known experts on the field as well, and are screaming simply because any deviation from the old workflow is seen as them as a failure and they cannot imagine anything else working ever.
15:17 pq: They have seen too many people making too many mistakes on a complicated topic, and deal with extreme prejudice on anything that even smells a little odd.
15:17 pq: That's the kind of environment where anyone aspiring to color management will grow in.
15:18 pq: That's why it's better to think carefully how to say things, or things just spiral out of control.
15:25 DemiMarie: pq: Is it possible to have conformance tests for compositor rendering?
15:26 pq: DemiMarie, not generic for everything, no. For some parts, yes, if we can have a common read-back interface.
15:26 DemiMarie: I understand that what is ultimately displayed on screen is a matter of compositor policy. However, if compositors are allowed to display literally anything they want, then a compositor that only ever displays a black screen is conformant, which I suspect is not the intent.
15:26 pq: DemiMarie, compositors are already allowed to manage windows literally any way they want, and that works fine.
15:27 zamundaaa[m]: Demi: what the compositor does depends on user expectations more than on client expectations
15:27 pq: exactly
15:29 pq: Color management is also difficult to understand, which means that even if "you're doing it wrong" is true, it could take hours to explain how and why. It doesn't take many people to overwhelm an expert and put them into hostile defensive mode simply trying to stop people from spreading incorrect information or implementations.
16:06 DemiMarie: This sounds like something that should be better handled by a single library used by every compositor, rather than every compositor having to reimplement it from scratch.
16:09 i509vcb: Well until this one library needs to handle the several options of renderer
16:10 i509vcb: And I doubt anyone would be enthusiastic to delegate the entire rendering infrastructure to some library
16:14 DemiMarie: i509vcb: What I want to avoid is a situation where one must be a color management expert to write a compositor.
16:16 JEEB: there are libraries like libplacebo if you want to externalize the conversion between CICP/H.263 defined values
16:16 i509vcb: Yeah there is a definitely problem imo where if someone wants to write a tiling wm under Wayland they need to become an expert. This is largely the rationale behind my compositor implementation
16:16 JEEB: uhh, wrong *3, I meant H.273 of course
16:17 i509vcb: most people who want to write a wm and still use wayland arguably don't care about the entire kitchen, only the sink
16:17 JEEB: of course since effectively you're only going to get a few things out of the available value range, then one thing that's been mentioned before is to just look at the generated shaders by libplacebo, and then utilize that as base.
16:18 JEEB: I guess with tone mapping it's less simple than that
16:20 i509vcb: libplacebo is LGPL, that might stop some people dead in their tracks
16:22 DemiMarie: yup
16:24 DemiMarie: How bad (from a performance perspective) is it to treat color management as a black box? In other words: let a third-party library convert the data to a linear colorspace, do all operations there, and then let that library convert the data again for display.
16:25 DemiMarie: The obvious disadvantage is that it will require more draw calls and more memory bandwidth than an integrated solution, because the data must be copied twice on the GPU.
16:39 zamundaaa[m]: Demi: applying the inverse EOTF is really not the complicated part of color management, and doesn't buy you a lot
16:42 zamundaaa[m]: If a given compositor doesn't ever touch the colors in any way it could work though
16:43 zamundaaa[m]: But then the question is kinda why you're writing a renderer at all in the first place
17:40 emersion: i509vcb: use wlroots, and then no need to care about this?
17:40 i509vcb: emersion: the kitchen also includes wlr_allocator, and a bunch of other boilerplate
17:41 emersion:shrug
17:41 i509vcb: The most comparable thing to what I am doing is probably wayfire
17:41 emersion: tinywl is pretty tiny
17:42 i509vcb: Until you realize that the gap between tinywl and a desktop compositor most people would want to use is probably a few thousand lines more
17:43 i509vcb: Anyways that is probably irrelevant to here tbf
17:43 haasn: libplacebo can also be used to create (static) gamut mapping 3DLUTs ahead-of-time which can then be applied with whatever mechanism one prefers
17:43 haasn: most other CMMs worth their salt can also be used in this way but I don't know of any that offers a C API for it
17:44 DemiMarie: haasn: sounds like color management is much more complex than just doing a conversion on output
17:44 haasn: I don't know what "just doing a conversion" means
17:44 emersion: i509vcb: and then you start doing something like libweston, and then complain that it's not flexible enough for you
17:45 haasn: a 3DLUT can implement any function you want and still qualify as just doing a conversion, no?
17:46 haasn: regarding the question of how complex color management is, it comes down to expectation
17:47 haasn: how should out-of-gamut values be handled, for example?
17:47 haasn: clipped? perceptually tone-mapped?
17:48 haasn: or should this simply be forbidden, thus making it the clients' problem?
17:48 haasn: (e.g. disallow displaying HDR content on SDR outputs)
17:49 haasn: where it gets tricky is when dealing with e.g. a display that supports 99% DCI-P3 (but not 100%), over BT.2020 transport.. should clients be allowed to display DCI-P3 content natively? what should happen to out-of-gamut values? what about DCIP3-in-BT.2020 content?
17:50 haasn: what I would do if I were a compositor author is round close-enough values (e.g. treat my 99% DCI-P3 display as 100% DCI-P3) and forbid sending anything wider gamut than what the display advertises as supported
17:53 DemiMarie: haasn: is all of this documented somewhere, in a form non-experts can understand?
17:56 zamundaaa[m]: I think the expectation that a single person can write a compositor that deals with all this complexity and at the same time deals with these low level decisions doesn't make any sense
17:58 i509vcb: what I'm hearing pretty much is that color management is kryptonite to policy over mechanism, what users expect is not necessarily easy to encode in policy
18:00 DemiMarie: i509vcb: would you mind explaining?
18:01 i509vcb: DemiMarie: everything after the comma there is pretty much what I'm trying to say
18:05 DemiMarie: i509vcb: does this mean that color management control should be left to clients?
18:06 i509vcb: I never asserted one side should deal with color management or not, there are some clear advantages still to having the server do color management (like direct scanout doing color conversion stuff for you)
18:08 i509vcb: Anyways I have no idea how any of this works, so I should probably go away
18:08 DemiMarie: What I am hearing right now is that any compositor that has its own renderer (as opposed to the stock renderers in wlroots/kwin/mutter/mir/smithay) and is not developed by a substantial team is going to get it wrong bigtime, and that is a huge discouragement to anyone who wants to do something requiring custom rendering code.
18:10 DemiMarie: If I am right, then either people will avoid writing custom rendering code even when it would be helpful, or people will not implement color management support properly. Neither is good.
18:14 haasn: to summarize the stance outlined above ^, the intent is to result in a scenario where the only color conversions that may be implemented by the compositor are those which are well-defined, with no room for ambiguity / subjectivity
18:14 haasn: this pretty much means, the compositor should just send data as-is, naive clipping, only mathematically strict conversions where necessary
18:18 haasn: at least when it comes to video, color management will _have_ to be handled by the client
18:18 haasn: because there are far, far too many moving parts to expose to the wayland compositor or protocol
18:18 haasn: and if anything, having a "smart" compositor is _detrimental_ to getting good end-to-end accuracy in a color managed client
18:20 DemiMarie: haasn: I agree 100% with keeping as much complexity out of the compositor as possible.
18:20 DemiMarie: Compositor writers aren’t color management experts.
18:59 hch12907: tbh, being "smart" as a general rule in the software world, are mostly detrimental in the long term
19:01 hch12907: it's highway to having decades of backwards compatibility in your program, that can never be dropped because everyone expects the program to be "smart".
19:02 hch12907: * to be "smart" enough to handle the erroneous inputs
19:07 danieldg: or worse: if it was *wrong* in its smartness, someone will rely on that wrongness eventually
19:07 danieldg: so you can't even fix it
19:45 wlb: wayland Issue #419 opened by Tom Turkey (tomt) black window contagion https://gitlab.freedesktop.org/wayland/wayland/-/issues/419
22:04 wlb: wayland Issue #419 closed \o/ (black window contagion https://gitlab.freedesktop.org/wayland/wayland/-/issues/419)
22:07 wlb: wayland Merge request !353 opened by Simon Ser (emersion) gitlab: make issue template the default https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/353