07:22MrCooper: huh, can't remember the last time I got any PM spam
07:30NotTheBees: I don't know if this is the right place to report this, but if I try to download the latest alpha from the releases page it only downloads a signature file
07:37ofourdan: not sure, latest alpha for which project? Best for you would be to post here the link you're trying to use to download, se people here can figure this out.
07:44ofourdan: ah you're right, the link for weston-12.0.91.tar.xz actually points to the signature file! https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.91/downloads/weston-12.0.91.tar.xz.sig
07:53wlb: wayland.freedesktop.org Merge request !67 opened by Olivier Fourdan (ofourdan) releases: Fix the link to the tarball https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/67
07:53ofourdan: there ^
08:26wlb: wayland.freedesktop.org/main: Olivier Fourdan * releases: Fix the link to the tarball https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/ef10de5b9744 releases.html
08:26wlb: wayland.freedesktop.org Merge request !67 merged \o/ (releases: Fix the link to the tarball https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/67)
08:26mvlad: ofourdan, thanks!
08:28ofourdan: yw!
08:28ofourdan: was easy enough to fix :D
08:35MrCooper: drakulix[m]: VK_hdr_layer sounds cool
09:18NotTheBees: q
09:18NotTheBees: \quit
09:18ofourdan: I'd rather not
09:29llyyr: anarsoul: I've never got a spam PM and the only oftc channels I'm in are this and #dri-devel
09:29llyyr: so it's most likely a different channel
09:32kennylevinsen: well if one were to spam the user list in naïve alphabetical order, maybe one would be disconnected before reaching 'l', 'k' or 'M'...
09:36llyyr: time to fill channels with a bunch of dummy _names? :D
09:37pq: I haven't got any PM spam in... I can't even remember when could have been the last time.
09:40emersion: if you get PM spam, you can set +j on yourself (reject PM from unauth users)
09:41pq: oh, that's nice to know
09:46MrCooper: I have vague recollection of doing so, how can I check?
09:47emersion: you can "/mode MrCooper", the server should reply with the current list of modes
09:47wlb: weston Merge request !1379 opened by Erico Nunes (enunes) Draft: clients/simple-vulkan: New Vulkan client example https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1379
09:47MrCooper: thanks, it's not there
09:49emersion: (the full user mode list is https://oftc.net/UserModes/)
11:25wlb: weston Merge request !1380 opened by Colin Kinloch (ColinKinloch) clients/stacking: Allow windows to be closed https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1380
12:18Company: pq, swick[m]: Does the color management protocol concern itself with the question of when two colorspaces are equal, ie when you don't need to transform to go from one to the other?
12:18Company: or is that implementation defined?
12:18pq: Company, what do you mean?
12:19Company: say, if some people hardcode primaries to 5 digits and somebody else to 7 digits
12:19Company: is that the same colorspace?
12:19pq: ah
12:19JEEB: (that's why CICP/H.273 enum values are <3)
12:20Company: JEEB: that's what made me think about it, yes
12:20pq: we need some recommendations on how much tolerance to use, if you actually need to compare numbers
12:20Company: enums vs copy/paste
12:20pq: that's won't be in the protocol spec, though
12:20Company: obviously I have the same problem in GTK when somebody hands me a colorspace - or some icc profile
12:20pq: JEEB, btw. it seems people do not like H.273 and want to invent new enums.
12:21JEEB: huh
12:22JEEB: having matrix/primaries/transfer separately just made sense to me at least, and APPL apparently wants to make it easier to extend the list
12:22JEEB: by having a registrar entity
12:22JEEB: like mp4-ra exists for MP4 mappings
12:22pq: JEEB, https://gitlab.freedesktop.org/swick/wayland-protocols/-/merge_requests/36#note_2132420
12:24Company: the problem you run into with that is compatibility
12:24Company: if somebody adds a new format, how do you know if the compositor is expected to support it?
12:25pq: my approach to ICC profiles is to handle them as opaque boxes and use some capable CMM to spit out the mathematics.
12:25Company: or vice versa, if the compositor wants to advertise a format
12:25pq: Company, the color-management protocol already explicitly advertises all supported enum values with events.
12:25Company: yeah, but you want the CMM to spit out "this is Rec 2020 HLG"
12:26pq: Company, no I don't.
12:26Company: well, you might want to decide that yourself
12:27Company: I'm happy if some smarter entity can decide that for me
12:27JEEB: pq: yea for wayland unspecified might be indeed a value you want to block. and yes, the BT.2020 stuff got added into transfer twice
12:28JEEB: of course the current state is that effectively unspecified/unspecified/unspecified is how compositing is happening and compositors just expect it to be *something* :)
12:28JEEB: but yea, as you add an explicit protocol you might want to disallow unspecified
12:29pq: Company, that's my point: I don't want to try to out-smart the ICC profile. I want a capable CMM to tell me what it wants to happen to pixel values.
12:29JEEB: this is what probably became the 2023-09 edition of H.273 https://jvet-experts.org/doc_end_user/documents/30_Antalya/wg11/JVET-AD1003-v2.zip
12:30pq: JEEB, the thing is, the protocol does not force anyone to implement any CICP value.
12:31JEEB: sure
12:31pq: compositors can simply choose to not support the "no idea what this is" code point.
12:31JEEB: yup
12:32Company: which means apps need to hardcode stuff anyway
12:32Company: so they can fallback?
12:32JEEB: just noted that it might be a recommendation as well, since I expect the protocol to want to limit itself to explicitness? (we already have enough implicit guessing in various parts of multimedia). of course application not utilizing this protocol would still effectively be "unspecified", but can't do much about that
12:33pq: Company, the fallback should not be another enum value, but a completely different request, or just fail.
12:33Company: pq: I was thinking that it'd be an ICC profile
12:33pq: or before outright failure, do the color stuff yourself
12:35pq: Company, I think I lost track here
12:36Company: all the enum values can just be represented by constructing an icc profile encoding the matrices and primaries, no?
12:37JEEB: apparently HDR transfers require some never-seen-in-wild ICC profile version, but otherwise I guess yes? although not sure how well something like reversible YCgCo would work?
12:37Company: so the client would just fall back to that if the compositor doesn't know an enum value
12:38pq: Company, no, not at all.
12:38Company: yeah, the transfer functions might be tricky
12:39pq: ICC v2 and v4 profiles always use the profile connection space (PCS) which is kinda undefined for any HDR workflow, and the ICC model also makes assumptions that do not hold for standard WCG or HDR video.
12:40Company: I thought there was an ICC version by now that does HDR
12:40Company: is that still not out?
12:40pq: iccMAX could represent anything and everything probably, but it's also unicorn-ware
12:41Company: meh okay
12:41Company: then that approach doesn't work
12:41pq: iccMAX spec is so complicated they had write specs for each use case on how to use iccMAX
12:41pq: *had to
12:42pq: yeah, I would not attempt to describe any HDR video with an ICC file any year soon, even though ICCv4 did add CICP
12:43pq: you could use an ICC file as a container to deliver CICP, but what's the point for us?
12:44Company: it would be a kinda neat way to handle fallbacks in an app
12:44Company: 1. try the specific thing
12:44Company: 2. if the compositor doesn't know about it, send an icc profile
12:45pq: except it's actually more complicated than the first way they are the fallback for, and still require the same or more complicated support in compositors as the first way
12:45pq: as/than
12:46pq: if a compositor cannot understand CICP, then wrapping CICP into an ICC file doesn't make it better
12:46Company: that wasn't what I was thinking
12:47pq: you were thinking to use the ICC math blocks instead?
12:47Company: I was thinking that if a compositor supported CICP 2019 but not CICP 2021, then those new enums could be put in an icc profile instead
12:47pq: pipelines, what do you call them... AToB etc. elements
12:47pq: I don't understand how that's any different.
12:53pq: In the end, I see the color enum support question as identical to e.g. pixel format support. Either the compositor supports the format, or it doesn't. If the compositor doesn't, the client needs to use something else.
12:53JEEB: yup
12:54JEEB: in theory you may attempt to hack around by trying to generate a "close enough, maybe" ICC profile. but that's not exactly what you're trying to present
12:54Company: I suppose it doesn't buy you anything anyway
12:54pq: things might be different if clients could send shader programs to the compositor to decode their contents, and that's... not too far away from iccMAX
12:55Company: all you do is make the compositor do a suboptimal color conversion when you could do a better one
12:55Company: though I guess you would save a copy of the pixels
12:55pq: yeah
12:55pq: yup
12:58pq: that's what HDR with ICCv4 is AFAIU: if the CMM handles the HDR specifics explicitly, you get ok result. If the CMM handles only the "usual" ICC stuff, you get a pretty bad approximation.
13:00pq: also AFAIU, those HDR specifics are pretty much the same we carry in color-management extension explicitly
13:02pq: however, given how the "fallback" is built in to ICC profiles (the spec says: do this, or if not then this, and then this, in descending order of correctness/precision), the client wouldn't even know which part of the ICC profile is even used by the compositor.
13:02pq: at least with color-management parametric image descritions, there is no "silent degradation"
13:03pq: everything supported is explicitly advertised
13:03Company: right, so the fallback should not be "try to convince the compositor some other way" but "do it on the client"
13:04JEEB: yea
13:04pq: indeed
13:09pq: zamundaaa[m], did you forget to reply to list when you emailed me? :-)
13:10zamundaaa[m]: yes. Gmail really doesn't handle mailing lists well
13:15pq: zamundaaa[m], the classification could be like "definitely < 0.5 ms", "< 10 ms surely", and "long", but I didn't want to spin off on that tangent there.
13:17zamundaaa[m]: yeah something like that would be ok. That could also be put into the API as a property on the colorop (max microseconds this operation may take), then the compositor can properly work with it
13:18zamundaaa[m]: Only situation that would still be tricky is if a colorop gets programmed over a bus that's shared with multiple other colorops
13:19pq: I would just assume that all programming is strictly serial.
13:20pq: IOW, sum, not max, of all changed colorops
13:25lordmzte: Hello! I'm having a bit of an issue with EGL on wayland: I've got a custom event loop set up which constantly polls the wayland FD, dispatching events immediately as they come in. Now I'm also rendering some stuff using EGL and when I'm done I cann eglSwapBuffers. This function however (at least on the nvidia driver) ends up ALSO poll()ing the wayland socket FD. As my event loop is
13:25lordmzte: already doing this though, it causes my whole program to deadlock after rendering one frame, as eglSwapBuffers never returns. What do I do about this?
13:26emersion: eglSwapInterval(0)?
13:26emersion: https://emersion.fr/blog/2018/wayland-rendering-loop/
13:26emersion: damn, 5 years already…
13:26kennylevinsen: let's not think about that
13:27lordmzte: yep, looks good!
13:27lordmzte: thanks!
14:54DemiMarie: Is there interest in a windows-shell protocol for use with Wine? Without it Wine will be stuck on Xwayland forever.
14:56DemiMarie: The Wayland driver being worked on cannot handle all applications without this protocol. Virtual desktop can, but it is very bad UX.
15:00emersion: maybe
15:04DemiMarie: Would a read-only “where am I?” protocol be accepted? What about one that provided read-only access to the relative position of two windows?
15:05emersion: i don't think that's a good idea
15:06DemiMarie: I have it on good authority (Qubes OS’s UX person) that there are legitimate reasons for applications to know this information, and it does not seem anywhere near as problematic as a protocol that allows writing.
15:06emersion: a shell which implements the exact win32 semantics would be way better
15:06DemiMarie: emersion: why is it a bad idea?
15:06DemiMarie: This is for a different use-case.
15:06emersion: i don't believe there is a legitimate use-case
15:07DemiMarie: One is for Wine, the other is for complex multi-window GUI applications.
15:08DemiMarie: Did I violate some unwritten netiquette rule by starting two conversations at once?
15:09emersion: no, i didn't realize the two were not connected
15:10DemiMarie: Anyway, the legitimate use-case is so that if I have more than one window, I can have one window e.g. draw an arrow pointing to another or something like that.
15:11emersion: that sounds a lot like xeyes
15:11emersion: … which isn't very compelling use-case to me
15:13ids1024: One thing with wine-specific protocols: how can the compositor restrict the protocol to only wine? With XWayland it can since it starts XWayland.
15:14emersion: one way would be to somehow store the bit "needs win32 APIs" in .desktop or something
15:14emersion: then security-context
15:14DemiMarie: ids1024: good point, and it also runs into another problem, which is that some people want to sandbox Wine.
15:16ids1024: If the protocol does things that non-wine apps may want to do, but is universally available and not just available to wine, it ceases to really be a wine specific protocol.
15:17emersion: it would completely replace xdg-shell, so not _that_ easy to use
15:17ids1024: True. Switching shell protocol for one particular feature isn't all that practical.
15:25DemiMarie: For me, virtual desktop would be an acceptable fallback for applications that cannot be supported with xdg-shell, but I suspect many users would disagree and for good reasons.
15:28Company: as a toolkit person, this is also tricky
15:28Company: because the app devs come to me and say "wine can do that, why can't you?"
15:33MrCooper: are they doing so with s/wine/Xwayland/ ?
16:37YaLTeR[m]: Demi: what relative position do you give in compositors without a global 2d coordinate space for windows?
16:55DemiMarie: MrCooper: Right now Wine relies on Xwayland. As per their XDC2023 talk the Wine devs don’t think they can support every application natively on Wayland.
17:08MrCooper: DemiMarie: my point was if app devs are going to ask for Wine's privileges, they should be asking for Xwayland's now
18:02mclasen: I have a question on the limitations of the viewporter protocol
18:03mclasen: it limits the source rect to 'inside the buffer' - is there a strong reason for that ?
18:04mclasen: if I could specify dimensions outside, I could use that to effectively render at a fractional destination rect
18:04mclasen: which would be nice
18:04vyivel: where else would it read pixels from?
18:05mclasen: if there's no pixel, transparent black works for me
18:05mclasen: or I guess you can introduce clamp modes like gl textures
18:11wlb: wayland-protocols Issue #163 opened by Matthias Clasen (matthiasc) Limitations of viewporter https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/163
22:44orowith2os[m]: Beep boop
22:44orowith2os[m]: There we go :)