ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Bugies has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
<Company>
it's gonna make a lot of people very unhappy if that doesn't work with the GTK offloading stuff
<Company>
because there's tons of apps that dynamically switch between subsurfaces and GTK compositing rather frequently
<Company>
rounded corners do that to people
mort_ has quit [Quit: Ping timeout (120 seconds)]
mort_ has joined #wayland
<JoshuaAshton>
good to know that it's not just us that needs this then
<JoshuaAshton>
I think it's fine if it doesn't make the initial pass for the protocol (something something feature/scope creep) tho
crazybyte has quit [Quit: Ping timeout (120 seconds)]
jadahl has quit [Remote host closed the connection]
crazybyte has joined #wayland
jadahl has joined #wayland
bindu_ has joined #wayland
bindu has quit [Remote host closed the connection]
fmuellner has quit [Ping timeout: 480 seconds]
<Company>
I've designed that whole stuff under the assumption that GTK's compositing code is identical to the compositors
<Company>
it's shaders all the way down, so we can just make sure we use the same ones
guru_ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
tyzef has quit [Quit: WeeChat 3.8]
Guest2402 has quit [Remote host closed the connection]
<zamundaaa[m]>
You can't assume subsurfaces do the same thing as compositing even without color management
<zamundaaa[m]>
The scaling algorithm with viewporter is implementation defined for example, and so is the blending function
privacy has quit [Quit: Leaving]
cool110 has joined #wayland
cool110 is now known as Guest2459
glennk has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
andyrtr has quit [Read error: Connection reset by peer]
andyrtr has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
crazybyte has quit [Remote host closed the connection]
crazybyte has joined #wayland
Guest2459 has quit [Remote host closed the connection]
cool110 has joined #wayland
tyzef has joined #wayland
cool110 is now known as Guest2465
bnason has quit [Ping timeout: 480 seconds]
caveman has joined #wayland
tyzef has quit [Quit: WeeChat 3.8]
tyzef has joined #wayland
tyzef has quit [Quit: WeeChat 3.8]
mxz has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
guru_ has quit [Remote host closed the connection]
<swick[m]>
but yeah, we don't even properly communicate premult, YCbCr conversion, subsampling position, etc etc
<swick[m]>
long way to go
<swick[m]>
the whole color management thing is going to make this much harder even
<swick[m]>
but eh, let's start somewhere
<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
<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
<swick[m]>
except if we explicitly communicate the min/max and reference white levels
<swick[m]>
which is exactly what !44 is trying to do
<pq>
swick[m], they were talking about sub-surfaces vs. client-side composition results being expected identical.
<pq>
and arbitraryly switching between those two. Not KMS off-loading.
<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?
<pq>
I wonder if the same applies with HLG...
<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.
Leopold_ has quit [Remote host closed the connection]
Bugies has quit [Quit: Wychodzi]
<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
<swick[m]>
yes, subsurface offloading doesn't have the property... now. I'm of the opinion that it should be the goal eventually
<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
<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
<swick[m]>
or to put it another way, there is no way to say "the PQ TF" without also implying "the PQ system"
<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
<swick[m]>
so just saying "SDR" for everything else is prooobably good enough
<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"
<JEEB>
and for the graphics white level, that's mostly for mapping SDR graphics white components onto HDR image.
<JEEB>
yea, mentioning the ref. viewing environment lets you say that
<swick[m]>
yeah, my point is that this is mostly true for all TFs but becomes really loosely defined in a lot of cases
<swick[m]>
which is why one would usually just lump them into the "SDR" category and be done with it
<swick[m]>
the details here don't matter that much
<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.
<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
<pq>
I think a much more feasible goal is to create a single compositing library used by literally all compositors that make the promise.
<pq>
then we must re-design Wayland to be prescriptive
<pq>
and turn Wayland into a drawing API
<swick[m]>
not really. you just let the clients know about the algorithm used and have a "unknown" escape hatch. everything stays prescriptive.
<pq>
I don't see that as a good idea. We lose all the flexibility.
<pq>
you mean descriptive?
<swick[m]>
you don't loose any flexibility because you can just say "unknown"
<pq>
but "unknown" means clients won't work
<swick[m]>
you can still do whatever you want, it just gives clients the possibility of matching some compositors
<swick[m]>
yes
<pq>
then lots of people complain why each compositor is choosing whatever and not the other thing that they do
<swick[m]>
so? the situation is already true right now
<pq>
implying there is that possibility will probably make lots of people demand it
<pq>
no, it's not, because we do not even pretend it could be possible.
<swick[m]>
dunno, this just changes that you have to target one compositor and can start targeting groups of compositors
<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.
<swick[m]>
I mean, sure, you said that at some point
<swick[m]>
doesn't mean it always has to stay true
<swick[m]>
anyway, too far into the future to loose much thought over it
<pq>
I fear people don't understand the "far future", they demand it now
<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.
<swick[m]>
you should talk with Company about how realistic that is
<pq>
how could that change anything?
<pq>
I so wish all this talk was in Gitlab or email, and not in IRC, too.
<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.
<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.
<JEEB>
-10 being the D one and -40 being Samsung's HDR10+
<JEEB>
re HLG: apparently the image folk are defining their own version of it as well
<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.
<swick[m]>
eh, sure... the primaries, YCbCr stuff etc etc
<swick[m]>
but the TF implies a luminance on the reference display in the reference viewing environment
<pq>
I was specifically thinking of min/max/reference luminances.
<pq>
and the viewing environment
<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
<swick[m]>
they closely coupled this, unlike all other specs
<swick[m]>
but tbh, I don't think it matters
<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.
<swick[m]>
yes, you can, but then it's not PQ anymore
<swick[m]>
which is completely fine
<swick[m]>
I don't think we disagree with anything, it's just a matter of naming
<pq>
yes, what to call the TF used in the PQ system
<pq>
color-management protocol extension currently conflates TFs and systems
privacy has joined #wayland
Leopold has joined #wayland
<swick[m]>
in the sense that it implies an absolute luminance at some signal level in the reference viewing environment, yes
<swick[m]>
we could make them two separate things
<swick[m]>
let the TF only imply the actual curve, and have another property for the luminances and viewing environment
<swick[m]>
instead of having a sort of "override"
<swick[m]>
which !44 is trying to do
<pq>
right
<pq>
what to call the curve used by the PQ system, without confusing most people?
<daniels>
pqurve
kts has joined #wayland
Leopold has quit [Remote host closed the connection]
rv1sr has joined #wayland
Leopold has joined #wayland
<pq>
JEEB, thanks for those links. I wish I never need to study them, but I saved them. :-)
zxrom has quit [Quit: Leaving]
<emersion>
seems like some downstreams monkey-patch the upstream protocols :(
<emersion>
and that results in fireworks when compiling regular compositors against this ofc
<pq>
I wish I was surprised.
<emersion>
clearly i haven't done enough embedded stuff
<pq>
I haven't either, but I've heard the rumours of weston butchery.
Leopold has quit [Remote host closed the connection]
<pq>
a double-facepalm for copying the docs of a different request and not bothering to even delete them.
andreasbackx has joined #wayland
<emersion>
:D
andreasbackx has quit []
Leopold_ has joined #wayland
nerdopolis has joined #wayland
<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
<daniels>
vendor downstreams are very much averse to creating new things, and very happy to hack up existing things
<pq>
because it's "less maintenance"?
Leopold_ has quit [Remote host closed the connection]
<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
Leopold has joined #wayland
<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. :/
<kennylevinsen>
s/make an addition/make a supplementary protocol/
<kennylevinsen>
so I imagine they wouldn't have minded doing it right knowing that
<daniels>
yep
<daniels>
and both NXP and Rockchip are actually contributing stuff upstream, which is nice
<daniels>
there's some really useful stuff in the Rockchip tree in particular which I'd like to get upstream
<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
<kennylevinsen>
o.O
<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)
<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