00:09 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
00:13 wlb: wayland New tag: 1.21.92 https://gitlab.freedesktop.org/wayland/wayland/tags/1.21.92
00:15 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
05:33 DemiMarie: Is it possible for an Xwayland surface to have subsurfaces?
07:32 emersion: not at the moment
08:05 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.
08:06 pq: emersion, thanks for the release!
08:06 emersion: np!
08:44 ofourdan:coughs !188 ;)
08:55 zubzub: pq: I've made some changes on how I handle display sync requests: https://docs.google.com/drawings/d/e/2PACX-1vTHYes7F3Gyt2HeuJtrOhOqOVnqBu5za6eso5x_n_R-VdxcswKbcslsoSqkGVrFZKWhxhInvVRrtH3P/pub?w=960&h=720
08:55 zubzub: so far it seems to correctly handle everything I throw at it
08:56 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
09:01 zubzub: I should probably make a video playing doom3 running remotely in the browser as an extra flex :p
09:04 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.
09:05 zubzub: yeah it's pretty minimal, should probagly extend it a bit
09:06 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.
09:06 pq: *whole
09:07 pq: so when I talk to you about what a compositor does, that applies only to the app-local server
09:08 zubzub: yeah that's not the case here, I should probably make a separate diagram to show how it works
09:08 pq: and the app-local server from the app's point of view, even
09:08 pq: zubzub, also something that can be viewed without saving to disk first, too ;-)
09:09 zubzub: pq: I'll send an email to Google ;)
09:09 zubzub: (I agree that is annoying)
09:10 pq: zubzub, ok, I think I get your diagram, and I very much agree with your design.
09:11 pq: zubzub, it actually doesn't differ from the "Classic" case semantically.
09:12 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)
09:12 zubzub: pq: indeed that's the idea
09:13 pq: Something like this is what any wayland compositor with a remote backend would do, with varying details.
09:14 zubzub: yup, but those usually just remote the rendering part
09:14 pq: more like the opposite?
09:15 zubzub: yeah, like, only the final output image is send over network
09:15 zubzub: compositor state is kept server side
09:15 pq: yeah
09:15 pq: depends on the remoting style which side is compositing, but it doesn't really make difference in this question
09:16 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 :-)
09:17 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
09:19 zubzub: yup, split brain
11:26 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?
11:28 emersion: MrCooper: this has been fixed iirc
11:28 emersion: wayland.app probably outdated
11:30 MrCooper: are you thinking of 9700155edaae ("protocol: wl_subsurface::destroy does not remove the role") perhaps?
11:31 MrCooper: can't find anything else related
11:32 emersion: i think yes
11:32 emersion: does it not fix it?
11:32 MrCooper: no, that's about the wl_surface of the sub-surface itself, not the parent
11:33 MrCooper: protocol/wayland.xml still has the same seemingly contradictory language about the parent
11:34 emersion: ah, i see
11:34 emersion: send patch?
11:38 pq: what did I mean by that...
11:38 JEEB: picking the past brains of yourself is a skill that many wish they had
11:39 emersion: the question here is whether or not to send a protocol error when the parent is destroyed before the child wl_subsurface
11:40 emersion: the sub-surface parent is immutable, so the sub-surface cannot be re-mapped after parent destroy
11:40 pq: emersion, there never was an error for that before, right? So there will not be one now.
11:40 emersion: you mean in the enum?
11:40 pq: I mean sent by anyone ever
11:41 emersion: "sub-surfaces must always have a parent" makes it sound like the compositor will send a protocol error when the parent is destroyed
11:41 pq: I don't recall wanting that to be a protocol error.
11:41 pq: ah, but that sentence is different
11:41 MrCooper: an alternative might be for the child to lose its sub-surface role
11:41 pq: The root surface in a tree of sub-surfaces is the main
11:41 pq: surface. The main surface cannot be a sub-surface, because
11:41 pq: sub-surfaces must always have a parent.
11:41 emersion: MrCooper: a role can never be lost
11:42 emersion: oh.
11:42 emersion: yeah, that's different in this context
11:42 pq: so I think that sentence is more about making it clear what a "main surface" is.
11:42 emersion: indeed
11:43 pq: I suppose sub-surfaces can be orphaned by destroying the parent, which creates a loop-hole
11:43 MrCooper: there's no way to set a new parent for the sub-surface after that though, is there?
11:43 pq: now or originally? ;-)
11:44 MrCooper: now
11:44 emersion: could be disambiguated with something like "sub-surfaces must always have a parent at creation time"
11:44 pq: emersion, that would work for me
11:44 emersion: there is no request to change the sub-surface parent to a new wl_surface (please don't add one)
11:45 pq: You *could* destroy wl_subsurface, and create a new one. Is that allowed? It could be used to change the parent.
11:45 emersion: but then it's a new sub-surface
11:46 MrCooper: so basically, destroying the parent wl_surface makes the wl_subsurface useless, it cannot be mapped anymore
11:46 emersion: correct
11:46 emersion: the only good thing to do after destroy the parent, is to destroy the sub-surface object
11:47 pq: what do you call a "sub-surface"? I thought it is a wl_surface with the sub-surface role.
11:47 MrCooper: other wl_subsurface requests for the useless sub-surface should just be ignored though, not return errors?
11:47 emersion: ah, no, i use it for the wl_subsurface object
11:48 emersion: like i use "toplevel" for xdg_toplevel objects
11:48 pq: oh, you do... I never did
11:49 pq: because what would you then call "the wl_surface with the role"?
11:49 emersion: MrCooper: "becomes inert" would be the wording to add
11:49 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)
11:50 emersion: pq, "the sub-surface's wl_surface"?
11:50 pq: too long :-)
11:50 emersion: in any case, if the difference between the two is important to you, "sub-surface" is not enough
11:51 pq: ok. Yes, it is important.
11:56 pq: btw. originally wl_subsurface.destroy explicitly documented that it removes the role from the wl_surface. That was extremely clear.
11:56 pq: Yes, it was different from anything else, but it was explicit.
11:57 pq: I don't see any discussion being hand about what implications changing that would cause.
11:57 pq: *had
11:58 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".
11:59 pq: Given that no-one apparently noticed that change, no-one relied on removing the role.
11:59 pq: or no compositor implemented the new behavior
11:59 emersion: wlroots does
11:59 pq: that's good
11:59 pq: probably from the start, right?
12:20 swick[m]: pq: did you notice that h.274 uses the terms content colour volume and mastering display colour volume?
12:21 pq: swick[m], I didn't read it yet, no.
12:22 swick[m]: it doesn't really define them though
12:22 pq: *facepalm*
12:22 pq: just like we :-P
12:23 swick[m]: it's not great that we have terms which don't match with ITU
12:24 swick[m]: but not sure if we should change it again, especially because I'm not 100% sure what they mean
12:26 JEEB: yea H.274 just defines the metadata blocks (and has some very basic explanation on their semantics)
12:26 swick[m]: and 5 pages of definitions
12:26 swick[m]: not for the color volumes though
12:28 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.
12:28 swick[m]: makes sense
12:29 JEEB: yea I wonder where those came from
12:29 pq: two different terms meaning the same thing is solvable, the same term with different meanings is... gamma :-p
12:29 JEEB: probably if one goes through the history of JVET-experts documents
12:29 JEEB: (thankfully that stuff is 100% public)
12:30 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
12:30 swick[m]: "RGB unspecified color space (Legacy RGB mode)"
12:31 swick[m]: and AMDGPU defaults to sRGB, not this for DRM_MODE_COLORIMETRY_DEFAULT
12:31 swick[m]: such a mess
12:32 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
12:33 JEEB: specifically what the output of an application is for the compositor (which then gets pushed onto the output config)
12:36 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
12:36 JEEB: since everyone just utilized ICC profiles or so to work around the problem
12:37 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.
12:39 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.
12:39 pq: I suspect the vagueness is the right answer: monitors display it in too wildly different ways
12:40 swick[m]: that's still very different than forcing sRGB
12:40 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
12:40 pq: yes, it is not sRGB.
12:41 pq: so "shiny better colors" is what you get when you set unspecified legacy RGB
12:42 pq: "better" being very much sarcastic here
12:42 pq: or should I say very much marketing
12:43 Dejan: it won't help me much, i am colour blind
12:43 swick[m]: JEEB: any pointers with the JVET-experts documents for the color volume definitions?
12:44 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.
12:45 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
12:46 pq: I mean a much bigger lie, even primaries.
12:47 swick[m]: do you know about displays where you can change the primaries with the OSD?
12:47 pq: hmm... I can do *something*
12:47 swick[m]: the ones I've seen so far all allow for adjusting the RGB channels separately
12:48 swick[m]: which gives you another white point with the same primaries
12:48 pq: right, so you would need to be able to adjust minimum emission of each channel
12:49 pq: to reduce color gamut, which mimicks moving the primaries
12:49 swick[m]: yup
12:56 pq: nope, can't see such adjustments in my monitors
12:56 pq: swick[m], I mean, the monitor firmware could automatically do that though, for certain signal types.
12:57 pq: but I also assume that monitor physical primaries are not matching the CTA-861 default colorimetry.
12:58 pq: of course they don't for WCG monitors, but I suspect also other monitors
13:04 zubzub: 10:01 zubzub: I should probably make a video playing doom3 running remotely in the browser as an extra flex :p
13:04 zubzub: https://www.youtube.com/watch?v=pTn_hjOwK-Y
13:08 pq: That might need a bit of explanation about why that's awesome. :-)
13:09 zubzub: I'll explain it at the next FOSDEM :p
13:10 zubzub: I should probably have written this all down in a series of blogposts :-/
13:12 JEEB: swick[m]: https://jvet-experts.org/doc_end_user/all_meeting.php
13:12 JEEB: that should have history from 2015 to NOW()
13:13 bl4ckb0ne: pq: often its just a lack of proper packaging and time/space
13:13 bl4ckb0ne: i made a few static version of packages in alpine and never had any issues
13:15 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.
13:17 bl4ckb0ne: alpine does it well fwiw
13:17 pq: yes, it *can* be done, but why bother?
13:17 bl4ckb0ne: ah and cmake requiring to re-generate the files to make a static lib leading to 2* build time
13:17 bl4ckb0ne: yeah why bother
13:17 bl4ckb0ne: :(
13:18 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
13:19 pq: that's what I mean - not that it wouldn't work but because it causes more work
13:19 pq: and you need to keep track of which binary linked what statically, and the runtime linker cannot help you check that
13:20 pq: so I think I see both sides of that coin, the other side being binaries that are more portable and break less
13:21 pq: application binaries, specifically, not lib binaries
13:22 pq: if you never need to ship bug fixes to libraries, then it's a different story
13:29 emersion: i like how C-specific the dynamic linking problem is presented
13:30 emersion: while all other languages (Rust, Go, Zig, …) just use static linking and don't bother with anything else
13:30 pq: which makes it useless to talk about dynamic linking with those: it does not exist
13:30 qyliss: With Rust it does exist I think
13:31 pq: not in any stable form
13:31 pq: unless of course you go out of your way to define a C ABI for your Rust libs, which... no
13:31 qyliss: yeah, but whether that matters depends on the distro
13:32 qyliss: it's a problem for most, but would be no problem for us in Nixpkgs, for example
13:32 qyliss: (static is also not a problem, for the same reason)
13:32 emersion: qyliss: i mean yeah it can always be done… but almost nobody does it
13:32 qyliss: yeah
13:33 qyliss: we have one of the only setups where it would make sense and even then we don't bother
13:33 pq: What is the easiest way to distribute bug fixes into sharable software components? Isn't the answer to that inherently language-specific?
13:34 pq: how much do you need to rebuild, how much binaries do you need to update and distribute
13:36 pq: or do you distribute only sources, and every end user rebuilds on their own
13:36 bl4ckb0ne: that ends up being a lot of compute time to spare a few kilobytes
13:36 pq: what is globally most efficient
13:36 pq: yes, exactly
13:36 DemiMarie: qyliss: nixpkgs might want to start using Rust dynamic linking.
13:37 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
13:40 emersion: there are languages where you distribute sources and every end user rebuilds their own everytime they run the program ;)
13:52 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
13:53 emersion: hm, it really depends
13:53 emersion: exhibit A: npm
13:54 pq: Isn't that the ecosystem where a tiny change in a tiny component can immediately bring down huge production systems? :-)
13:55 emersion: tbh i've been dealing with lots and lots of breakage in Python too
13:57 emersion: celery, pgpy, jinja2…
14:07 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
14:08 psykose: the issue is that people write too much code
14:08 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
14:09 psykose: how many xml parsers do you have on your system, do you think?
14:10 bl4ckb0ne: not enough
14:11 emersion: to start things of, libwayland has two :P
14:11 emersion: off*
14:11 psykose: :-)
14:12 bl4ckb0ne: how come?
14:12 emersion: one for parsing, one for checking DTDs
14:12 MrCooper:
14:12 emersion: (latter is optional)
14:13 MrCooper: (I accidentally hit enter instead of backspace)
20:50 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
20:50 swick[m]: 3.6 colour volume: Space of all colours and intensities that a device or signal can reproduce or convey.
20:51 swick[m]: "The approved colour volume, which can be smaller than the container volume, is often indicated with SMPTE ST 2086 metadata."
20:53 swick[m]: the Mastering display colour volume is defined well and they use container colour volume as well
20:54 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"
20:55 swick[m]: so they use "utilized colour volume" and "approved colour volume" for what we call "target color volume"
20:55 swick[m]: not sure what to make of this
21:15 JEEB: swick[m]: right that supplement
21:16 swick[m]: well for CICP, not for h.273
21:17 JEEB: H.273 is the ITU published version of CICP :)
21:17 swick[m]: eh, right, I meant h.274
21:18 JEEB: ayup
21:18 swick[m]: off by one errors on specification numbers
21:18 JEEB: :)
21:18 JEEB: talking of JVET archives, it's fun how latest minus 1 meeting has an actual errata doc for CICP etc
21:19 JEEB: not that it has a lot, but it's fun to see what they're thinking about