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
<wlb> wayland/main: Simon Ser * build: bump version to 1.21.92 for the beta release https://gitlab.freedesktop.org/wayland/wayland/commit/002e1f1d3a2a meson.build
<wlb> wayland.freedesktop.org/main: Simon Ser * releases: add Wayland 1.21.92 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/a5aa2fbe466f releases.html
shsharma has joined #wayland
shsharma__ has quit [Ping timeout: 480 seconds]
mohamexiety has quit []
shsharma_ has joined #wayland
shsharma has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 481 seconds]
julio7359 has joined #wayland
BlkPoohba has quit []
julio7359 has quit [Ping timeout: 480 seconds]
nyn has quit [Ping timeout: 480 seconds]
nyn has joined #wayland
floof58 has quit [Remote host closed the connection]
floof58 has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
BlkPoohba has joined #wayland
julio7359 has joined #wayland
julio7359 has quit [Remote host closed the connection]
julio7359 has joined #wayland
BlkPoohba has quit []
Fxzxmic has joined #wayland
cool110 has joined #wayland
BlkPoohba has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
julio7359 has joined #wayland
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
kts has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
<DemiMarie> Is it possible for an Xwayland surface to have subsurfaces?
BlkPoohba has quit []
Company has quit [Quit: Leaving]
dcz has joined #wayland
kts has quit [Quit: Konversation terminated!]
kts has joined #wayland
kts has quit [Quit: Konversation terminated!]
chip_x has joined #wayland
danvet has joined #wayland
paulk has quit [Ping timeout: 480 seconds]
chipxxx has quit [Ping timeout: 480 seconds]
julio7359 has quit [Ping timeout: 480 seconds]
mvlad has joined #wayland
<emersion> not at the moment
tzimmermann has joined #wayland
kts has joined #wayland
chip_x has quit [Remote host closed the connection]
<pq> bl4ckb0ne, you know that distros hate static linking and lib vendoring because it makes it so much harder to address bugs in a lib, right? AFAIK.
<pq> emersion, thanks for the release!
<emersion> np!
rv1sr has joined #wayland
rasterman has joined #wayland
rv1sr has quit []
rv1sr has joined #wayland
MajorBiscuit has joined #wayland
Major_Biscuit has joined #wayland
* ofourdan coughs !188 ;)
MajorBiscuit has quit [Ping timeout: 480 seconds]
d__ed has joined #wayland
<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
ki[m] has quit []
frytaped[m] has quit []
cb5r[m] has quit []
hasebastian[m] has quit []
<zubzub> yup, split brain
ozwald1[m] has quit []
halfline[m] has quit []
tleydxdy has quit []
toggleton[m] has quit []
Guest7809 has quit []
ElyusiKei[m] has quit []
kts has quit [Quit: Konversation terminated!]
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
d__ed has quit [Ping timeout: 480 seconds]
chipxxx has joined #wayland
Fxzxmic has quit [Quit: Konversation exit!]
bim9262 has quit [Quit: ZNC - https://znc.in]
bim9262 has joined #wayland
devilhorns has joined #wayland
kts has joined #wayland
kts has quit []
kts has joined #wayland
nerdopolis has joined #wayland
chip_x has joined #wayland
chip_x has quit [Max SendQ exceeded]
chip_x has joined #wayland
chipxxx has quit [Ping timeout: 480 seconds]
chipxxx has joined #wayland
<MrCooper> https://wayland.app/protocols/wayland#wl_subcompositor says "sub-surfaces must always have a parent", but then https://wayland.app/protocols/wayland#wl_subsurface says "If the parent wl_surface object is destroyed, the sub-surface is unmapped.", which sounds like the sub-surface keeps its role with no parent; which is it?
chipxxx has quit [Max SendQ exceeded]
<emersion> MrCooper: this has been fixed iirc
chipxxx has joined #wayland
<emersion> wayland.app probably outdated
<MrCooper> are you thinking of 9700155edaae ("protocol: wl_subsurface::destroy does not remove the role") perhaps?
chip_x has quit [Ping timeout: 480 seconds]
<MrCooper> can't find anything else related
d__ed has joined #wayland
<emersion> i think yes
<emersion> does it not fix it?
<MrCooper> no, that's about the wl_surface of the sub-surface itself, not the parent
<MrCooper> protocol/wayland.xml still has the same seemingly contradictory language about the parent
<emersion> ah, i see
<emersion> send patch?
<pq> what did I mean by that...
<JEEB> picking the past brains of yourself is a skill that many wish they had
<emersion> the question here is whether or not to send a protocol error when the parent is destroyed before the child wl_subsurface
<emersion> the sub-surface parent is immutable, so the sub-surface cannot be re-mapped after parent destroy
<pq> emersion, there never was an error for that before, right? So there will not be one now.
<emersion> you mean in the enum?
<pq> I mean sent by anyone ever
<emersion> "sub-surfaces must always have a parent" makes it sound like the compositor will send a protocol error when the parent is destroyed
<pq> I don't recall wanting that to be a protocol error.
<pq> ah, but that sentence is different
<MrCooper> an alternative might be for the child to lose its sub-surface role
<pq> The root surface in a tree of sub-surfaces is the main
<pq> surface. The main surface cannot be a sub-surface, because
<pq> sub-surfaces must always have a parent.
<emersion> MrCooper: a role can never be lost
<emersion> oh.
<emersion> yeah, that's different in this context
<pq> so I think that sentence is more about making it clear what a "main surface" is.
<emersion> indeed
<pq> I suppose sub-surfaces can be orphaned by destroying the parent, which creates a loop-hole
<MrCooper> there's no way to set a new parent for the sub-surface after that though, is there?
<pq> now or originally? ;-)
<MrCooper> now
<emersion> could be disambiguated with something like "sub-surfaces must always have a parent at creation time"
<pq> emersion, that would work for me
<emersion> there is no request to change the sub-surface parent to a new wl_surface (please don't add one)
<pq> You *could* destroy wl_subsurface, and create a new one. Is that allowed? It could be used to change the parent.
<emersion> but then it's a new sub-surface
<MrCooper> so basically, destroying the parent wl_surface makes the wl_subsurface useless, it cannot be mapped anymore
<emersion> correct
<emersion> the only good thing to do after destroy the parent, is to destroy the sub-surface object
<pq> what do you call a "sub-surface"? I thought it is a wl_surface with the sub-surface role.
<MrCooper> other wl_subsurface requests for the useless sub-surface should just be ignored though, not return errors?
<emersion> ah, no, i use it for the wl_subsurface object
<emersion> like i use "toplevel" for xdg_toplevel objects
<pq> oh, you do... I never did
<pq> because what would you then call "the wl_surface with the role"?
<emersion> MrCooper: "becomes inert" would be the wording to add
<MrCooper> (the context for my questions is https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2917 , I was wondering if mutter should handle this more fundamentally)
<emersion> pq, "the sub-surface's wl_surface"?
<pq> too long :-)
<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
Guest7940 has quit [Ping timeout: 480 seconds]
<pq> That might need a bit of explanation about why that's awesome. :-)
<zubzub> I'll explain it at the next FOSDEM :p
<zubzub> I should probably have written this all down in a series of blogposts :-/
<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
<emersion> celery, pgpy, jinja2…
kts has joined #wayland
<wlb> wayland Issue #370 opened by Aleksander (aleks-devel) Java AWT, loses focus after switching between windowsю https://gitlab.freedesktop.org/wayland/wayland/-/issues/370
<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]
bl4ckb0ne has joined #wayland
emersion has joined #wayland
soreau has quit [Ping timeout: 480 seconds]
bjasp has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
Leopold___ has joined #wayland