ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
<zubzub>
so far it seems to correctly handle everything I throw at it
<zubzub>
now I can actually play remote games at 1920x1080@60fps with 40ms (20 network + 20 encode/decode) input latency which is is pretty cool too
<zubzub>
I should probably make a video playing doom3 running remotely in the browser as an extra flex :p
<pq>
zubzub, that's a nice diagram, but I get the feeling it is missing some of the actors: app, app-local server, browser - or at least not quite clear on who it is talking about.
<zubzub>
yeah it's pretty minimal, should probagly extend it a bit
<pq>
I would always think that Wayland is only between the app and the app-local server, and whatever goes between the app-local server and browser is a while independent another thing.
<pq>
*whole
<pq>
so when I talk to you about what a compositor does, that applies only to the app-local server
<zubzub>
yeah that's not the case here, I should probably make a separate diagram to show how it works
<pq>
and the app-local server from the app's point of view, even
<pq>
zubzub, also something that can be viewed without saving to disk first, too ;-)
<zubzub>
pq: I'll send an email to Google ;)
<zubzub>
(I agree that is annoying)
<pq>
zubzub, ok, I think I get your diagram, and I very much agree with your design.
<pq>
zubzub, it actually doesn't differ from the "Classic" case semantically.
<zubzub>
now I just need to implement the whole apps-render-faster-than-compositor case and fix all bugs and my life's work is complete (at least for the remoting part)
<zubzub>
pq: indeed that's the idea
<pq>
Something like this is what any wayland compositor with a remote backend would do, with varying details.
<zubzub>
yup, but those usually just remote the rendering part
<pq>
more like the opposite?
<zubzub>
yeah, like, only the final output image is send over network
<zubzub>
compositor state is kept server side
<pq>
yeah
<pq>
depends on the remoting style which side is compositing, but it doesn't really make difference in this question
<pq>
it also doesn't make a real difference on which side does the window management decisions, as long as the two sides don't try to fight each other :-)
<pq>
that fight is likely what one would get if you combined local composited display with per-window remoting to a remote window system making its own decisions
<emersion>
in any case, if the difference between the two is important to you, "sub-surface" is not enough
<pq>
ok. Yes, it is important.
d__ed has quit []
<pq>
btw. originally wl_subsurface.destroy explicitly documented that it removes the role from the wl_surface. That was extremely clear.
<pq>
Yes, it was different from anything else, but it was explicit.
<pq>
I don't see any discussion being hand about what implications changing that would cause.
<pq>
*had
<pq>
The whole point of wl_subsurface object is to *change* how wl_surface works, so you cannot just refer to "this is how wl_surface always works".
<pq>
Given that no-one apparently noticed that change, no-one relied on removing the role.
<pq>
or no compositor implemented the new behavior
<emersion>
wlroots does
<pq>
that's good
<pq>
probably from the start, right?
BlkPoohba has joined #wayland
fmuellner has joined #wayland
<swick[m]>
pq: did you notice that h.274 uses the terms content colour volume and mastering display colour volume?
<pq>
swick[m], I didn't read it yet, no.
<swick[m]>
it doesn't really define them though
<pq>
*facepalm*
Dejan has joined #wayland
<pq>
just like we :-P
<swick[m]>
it's not great that we have terms which don't match with ITU
<swick[m]>
but not sure if we should change it again, especially because I'm not 100% sure what they mean
<JEEB>
yea H.274 just defines the metadata blocks (and has some very basic explanation on their semantics)
<swick[m]>
and 5 pages of definitions
<swick[m]>
not for the color volumes though
<pq>
swick[m], if we can't find a definition for a term used in standards, I'd rather we define our own different term in order to not conflict with standards in case they mean something else.
<swick[m]>
makes sense
<JEEB>
yea I wonder where those came from
<pq>
two different terms meaning the same thing is solvable, the same term with different meanings is... gamma :-p
<JEEB>
probably if one goes through the history of JVET-experts documents
<JEEB>
(thankfully that stuff is 100% public)
<swick[m]>
I also looked at the Colorspace prop again... While hdmi's color space definitions are from CTA-861 and the default colorimetry explicitly references the EDID colorimetry the DP definition of the default is much more vague
<swick[m]>
"RGB unspecified color space (Legacy RGB mode)"
<swick[m]>
and AMDGPU defaults to sRGB, not this for DRM_MODE_COLORIMETRY_DEFAULT
<swick[m]>
such a mess
<JEEB>
yea MS just defines that it's supposed to be sRGB but in reality it's whatever an application does without utilizing additional specific colorspace APIs
<JEEB>
specifically what the output of an application is for the compositor (which then gets pushed onto the output config)
<JEEB>
I think historically speaking it's until very lately been very vague/unspecified what is going over the wire :D and now we're finally getting definitions
<JEEB>
since everyone just utilized ICC profiles or so to work around the problem
<swick[m]>
I mean the point here is that I'm not sure what I get with DP set to "RGB unspecified color space". I suspect it means the same as the CTA-861 default colorimetry but it's to vague to be sure.
<swick[m]>
and also that the KMS Colorspace property just says the default is driver-specific when it really should not be driver specific. amdgpu implements the default as sRGB and there is no way to specify the CTA-861 default colorimetry.
<pq>
I suspect the vagueness is the right answer: monitors display it in too wildly different ways
<swick[m]>
that's still very different than forcing sRGB
<pq>
It's the unqualified RGB thing that end users have accustomed to seeing ove years of evolution of buying a new monitor and "ooh, shiny better colors!" repeatedly
<pq>
yes, it is not sRGB.
<pq>
so "shiny better colors" is what you get when you set unspecified legacy RGB
<pq>
"better" being very much sarcastic here
<pq>
or should I say very much marketing
<Dejan>
it won't help me much, i am colour blind
<swick[m]>
JEEB: any pointers with the JVET-experts documents for the color volume definitions?
<pq>
swick[m], do we have any evidence that "CTA-861 default colorimetry" is not a lie? Maybe DP spec just acknowledged it's a lie.
<swick[m]>
I suspect it's a lie in the sense that the user can change the white point on the display and we won't know about it
<pq>
I mean a much bigger lie, even primaries.
<swick[m]>
do you know about displays where you can change the primaries with the OSD?
<pq>
hmm... I can do *something*
BlkPoohba has quit []
<swick[m]>
the ones I've seen so far all allow for adjusting the RGB channels separately
<swick[m]>
which gives you another white point with the same primaries
<pq>
right, so you would need to be able to adjust minimum emission of each channel
<pq>
to reduce color gamut, which mimicks moving the primaries
<swick[m]>
yup
jmdaemon has quit [Ping timeout: 480 seconds]
<pq>
nope, can't see such adjustments in my monitors
<pq>
swick[m], I mean, the monitor firmware could automatically do that though, for certain signal types.
devilhorns has quit []
<pq>
but I also assume that monitor physical primaries are not matching the CTA-861 default colorimetry.
<pq>
of course they don't for WCG monitors, but I suspect also other monitors
floof58 is now known as Guest7940
floof58 has joined #wayland
<zubzub>
10:01 < zubzub> I should probably make a video playing doom3 running remotely in the browser as an extra flex :p
<JEEB>
that should have history from 2015 to NOW()
<bl4ckb0ne>
pq: often its just a lack of proper packaging and time/space
<bl4ckb0ne>
i made a few static version of packages in alpine and never had any issues
<pq>
bl4ckb0ne, I mean it increases maintenance burden, work to rebuild packages, and bandwidth usage to distribute them all. That is assuming your packaging database already records which binary statically linked which lib.
chipxxx has quit [Remote host closed the connection]
<bl4ckb0ne>
alpine does it well fwiw
<pq>
yes, it *can* be done, but why bother?
<bl4ckb0ne>
ah and cmake requiring to re-generate the files to make a static lib leading to 2* build time
<bl4ckb0ne>
yeah why bother
<bl4ckb0ne>
:(
<pq>
when one lib gets a bug fix, do you want to build and distribute that one lib binary package, or tons of packages that use it
<pq>
that's what I mean - not that it wouldn't work but because it causes more work
<pq>
and you need to keep track of which binary linked what statically, and the runtime linker cannot help you check that
<pq>
so I think I see both sides of that coin, the other side being binaries that are more portable and break less
<pq>
application binaries, specifically, not lib binaries
<pq>
if you never need to ship bug fixes to libraries, then it's a different story
Leopold_ has quit []
Leopold has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
<emersion>
i like how C-specific the dynamic linking problem is presented
<emersion>
while all other languages (Rust, Go, Zig, …) just use static linking and don't bother with anything else
<pq>
which makes it useless to talk about dynamic linking with those: it does not exist
<qyliss>
With Rust it does exist I think
<pq>
not in any stable form
<pq>
unless of course you go out of your way to define a C ABI for your Rust libs, which... no
<qyliss>
yeah, but whether that matters depends on the distro
<qyliss>
it's a problem for most, but would be no problem for us in Nixpkgs, for example
<qyliss>
(static is also not a problem, for the same reason)
<emersion>
qyliss: i mean yeah it can always be done… but almost nobody does it
<qyliss>
yeah
<qyliss>
we have one of the only setups where it would make sense and even then we don't bother
<pq>
What is the easiest way to distribute bug fixes into sharable software components? Isn't the answer to that inherently language-specific?
<pq>
how much do you need to rebuild, how much binaries do you need to update and distribute
<pq>
or do you distribute only sources, and every end user rebuilds on their own
<bl4ckb0ne>
that ends up being a lot of compute time to spare a few kilobytes
<pq>
what is globally most efficient
<pq>
yes, exactly
<DemiMarie>
qyliss: nixpkgs might want to start using Rust dynamic linking.
<pq>
centrally built binaries shipped as binaries cut most of the overhead, and dynamic libraries cut a little bit even more compared to static libs
<emersion>
there are languages where you distribute sources and every end user rebuilds their own everytime they run the program ;)
kts has quit [Quit: Konversation terminated!]
<pq>
indeed, and on such languages when you bug-fix a library, it is a very small effort to get the fix to end users
<emersion>
hm, it really depends
<emersion>
exhibit A: npm
<pq>
Isn't that the ecosystem where a tiny change in a tiny component can immediately bring down huge production systems? :-)
<emersion>
tbh i've been dealing with lots and lots of breakage in Python too
<psykose>
the issue is that people write too much code
<psykose>
there is never a sane way to manage dependencies when 28 xml parsing libraries exist, and every project uses a different one, and that happens even in C
<psykose>
how many xml parsers do you have on your system, do you think?
<bl4ckb0ne>
not enough
<emersion>
to start things of, libwayland has two :P
<emersion>
off*
<psykose>
:-)
<bl4ckb0ne>
how come?
<emersion>
one for parsing, one for checking DTDs
<MrCooper>
<emersion>
(latter is optional)
<MrCooper>
(I accidentally hit enter instead of backspace)
fmuellner_ has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
BlkPoohba has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
Company has joined #wayland
kts has quit [Quit: Konversation terminated!]
kts has joined #wayland
julio7359 has joined #wayland
DodoGTA has left #wayland [#wayland]
mohamexiety has joined #wayland
cvmn has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
DodoGTA has joined #wayland
kts has quit [Quit: Konversation terminated!]
julio7359 has quit [Ping timeout: 480 seconds]
pochu has quit [Quit: leaving]
DodoGTA has left #wayland [#wayland]
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
DodoGTA has joined #wayland
DodoGTA has left #wayland [#wayland]
DodoGTA_ has joined #wayland
jmdaemon has joined #wayland
GentooPhysicist3935426 has quit []
GentooPhysicist3935426 has joined #wayland
tzimmermann has quit [Quit: Leaving]
JoshuaAs- has quit [Ping timeout: 480 seconds]
JoshuaAshton has joined #wayland
floof58 has quit [Read error: No route to host]
floof58 has joined #wayland
Major_Biscuit has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #wayland
Major_Biscuit has quit [Ping timeout: 480 seconds]
___nick___ has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
mvlad has quit [Remote host closed the connection]
rasterman has joined #wayland
DodoGTA_ has quit [Remote host closed the connection]
DodoGTA has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
Dejan has quit [Read error: Connection reset by peer]
dcz has quit [Ping timeout: 480 seconds]
<swick[m]>
pq JEEB so I went hunting in the JVET archives just to notice that the definitions are in H.Sup19 : Usage of video signal type code points
<swick[m]>
3.6 colour volume: Space of all colours and intensities that a device or signal can reproduce or convey.
<swick[m]>
"The approved colour volume, which can be smaller than the container volume, is often indicated with SMPTE ST 2086 metadata."
<swick[m]>
the Mastering display colour volume is defined well and they use container colour volume as well
<swick[m]>
"Some applications restrict the utilized colour volume to be smaller than what can be expressed in a Rec. ITU-R BT.2020 or Rec. ITU-R BT.2100 container"
<swick[m]>
so they use "utilized colour volume" and "approved colour volume" for what we call "target color volume"
<swick[m]>
not sure what to make of this
rv1sr has quit []
___nick___ has quit [Ping timeout: 480 seconds]
<JEEB>
swick[m]: right that supplement
<swick[m]>
well for CICP, not for h.273
<JEEB>
H.273 is the ITU published version of CICP :)
<swick[m]>
eh, right, I meant h.274
<JEEB>
ayup
<swick[m]>
off by one errors on specification numbers
<JEEB>
:)
<JEEB>
talking of JVET archives, it's fun how latest minus 1 meeting has an actual errata doc for CICP etc
<JEEB>
not that it has a lot, but it's fun to see what they're thinking about
danvet has quit [Ping timeout: 480 seconds]
BlkPoohba has quit []
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
bl4ckb0ne has joined #wayland
emersion has joined #wayland
mohamexiety has quit []
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]