ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
glennk has quit [Ping timeout: 480 seconds]
privacy has quit [Remote host closed the connection]
Guest5675 has quit [Remote host closed the connection]
co1umbarius has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest5809
columbarius has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Guest5809 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest5814
carlos_ has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
axet has joined #wayland
nnm has quit []
nnm has joined #wayland
Guest5814 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest5826
Guest5826 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest5827
sevz has quit [Quit: WeeChat 4.1.1]
CodeSpelunker has joined #wayland
glennk has joined #wayland
CodeSpelunker has quit [Quit: CodeSpelunker]
<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
<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.
rv1sr has joined #wayland
nnm has quit []
nnm has joined #wayland
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
junaid has joined #wayland
privacy has joined #wayland
junaid has quit [Quit: leaving]
junaid has joined #wayland
qaqland is now known as Guest5835
Guest5835 has quit [Read error: Connection reset by peer]
qaqland has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
junaid has quit [Ping timeout: 480 seconds]
qyliss has quit [Quit: bye]
qyliss has joined #wayland
Company has quit [Quit: Leaving]
mblenc has joined #wayland
sima has joined #wayland
carlos_ has joined #wayland
mblenc1 has quit [Ping timeout: 482 seconds]
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
flom84 has joined #wayland
caveman has quit [Remote host closed the connection]
flom84 has quit []
caveman has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
flom84 has joined #wayland
<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.
<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.
privacy has quit [Quit: Leaving]
<karolherbst>
I don't want to repeat myself: enjoy your weekend
rasterman has joined #wayland
Fxzxmic has joined #wayland
Fxzxmic has quit [Quit: Konversation exit!]
Fxzxmic has joined #wayland
flom84 has quit [Quit: Leaving]
Fxzxmic has quit []
Fxzxmic has joined #wayland
Fxzxmic has quit []
Fxzxmic has joined #wayland
caveman has quit [Remote host closed the connection]
rv1sr has quit []
caveman has joined #wayland
Fxzxmic has quit []
Fxzxmic has joined #wayland
luna has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
luna has left #wayland [#wayland]
Fxzxmic is now known as Fxzx_mic
kts has joined #wayland
Fxzx_mic has quit []
Fxzx_mic has joined #wayland
Fxzx_mic is now known as Fxzxmic
Fxzxmic is now known as Fxzx_mic
Fxzx_mic is now known as Fxzxmic
Fxzxmic is now known as Fxzx_mic
Fxzx_mic is now known as Fxzxmic
Fxzxmic is now known as Fxzx_mic
Fxzx_mic has quit [Quit: Konversation exit!]
Fxzx_mic has joined #wayland
Fxzx_mic is now known as Fxzxmic
Fxzxmic is now known as Fxzx_mic
Fxzx_mic has quit []
Fxzx_mic has joined #wayland
Fxzx_mic is now known as Fxzxmic
Fxzxmic is now known as Fxzx_mic
Fxzx_mic is now known as Fxzxmic
Fxzxmic has quit [Quit: Konversation exit!]
Fxzxmic has joined #wayland
Moprius has joined #wayland
sewn has joined #wayland
Guest5827 has quit [Remote host closed the connection]
iomari891 has quit [Remote host closed the connection]
kts has joined #wayland
<pq>
There is no legitimate use case at all for *asking* the latest valid (input) serial, and asking would be racy in itself anyway.
Fxzxmic has quit [Remote host closed the connection]
Fxzxmic has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
babyfaceold has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
caveman has quit [Remote host closed the connection]
<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.
caveman has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
<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.
<pq>
*Your
<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.
<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.
sewn_ has joined #wayland
<pq>
That's the kind of environment where anyone aspiring to color management will grow in.
sewn has quit [Ping timeout: 480 seconds]
<pq>
That's why it's better to think carefully how to say things, or things just spiral out of control.
<DemiMarie>
pq: Is it possible to have conformance tests for compositor rendering?
<pq>
DemiMarie, not generic for everything, no. For some parts, yes, if we can have a common read-back interface.
<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.
<pq>
DemiMarie, compositors are already allowed to manage windows literally any way they want, and that works fine.
<zamundaaa[m]>
Demi: what the compositor does depends on user expectations more than on client expectations
<pq>
exactly
Fxzxmic has quit [Quit: Konversation exit!]
mblenc has quit [Read error: Connection reset by peer]
<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.
sewn_ has quit [Ping timeout: 480 seconds]
pq has quit [Quit: bbl]
maxzor has joined #wayland
kts has quit [Ping timeout: 480 seconds]
qyliss has quit [Quit: bye]
qyliss has joined #wayland
sewn has joined #wayland
sewn has quit [Remote host closed the connection]
glennk has joined #wayland
Arnavion- is now known as Arnavion
<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.
<i509vcb>
Well until this one library needs to handle the several options of renderer
<i509vcb>
And I doubt anyone would be enthusiastic to delegate the entire rendering infrastructure to some library
Ermine has quit [Remote host closed the connection]
Ermine has joined #wayland
kts has joined #wayland
kts has quit [Remote host closed the connection]
pq has joined #wayland
<DemiMarie>
i509vcb: What I want to avoid is a situation where one must be a color management expert to write a compositor.
<JEEB>
there are libraries like libplacebo if you want to externalize the conversion between CICP/H.263 defined values
<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
<JEEB>
uhh, wrong *3, I meant H.273 of course
<i509vcb>
most people who want to write a wm and still use wayland arguably don't care about the entire kitchen, only the sink
<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.
<JEEB>
I guess with tone mapping it's less simple than that
<i509vcb>
libplacebo is LGPL, that might stop some people dead in their tracks
<DemiMarie>
yup
sevz has joined #wayland
<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.
<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.
<zamundaaa[m]>
Demi: applying the inverse EOTF is really not the complicated part of color management, and doesn't buy you a lot
<zamundaaa[m]>
If a given compositor doesn't ever touch the colors in any way it could work though
<zamundaaa[m]>
But then the question is kinda why you're writing a renderer at all in the first place
mblenc has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: bye]
ManMower has quit [Remote host closed the connection]
ManMower has joined #wayland
<emersion>
i509vcb: use wlroots, and then no need to care about this?
<i509vcb>
emersion: the kitchen also includes wlr_allocator, and a bunch of other boilerplate
* emersion
shrug
<i509vcb>
The most comparable thing to what I am doing is probably wayfire
<emersion>
tinywl is pretty tiny
<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
<i509vcb>
Anyways that is probably irrelevant to here tbf
<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
<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
<DemiMarie>
haasn: sounds like color management is much more complex than just doing a conversion on output
<haasn>
I don't know what "just doing a conversion" means
<emersion>
i509vcb: and then you start doing something like libweston, and then complain that it's not flexible enough for you
<haasn>
a 3DLUT can implement any function you want and still qualify as just doing a conversion, no?
<haasn>
regarding the question of how complex color management is, it comes down to expectation
<haasn>
how should out-of-gamut values be handled, for example?
<haasn>
clipped? perceptually tone-mapped?
<haasn>
or should this simply be forbidden, thus making it the clients' problem?
mblenc has joined #wayland
<haasn>
(e.g. disallow displaying HDR content on SDR outputs)
<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?
<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
mblenc has quit [Read error: Connection reset by peer]
mblenc has joined #wayland
<DemiMarie>
haasn: is all of this documented somewhere, in a form non-experts can understand?
mblenc1 has quit [Ping timeout: 480 seconds]
<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
mblenc has quit [Read error: Connection reset by peer]
mblenc has joined #wayland
<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
<DemiMarie>
i509vcb: would you mind explaining?
<i509vcb>
DemiMarie: everything after the comma there is pretty much what I'm trying to say
<DemiMarie>
i509vcb: does this mean that color management control should be left to clients?
mblenc has quit [Ping timeout: 480 seconds]
<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)
<i509vcb>
Anyways I have no idea how any of this works, so I should probably go away
<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.
<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.
mblenc has joined #wayland
<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
<haasn>
this pretty much means, the compositor should just send data as-is, naive clipping, only mathematically strict conversions where necessary
<haasn>
at least when it comes to video, color management will _have_ to be handled by the client
<haasn>
because there are far, far too many moving parts to expose to the wayland compositor or protocol
<haasn>
and if anything, having a "smart" compositor is _detrimental_ to getting good end-to-end accuracy in a color managed client
<DemiMarie>
haasn: I agree 100% with keeping as much complexity out of the compositor as possible.
<DemiMarie>
Compositor writers aren’t color management experts.
keir- has quit []
keir has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
<hch12907>
tbh, being "smart" as a general rule in the software world, are mostly detrimental in the long term
<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".
<hch12907>
* to be "smart" enough to handle the erroneous inputs
<danieldg>
or worse: if it was *wrong* in its smartness, someone will rely on that wrongness eventually