ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
andreasbackx has quit [Remote host closed the connection]
Brainium has quit [Quit: Konversation terminated!]
mxz has quit [Ping timeout: 480 seconds]
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest4639
Guest4639 has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
Fxzxmic has joined #wayland
privacy has quit [Quit: Leaving]
cool110 has joined #wayland
cool110 is now known as Guest4641
Fxzxmic has quit [Remote host closed the connection]
Fxzxmic has joined #wayland
kts has joined #wayland
Guest4641 has quit [Remote host closed the connection]
mxz has joined #wayland
tzimmermann has joined #wayland
kts has quit [Quit: Leaving]
mclasen has joined #wayland
kts has joined #wayland
mblenc1 has quit [Remote host closed the connection]
mblenc has joined #wayland
cool110_ has joined #wayland
cool110_ is now known as Guest4645
leon-anavi has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
kts has quit [Ping timeout: 480 seconds]
Guest4645 has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
klausvalka has joined #wayland
garnacho has joined #wayland
kts has joined #wayland
sima has joined #wayland
learn-wayland has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest4653
<learn-wayland>
can someone point me to good resource to install wayland in debain. I don't want any wm or de with it as I want to test my own build of sway!
rasterman has joined #wayland
kts_ has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts_ has quit []
<RAOF>
learn-wayland: "sudo apt build-dep sway"? If you're building sway then you just need the build-dependencies of Sway.
Guest4653 has quit [Ping timeout: 480 seconds]
<learn-wayland>
rolf: will installing wayland to my x11 debain system break something?
manuel1985 has joined #wayland
kts has joined #wayland
klausvalka has quit [Remote host closed the connection]
kts has quit [Remote host closed the connection]
kts has joined #wayland
lbia has quit [Quit: lbia]
glennk has quit [Ping timeout: 480 seconds]
<YaLTeR[m]>
didn't you hear? Wayland breaks everything!
<YaLTeR[m]>
On a more serious note, no, it won't
<learn-wayland>
YaLTeR[m]: hahaha thanks I'm new to this thing so please don't mind.
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
cool110_ has joined #wayland
cool110_ is now known as Guest4655
kts has quit []
learn-wayland has quit []
Guest4655 has quit [Ping timeout: 480 seconds]
leonanavi has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest4659
leon-anavi has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
tanty has quit [Quit: Ciao!]
manuel_ has joined #wayland
tanty has joined #wayland
manuel1985 has quit [Ping timeout: 480 seconds]
tanty has quit [Quit: Ciao!]
tanty has joined #wayland
glennk has joined #wayland
mart has joined #wayland
fossdd has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
fossdd has quit [Read error: Connection reset by peer]
<kennylevinsen>
... I wonder if I'll ever get around to writing that article about how seats work...
sima has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
fossdd has quit [Remote host closed the connection]
fossdd has joined #wayland
sima has joined #wayland
Ojus1_ has joined #wayland
Fxzx_mic has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Ojus1_ has quit [Remote host closed the connection]
Fxzx_mic has quit [Read error: Connection reset by peer]
Fxzx_mic has joined #wayland
garnacho has joined #wayland
garnacho has quit []
mblenc has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
<zzag>
d_ed[m]: jadahl: emersion: drakulix[m]: do you think that it's worth to resume governance meetings? imho they were quite productive
<emersion>
sure, would be great
garnacho has quit []
garnacho has joined #wayland
<zzag>
... and we've got a few protocols that are worth discussing
mblenc has joined #wayland
<pq>
I've been wondering why people have not requested more of the meetings
<zzag>
heh some kde thing happened around that time iirc and people just forgot about it :D
mblenc1 has quit [Ping timeout: 480 seconds]
<jadahl>
zzag: which ones should be prioritized?
<jadahl>
as talking points I mean
kts has joined #wayland
Fxzx_mic has quit [Read error: Connection reset by peer]
Fxzx_mic has joined #wayland
<zzag>
I was thinking toplevel-icon, placement, and surface group transaction (this one should be the easiest because we're all on the same page, and we just need to hash out the subsurface related details to finally get it in). do you have something that you would like to discuss?
Fxzx_mic has quit [Read error: Connection reset by peer]
Fxzx_mic has joined #wayland
<d_ed[m]>
I suggest you pick one thing at a time
Fxzx_mic has quit [Read error: Connection reset by peer]
Fxzx_mic has joined #wayland
<jadahl>
yea, those three are vastly different, perhaps good to narrow it down to one general topic
<zzag>
hmm, indeed.. what about the surface group transaction protocol?
<zzag>
it should be the least controversial
<zzag>
and it seems like a good starting point to resume the meetings
<jadahl>
sure, we can try to figure out how much interaction with subsurfaces can be possible to specify
<zzag>
(and also if we could simplify some of subsurface stuff in long term :D )
<Company>
if you ever want to talk about fractional scaling, please invite me
<zzag>
I'll send a doodle link to the wayland-devel mailing list later today or tomorrow
<zzag>
would you be available the next week?
Net147 has quit [Quit: Quit]
Fxzx_mic has quit [Remote host closed the connection]
Net147 has joined #wayland
Fxzxmic has joined #wayland
privacy has joined #wayland
<colinmarc>
Hi! I'm implementing the color management draft protocol and I have a very specific question that's quite tricky to google. My question is: why is ST2084 PQ so... weird?
<colinmarc>
When I get buffers from the app and linearize, I'm left with this number of absolute nits from 0 to 10,000. To blend that with SDR content, I have to rescale to some reasonable value of `1.0`. I've seen the suggestion 203 nits in Rec. 2048, but I've also seen 100 in a bunch of places, and 80. Which one should I use? Are there other ways around this issue? Thanks in advance!
systwi has quit []
kts has quit [Quit: Leaving]
<kennylevinsen>
You will nee to deal with the difference in target brightness one way or another. When outputting HDR, you would rescale SDR to a standard target brightness of choice to not have a word processor incinerate your eyeballs with 4000+ nits of white.
Ojus1_ has joined #wayland
<colinmarc>
The way I'm doing blending right now is supposed to be independent of the output. (I'm blending into scRGB, with values above 1.0 clipped for SDR output). I guess scaling up SDR and scaling down HDR are the same operation in that sense - if I'm dividing by 203 and then multiplying back out by 203 on the other side.
<kennylevinsen>
I plead the fifth and invoke pq, the color whisperer :)
<vaxry>
🎷🎶
<vaxry>
oh wait wrong whisperer
Fxzxmic has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest4684
Fxzxmic has joined #wayland
<pq>
colinmarc, heya
<pq>
colinmarc, the first thing is, nits at a lie.
<pq>
In physics, cd/m^2 a.k.a nit is a measure of absolute luminance. But when we are talking about video signals, nit is actually a unit of relative luminance. It is relative to the implied viewing environment, and also relative to the display capabilities (dynamic range).
<JEEB>
colinmarc: 100 nits (!in dark env!) is the film SDR spec, but the thing is that if you clip HDR stuff with that, you are actually not capturing enough for what was visible as SDR graphics white in HDR. that is what was then via experiments noted to be ~203 nits in rec. 2048 etc
<drakulix[m]>
Sounds good to me. d_ed . I would additionally be interested in discussing fifo and commit-timing. (Also ext-screencopy, but I think only emersion is on-board with that one.)
<JEEB>
so you map SDR graphics white in HDR to SDR graphics white to SDR for the "simplest" clipping style thing
<JEEB>
it gets even more fun with MS bringing in 80 nits (!in dark env!) which is mentioned in sRGB spec
<JEEB>
but I would probably ignore that
<kennylevinsen>
also note: while there may be different opinions of what the true SDR mastering brightness is, people are also used to being able to arbitrarily set the SDR target with whatever "brightness" dial is available to them
<pq>
All of the 203, 100 and 80 nit values are correct *in their respective contexts*. Taking that value out of its context makes it meaningless.
<JEEB>
yea
<Company>
the great thing is that it's absolutely undefined so everyone just does whatever
<Company>
and then blames everyone else for doing it wrong
<JEEB>
I think it's not undefined since we have recs for SDR<->HDR conversions
<colinmarc>
pq: so like, other transfer functions are relative to the screen brightness, and pq is *also* relative to the screen, just with an extra coefficient?
<pq>
colinmarc, nothing that simple, no.
<Company>
JEEB: dunno, there seems to be a surprising lack of testsuites
<colinmarc>
🫠
<JEEB>
PQ is also related to screen brightness since you would not show the image at the same brightness at 500 nits and 250 nits of env brightness
<JEEB>
uhh, not screen but env
<JEEB>
:V
<JEEB>
Company: that is true, there is no reference test suite like with codecs or containers
Ojus1_ has quit [Remote host closed the connection]
<pq>
It seems like the differences between display luminance capability and environment brightness are compensated by non-linear adjustment that is related to "gamma". HLG OOTF is one such definition.
<pq>
I mean, difference between display A in environment 1, and display B in environment 2.
<pq>
colinmarc, if you're looking for a straight answer "how do I", I don't have an answer. I haven't really looked into luminance mapping yet.
<Company>
JEEB: the thing where this is gonna go wrong in the future is when color transforms are sometimes done by a compositor, sometimes by a toolkit, sometimes by an app, and sometimes by the hardware, depending on the state of everything
<Company>
JEEB: ie when you have a fullscreen app and opening a context menu changes the brightness, because it switches from direct scanout to compositing in the compositor
* kennylevinsen
shakes fist at Apple TV's mapping of SDR to HDR takes away the ability to control SDR brightness independently of monitor HDR brightness
<colinmarc>
JEEB: so I did look at libplacebo, and I think it does the 203 nits thing.
<JEEB>
yes
<pq>
colinmarc, other TFs are indeed relative to the display in a straight manner, and both the reference display and reference viewing environment are usually defined the respective or associated specs.
<JEEB>
mpv/libplacebo has done it for ages. SDR graphics white in SDR is taken in as 100 nits, then boosted to what people perceive as graphics white in HDR
<colinmarc>
Company: Right, I thought about that! If I pick 203, and then I switch to fullscreen exclusive (which in my compositor happens most of the time), I'm no longer touching the nonlinear value, so the brightness could change if I'm compositing vs not.
rasterman has quit [Quit: Gettin' stinky!]
<Company>
colinmarc: my assumption about that is that it will be solved as people encounter it
<JEEB>
Company: but yea given that there N different ways of doing both gamut and tone mapping, and since none of those are specified other than "clip", you really can't verify anything else than clip implementation
<Company>
and then things will be agreed on and all the projects will start doing the same thing
<JEEB>
but yea, would be nice if we had some sort of ref. test suite even for that :)
<colinmarc>
pq: I really appreciate the help. Can you provide any context on why ST2084 is "absolute" if the absolute thing is a lie anyways?
<Company>
the same thing is happening with graphics offload atm
<Company>
where compositors accept YUV and GTK accepts YUV but they don't necessarily agree on the YUV primaries
<pq>
colinmarc, PQ TF though, being "absolute", can encode luminances beyond what any display at hand can, or even the mastering display could, produce. You still have a reference viewing environment where the signal would apply as-is, if you were sending to the mastering display. HDR metadata gives you the mastering display capapbilities, which gives you some sort of reference of how high luminance can even be
<JEEB>
colinmarc: tl;dr "absolute within the reference viewing environment"
<pq>
meaninful for the signal. Then there is also the standard diffuse or graphics white level associated with the PQ system. Using all of these, one is somehow supposed to be able to adapt the signal for the display at hand.
<JEEB>
this is why apple actually utilizes the reference viewing environment metadata, although way too often I've just seen some hard-coded values there
* JEEB
goes check some of his winter snow clips
<colinmarc>
but the SDR reference white isn't part of the metadata, is it?
<JEEB>
no, it's specified now
<pq>
Company, if you haven't noticed, people are working hard to define a KMS UAPI so that display controller (KMS) and compositor would perform tone mapping exactly the same way, so that switching between them would be seamless.
<pq>
Company, OTOH an application should never attempt to switch between application and compositor tone mapping assuming it should be seamless. It won't.
<colinmarc>
The application doesn't get to decide, right? The compositor can pop something over top like a notification or whatever
<Company>
pq: it will have to be for any sort of acceleration to work
<JEEB>
I think it's probably mentioned in the former, but the latter was updated later so indeed I would start there
<Company>
pq: like direct scanout, in particular with multiple overlay planes
<pq>
colinmarc, I have no idea why PQ system was designed like it was. I believe it was extracted from Dolby Video, which is proprietary. I have enough problems trying to figure out just the "how". :-)
<pq>
Company, you mean YUV-RGB conversion matrix? The primaries are yet another thing to get wrong.
<Company>
pq: I mean more or less anything - but video playback is the obvious example
<colinmarc>
It's such a rabbit hole, this stuff! I'm also dealing with YCbCr encoding in my case (for video streaming). For some reason, unlike with RGB <-> RGB conversions, RGB <-> YCbCr conversions are defined in terms of `R', G', B'` - with a transfer function baked in
<JEEB>
the matrix defines the order of applying trc I think. with most doing it one way, and then one of the NCL/CL ones being different - I think? (possibly also ICtCp, but not sure)
<colinmarc>
Yes, iiuc BT2020 defines a linear transformation as well, but that's not used anywhere really
<JEEB>
yes, NCL is the common one
<Company>
pq: and Gnome apps have this tendency to round corners, which means they can't be offloaded into a subsurface unless they are maximized/fullscreen or have black bars larger than the corners
<JEEB>
anyways with RGB you don't have matrix coefficients :P
<JEEB>
you only have primaries and transfer
<Company>
pq: which means that the offload status changes as the player window is resized
<JEEB>
or well, H.273 wise it's called "transfer: identity"
<JEEB>
ugh, not transfer
<colinmarc>
JEEB: I'm using matrices to do RGB <-> RGB. You can premultiply the "to XYZ" and "from XYZ" matrix. Unless I'm getting something wrong?
<JEEB>
I should not attempt to multitask
Fxzxmic has quit [Remote host closed the connection]
<colinmarc>
Oh, I think I understand what you mean.
Fxzxmic has joined #wayland
<JEEB>
colinmarc: I just recall the 0) handling chroma subsampling 1) matrix coefficients 2) transfer 3) primaries for some matrix to linear XYZ (except for the exceptions), although my brain could misremember these steps :P
<pq>
that's correct
<pq>
If your pipeline is a matrix-TF-matrix, then you can convert any electrical YCbCr and ICtCp to optical RGB (and XYZ with an additional matrix). Talking only about format conversion, not mapping.
<colinmarc>
(there's one more parameter, which is whether your range is 16-235 or full)
<pq>
quantization range handling needs an offset along with the first matrix
<JEEB>
yea
<JEEB>
the whole range stuff is something for which I rewrote the FFmpeg docs in 2020 or so
<colinmarc>
It just occurred to me to ask - what is MPEG range in a 10-bit context?
<JEEB>
I specified it in a bit depth unrelated manner which is listed in BT.2100 as well
<JEEB>
(BT.2100 actually finally defines the full range representation as well)
<colinmarc>
found it in 2100, thanks!
<pq>
anyway, you decode content to optical, map source graphics white to destination graphics white, and clip or map to destination display capability. And don't forget the RGB-RGB conversion to account for different primaries. That could be a start.
<JEEB>
yup
<pq>
oh, and then encoding for the destination display
<colinmarc>
I have all of that, in theory. my math is wrong somewhere because I'm getting trippy colors. Currently debugging that.
<colinmarc>
I was stuck for a long time on the 203 nits thing, though. It's just really counterintuitive
<pq>
in Weston we're only soon'ish entering the stage where we get to deal with all this, since we started with ICC workflow and the parametric image description stuff is brewing.
<JEEB>
and the ICC stuff is the stuff which I consider much more complex than "just H.273 values" :D
<pq>
well...
<pq>
ICC is really "just trust the ICC file" and "use a battle-tested CMM to give you the pipeline"
<JEEB>
colinmarc: it becomes more intuitive when you understand that previously while actual screens were much more bright, video was limited to 100 nits. and graphics white for most people is not 100 nits (due to ambient environment or otherwise).
<JEEB>
so now that the brightness of coded content is no longer limited to 100 nits, the graphics white gets put somewhere closer to where it should be
<JEEB>
many screens are by default around 200-250 nits IIRC? so it seems to match.
<JEEB>
pq: well sure, solvable by "just throw it at an implementation" :)
<pq>
JEEB, I think it really is the only solution, because these CMMs contains code the work around broken ICC files that are abundant.
<pq>
*to work around
<JEEB>
pretty much
<colinmarc>
Where does one get a CMM?
<pq>
colinmarc, pick a software; I picked LittleCMS for Weston.
<pq>
mature product, comes as a library, and a compatible license
<colinmarc>
my plan was to clean it up and open an MR next week, since I'll be away from my GPU for a week starting tomorrow.
<JEEB>
yup
<pq>
colinmarc, is that not based on the work JoshuaAshton and drakulix[m] did? Or did they implement only the simpler protocol?
<pq>
colinmarc, please also mind the two Khronos issues I opened about EGL and Vulkan interop, thanks. :-)
<colinmarc>
pq: I saw those. The vulkan side of this is very very thin! There's no way to wire up most of the protocol via vulkan, like the surface/output image descriptions.
<colinmarc>
I didn't wire up the metadata yet, but there is an extension to do that with vulkan
<zamundaaa[m]>
yeah Vulkan needs a new extension to get the preferred surface metadata
<zamundaaa[m]>
Colin Marc: fwiw KWin's implementation also only clips HDR content to SDR the brightness on SDR screens, and in practice it's a good starting point... people don't often put HDR content on SDR screens *yet*
<colinmarc>
My compositor is a little weird / easier to test with in that I only have to hand off the content to a video encoder. The actual displaying is happening on my macbook, where SDR/HDR is pretty well handled.
<JEEB>
zamundaaa[m]: and windows anyways does that I think (at least at point of win10)
<colinmarc>
It's not that bad to propose an extension to vulkan, right? Not that I'm volunteering...
Fxzxmic has quit [Remote host closed the connection]
<JEEB>
colinmarc: btw if you want to yell in annoyance, check the difference between BT.709 transfer handling between macOS/QT and iOS
<zamundaaa[m]>
Joshua wanted to do it at some point. I don't think anything happened with that yet, did it?
<zamundaaa[m]>
JoshuaAshton?
<JEEB>
macOS handles it in pre-BT.1886 manner, while iOS's handling was coded post-BT.1886 :D
<pq>
colinmarc, FWIW, much of the Wayland color-management protocol is not even meant to be used via EGL or Vulkan, but the protocol should be enough to implement what EGL/Vulkan there is with their extension.
<colinmarc>
zamundaaa[m]: Sorry, I misunderstood at first, you're talking about mapping to SDR reference white and then clipping?
Fxzxmic has joined #wayland
<colinmarc>
pq: That's quite tricky, isn't it? I feel like most protocols are either meant to be used exclusively by the driver or exclusively by the client.
lsd|2 has joined #wayland
<JEEB>
in scRGB that is "just" graphics white at 1.0, but yes :)
<pq>
colinmarc, it is exclusive IIRC, yeah. Which is why an extension to get the preferred image description out is probably necessary.
<pq>
colinmarc, but I would not expect to be able to use ICC files via Vulkan, or even custom primaries nor arbitrary combinations of TF/primaries/etc.
<zamundaaa[m]>
Colin Marc: there's no mapping yet. Compositing in KWin happens in nits, and when I encode for the display I apply the inverse EOTF and clip the result to 1.0
<zamundaaa[m]>
Unless an ICC profile is set for the screen, that just means clamp((nits / sdrBrightness) ^ (1/2.2), 0.0, 1.0)
<colinmarc>
Gotcha, yeah, that's more or less exactly what I have.
<pq>
till tomorrow \o.
<colinmarc>
thank you for the help!!
silverpower_ has quit [Ping timeout: 480 seconds]
silverpower has joined #wayland
zvarde1988303206779191685 has quit [Quit: Ping timeout (120 seconds)]
Ojus1_ has joined #wayland
zvarde1988303206779191685 has joined #wayland
Kerr has quit [Ping timeout: 480 seconds]
Ojus1_ has quit [Remote host closed the connection]
lsd|2 has quit [Remote host closed the connection]
mclasen has joined #wayland
lsd|2 has joined #wayland
rasterman has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
I just found this in kernel documentation about the drm plane SRC properties: "Devices that don’t support subpixel plane coordinates can ignore the fractional part."
rederick29 has quit [Quit: Leaving]
<zamundaaa[m]>
why can't drivers that don't support fractional coordinates just reject commits that try to use them?
<zamundaaa[m]>
This makes the fractional part of the coordinates useless for generic userspace :/
<vsyrjala>
i guess someone would need to figure out an answer to 1) how precise should such a check be? 2) how much userspace would we break by making it more strict?
<vsyrjala>
also the rules regarding filtering across the edge are another mess. my take is that you want "clamp to edge" behaviour at the fb edges, not at the viewport edges. ie. filter should be allowed to fetch an arbitrary amount past the viewport edge
<vsyrjala>
but i'm sure someone somewhere is already assuming nothing past the viewport edge is read
<zamundaaa[m]>
I would expect nothing past the viewport edge to be read... but my main use case for the properties is really just supporting direct scanout with viewporter
<zamundaaa[m]>
so I'll look up what viewporter does or doesn't specify for that
<vsyrjala>
not allowing filtering across the edge will lead to quality loss for pan&scan type of stuff
glennk has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
true. It would also not match what compositors generally do in rendering
<vsyrjala>
do compositors even use wider than bilinear filtering?
rv1sr has quit []
<zamundaaa[m]>
Not that I know of
<vsyrjala>
i guess we could always add more properties to control the behaviour
<zamundaaa[m]>
viewporter says content outside the source rectangle is ignored
<zamundaaa[m]>
but the compositing path in KWin at least doesn't seem to have any special code for making sure content outside of it doesn't get used even in filtering...
<vsyrjala>
"outside" is a bit ambiguous if it allows sub-pixel coordinates. same for sub-sampled formats
<zamundaaa[m]>
yeah
mohit81582263 has quit [Quit: mohit81582263]
mohit81582263 has joined #wayland
Brainium has quit [Ping timeout: 480 seconds]
<emersion>
iirc there is an issue about this somewhere
<zamundaaa[m]>
emersion: I thought so too but couldn't find it
<emersion>
i recall someone tried using a buffer with 1px squares of different colors to achieve single pixel buffer behavior
<emersion>
and then realized that worked on no compositor because of the filtering