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]
guru_ has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
Kerr has joined #wayland
sima has joined #wayland
kts has joined #wayland
kts has quit []
mxz has joined #wayland
kts has joined #wayland
kts_ has joined #wayland
kts has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
calcul0n has joined #wayland
ity1 has joined #wayland
ity has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
garnacho has joined #wayland
tyzef has joined #wayland
rooq96 has quit []
rooq96 has joined #wayland
<wlb> weston Issue #877 opened by diegonieto (diegonieto) Screen capture in a single output https://gitlab.freedesktop.org/wayland/weston/-/issues/877
leon-anavi has joined #wayland
Leopold_ has joined #wayland
glennk has joined #wayland
mripard has joined #wayland
kts_ has quit [Ping timeout: 480 seconds]
kts_ has joined #wayland
kts_ has quit []
manuel1985 has joined #wayland
rasterman has joined #wayland
mvlad has joined #wayland
zxrom has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Bugies has joined #wayland
Leopold_ has joined #wayland
karolherbst has quit [Read error: Connection reset by peer]
karolherbst has joined #wayland
zxrom has quit [Quit: Leaving]
zxrom has joined #wayland
<wlb> wayland Issue #440 opened by Julian Orth (mahkoh) Re-using interfaces across protocols https://gitlab.freedesktop.org/wayland/wayland/-/issues/440
fmuellner has joined #wayland
<swick[m]> zamundaaa: the end goal should always be to make it possible for offloading to be entirely transparent
<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.
<swick[m]> neat
<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
<JEEB> 2084 being https://ieeexplore.ieee.org/document/7291452 and 2086 being https://ieeexplore.ieee.org/document/7291707 , although the latter is marked as superceded?
<JEEB> ah there is a 2018 edition which I was not able to find from the IEEExplore? https://pub.smpte.org/pub/st2086/st2086-2018.pdf
<pq> oh, those are free now as well, cool
<pq> that SMPTE logo is funny btw... one could read it as "film in, SMPTE does magic, pixel garbage out" :-p
<JEEB> :D
<JEEB> indeed
ity1 has quit [Remote host closed the connection]
<emersion> "enhance!"
ity has joined #wayland
tyzef has quit [Quit: WeeChat 3.8]
Leopold has quit [Remote host closed the connection]
zxrom has joined #wayland
kts has quit [Ping timeout: 480 seconds]
<wlb> weston/main: Leandro Ribeiro * tests: move functions that create ICC profiles to lcms_util.c https://gitlab.freedesktop.org/wayland/weston/commit/ac3e41640227 tests/ color-icc-output-test.c lcms_util.c lcms_util.h
<wlb> weston/main: Leandro Ribeiro * tests: add helpers to create unique filenames https://gitlab.freedesktop.org/wayland/weston/commit/d29f904bec28 tests/ weston-test-client-helper.c weston-test-client-helper.h weston-test-runner.c weston-test-runner.h
<wlb> weston/main: Leandro Ribeiro * tests: make use of helpers to create unique filenames https://gitlab.freedesktop.org/wayland/weston/commit/bac9060d5429 tests/ color-icc-output-test.c drm-writeback-screenshot-test.c internal-screenshot-test.c weston-test-client-helper.c weston-test-client-helper.h
<wlb> weston Merge request !1453 merged \o/ (Test suite changes related to ICC profiles https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1453)
kts has joined #wayland
kts has quit [Quit: Leaving]
rooq96 has left #wayland [The Lounge - https://thelounge.chat]
Leopold has joined #wayland
kts has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
caveman has quit [Quit: caveman]
caveman has joined #wayland
qaqland has quit [Remote host closed the connection]
qaqland has joined #wayland
tyzef has joined #wayland
Amber_Harmonia has quit [Ping timeout: 480 seconds]
Amber_Harmonia has joined #wayland
vincejv has quit [Ping timeout: 480 seconds]
manuel1985 has quit [Quit: Leaving]
dogukan has joined #wayland
vincejv has joined #wayland
tzimmermann has quit [Quit: Leaving]
zetaE has quit [Read error: Connection reset by peer]
vyivel has quit [Remote host closed the connection]
vyivel has joined #wayland
kts has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Company has joined #wayland
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
mripard has quit [Quit: mripard]
Leopold has quit [Remote host closed the connection]
Leopold has joined #wayland
tyzef has quit [Quit: WeeChat 3.8]
garnacho has quit [Remote host closed the connection]
kenny has quit [Quit: WeeChat 4.2.1]
psykose has quit [Remote host closed the connection]
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
privacy has quit [Quit: Leaving]
calcul0n has quit [Remote host closed the connection]
calcul0n has joined #wayland
Brainium has joined #wayland
fvok4 has joined #wayland
overholts has quit [Quit: Ping timeout (120 seconds)]
overholts has joined #wayland
fvok4_ has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
Leopold_ has joined #wayland
sima has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
riteo has quit [Ping timeout: 480 seconds]
rv1sr has quit []
leon-anavi has quit [Quit: Leaving]
mvlad has quit [Remote host closed the connection]
Brainium has quit [Ping timeout: 480 seconds]
privacy has joined #wayland
fmuellner has joined #wayland
calcul0n has quit [Ping timeout: 480 seconds]
lsd|2 has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
tyzef has joined #wayland
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]