ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
glennk has joined #wayland
ramblurr_ has joined #wayland
ramblurr has quit [Ping timeout: 480 seconds]
ramblurr_ is now known as ramblurr
CME has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
CME has joined #wayland
narodnik2 has quit [Ping timeout: 480 seconds]
bookworm has quit [Remote host closed the connection]
bookworm has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Quit: bye]
user21 has joined #wayland
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
karenw has quit [Ping timeout: 480 seconds]
user21 has quit [Remote host closed the connection]
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
user21 has joined #wayland
txtsd has quit [Read error: Connection reset by peer]
txtsd has joined #wayland
kode542 has joined #wayland
kode54 has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
kode542 has quit []
kode54 has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
noord has quit [Quit: bye]
noord has joined #wayland
coldfeet has joined #wayland
Fya has quit [Remote host closed the connection]
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
coldfeet has quit [Quit: Lost terminal]
tzimmermann has joined #wayland
tzimmermann has quit []
tzimmermann has joined #wayland
leon-anavi has joined #wayland
pavlushka has joined #wayland
danshick has joined #wayland
sima has joined #wayland
iomari891 has joined #wayland
rgallaispou has joined #wayland
rasterman has joined #wayland
glennk has joined #wayland
grinja1 has quit [Remote host closed the connection]
rgallaispou has quit [Ping timeout: 480 seconds]
grinja1 has joined #wayland
garnacho has joined #wayland
pavlushka has quit [Ping timeout: 480 seconds]
pavlushka has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
miro has joined #wayland
miro has quit [Quit: Page closed]
iomari891 has quit [Quit: WeeChat 4.3.1]
AJ_Z0 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
Moprius has joined #wayland
fmuellner has joined #wayland
feaneron has joined #wayland
kts has joined #wayland
karolherbst is now known as karolherbst[i]
fmuellner has quit []
fmuellner has joined #wayland
<pq>
zamundaaa[m], what do we list as the parametric<->ICC connection implementation?
karolherbst[i] has quit []
karolherbst has joined #wayland
<zamundaaa[m]>
pq: KWin has parametric->ICC transformations
<zamundaaa[m]>
The reverse would also be trivially constructed, but it's not used in KWin (yet)
<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.
<emersion>
enough ack but missing a review?
<zamundaaa[m]>
I put a reviewed-by in my last comment
<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 :)
<emersion>
i've skimmed through the protocol but haven't read in detail
<zamundaaa[m]>
pq: I don't particularly care if it's today, but it should be very soon. It's been waiting long enough.
<emersion>
i also have some non-important nits
<emersion>
probably not worth addressing (e.g. interface name for creator being quite long)
mvlad has joined #wayland
<emersion>
and surface_feedback being more consistent than feedback_surface (see linux-dmabuf)
<emersion>
some clarfications could be added regarding what a compositor should advertise in the image desc info events
<emersion>
(right now nothing stops them from sending nothing)
<emersion>
(should they send raw values if they send named primaries?)
<zamundaaa[m]>
They should send everything that applies
<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.
<zamundaaa[m]>
But yeah it would be good to make that more explicit
<emersion>
so, name alongside raw values?
<zamundaaa[m]>
emersion: yes
<emersion>
should or must?
<emersion>
the risk is a client not understanding (some) named TFs/primaries?
fmuellner has quit [Remote host closed the connection]
<zamundaaa[m]>
emersion: must I'd say
<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
<pq>
a full solution as is.
<zamundaaa[m]>
Spelling out that it must send the closest applicable parametric info if an ICC profile is sent would also be good
<pq>
orowith2os[m], we might need to add the concept of a "paletted image description".
<zamundaaa[m]>
Otherwise clients that only do parametric would potentially have to drag in an ICC parser
<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
paulk-bis has quit []
paulk has joined #wayland
<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.
<zamundaaa[m]>
pq: the compositor will do the transform from that closest parametric to the ICC profile
<zamundaaa[m]>
If the compositor doesn't support parametric, then yeah it doesn't really matter
<pq>
but the client intends to do all color management itself, but surprisigly doesn't
kts has quit [Read error: No route to host]
<pq>
It's really not the same if a client needs to resort to an approximation of the ICC profile.
<zamundaaa[m]>
It's not about approximating the ICC profile
<zamundaaa[m]>
It's about knowing the gamut that the app can target
<pq>
parameteric may not adequately represent the gamut
<zamundaaa[m]>
That's okay
<pq>
it's not okay for app that need to do their own color management, users expect better
<zamundaaa[m]>
Games for example will never support ICC profiles, but they do commonly support rendering to some gamut
<pq>
ahh, I see, that kind of use
<pq>
okay, I can agree with that
<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.
<pq>
each step of fallback reduces quality in the ICC workflow, but like you said, a compositor can compensate for some of that.
<pq>
so it's possible to get the parametric values straight from the ICC profile if the tags are there, IIRC
<zamundaaa[m]>
Yes, that's what KWin does
<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.
<zamundaaa[m]>
Except for the TRC, where we just tell the client gamma 2.2 because compositing happens in that space
<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.
<pq>
Would it work if the parametric approximation was allowed for preferred image descriptions, but disallowed for output image descriptions?
<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?
<emersion>
why do we have output image desc again?
<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.
<pq>
Output image descriptions are for e.g. measurement tooling (display profiling).
<zamundaaa[m]>
pq: that's not the case with KWin, and won't be for a while at least
<pq>
Also for color-critical apps that insist on doing color management themselves, like, say, Krita, Darktable
<zamundaaa[m]>
Actually, can't be in all cases, because ICC profiles don't have a reference luminance?
<pq>
That's true. I guess an ICC characterized monitor need to have its reference luminance fixed to the expectation of ICC.
<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.
<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
<zamundaaa[m]>
It's just that clients that can't make any sense of the profile also have something to use instead
<pq>
yes, and one could argue that any app wanting to use an output image description should know to never use the approximation.
<pq>
if the approximation is good enough, then one should not be looking at an output image description
<pq>
I'd like to avoid sending data which has no justified use.
<zamundaaa[m]>
Fair enough. I won't complain about giving clients a(nother) good reason to avoid the output image description
<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
<emersion>
another question: should the parametric creator max_ccl/fall be echoed back in info events?
<emersion>
there they have a target_ prefix
<emersion>
is there a reason for the difference in naming?
<pq>
it's a subtle semantic meaning
<zamundaaa[m]>
emersion: you can't call get_information on a parametric or icc image description created by the client
<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.
tokyo4j has quit [Remote host closed the connection]
tokyo4j has joined #wayland
<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
<soreau>
gntm: you might ask in #wlroots on liberachat.. there's a list of compositors you could request being added to
<pq>
gntm, if you want to send an annoucement to wayland-devel mailing list, go ahead.
mriesch has quit [Quit: No Ping reply in 180 seconds.]
mriesch has joined #wayland
funderscore is now known as f_
leon-anavi has quit [Quit: Leaving]
feaneron has quit [Ping timeout: 480 seconds]
tlwoerner_ has joined #wayland
tlwoerner has quit [Ping timeout: 480 seconds]
linkmauve has left #wayland [Error from remote client]
pavlushka has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
iomari891 has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
linkmauve has joined #wayland
AJC_Z0 has joined #wayland
AJ_Z0 has quit [Ping timeout: 480 seconds]
AJC_Z0 is now known as AJ_Z0
<emersion>
i feel like i've asked this before, but i don't remember the answer:
<emersion>
what exactly does the "Colorspace" KMS connector property do?
<emersion>
it seems like it only deals with "colorimetry" when HDR_OUTPUT_METADATA is also set
<emersion>
but it's not super clear to me what "colorimetry" means here
sima has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
emersion: it sends the primaries the signal for the display should be interpreted with
<emersion>
seems like weston has a knob to set it from the config file and does nothing special
<emersion>
ah…
<emersion>
but HDR_OUTPUT_METADATA also has primeries right?
<zamundaaa[m]>
That's mastering display primaries, to help the display do tone mapping
<emersion>
oh, i see
<emersion>
that's not spelled out in the docs
<emersion>
thanks!
AJ_Z0 has quit [Quit: I have to return some videotapes]
AJ_Z0 has joined #wayland
karenw has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
karenw_ has joined #wayland
karenw is now known as Guest6797
karenw_ is now known as karenw
Guest6797 has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
would anybody happen to be able to comment on Firefox under Wayland with Zink having some protocol errors?
<orowith2os[m]>
specifically, trying to create surface syncobjs for surfaces that already have one
<orowith2os[m]>
on sway, tearing control objects, same situation
<orowith2os[m]>
and then also a "release or acquire point set with no buffer attached" error
<orowith2os[m]>
probably some weird interaction between mesa/zink and firefox, but wanted to see if anybody had any insight
<emersion>
hm, sounds weird…
<orowith2os[m]>
I can reliably reproduce it with Mesa 23.3.1 and newer (haven't tried older), Firefo 134
<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
<mclasen>
thats a mesa problem
<orowith2os[m]>
thought so, if anybody wants to help out, we'll be in #zink
<karenw>
How come the tablet-v2 protocol still has objects named 'zwp_*' despite being stable? Shouldn't it be 'wp_*'?
iomari891 has joined #wayland
<d_ed[m]>
karenw: It could be, but pragmatically that makes a huge workload whilst not accomplishing anything
<d_ed[m]>
so we have a bit of a mix right now
<karenw>
Fair. It would mean a v3 and making compositors upgrade for no reason but neatness on the protocol side.
feaneron has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
psykose has quit [Remote host closed the connection]
glennk has quit [Read error: Connection reset by peer]
bindu_ has joined #wayland
bindu has quit [Ping timeout: 480 seconds]
<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?