01:46 jadahl: daniels: I saw, will make one tonight
02:50 soreau: I wanted to make a backdrop display using a background app and some app that displays time and weather with weather icon. Background apps are plenty.. does anyone have suggestions on possibly existing implementations for an app with transparent background featuring time/temp/weather-icon that is configurable?
09:27 wlb: weston Issue #992 opened by thibault (eldoccc) "ghost" window on arm64 when using transform https://gitlab.freedesktop.org/wayland/weston/-/issues/992
09:46 pq: emersion, right. Mastering Display Color Volume (MDCV) is defined for image content that has been graded/mastered on a display.
09:47 pq: emersion, the description of a (compositor's) display is not mastered, it's a display and not content, so using MDCV for it sounds weird. Hence we use "target color volume".
09:48 pq: emersion, content targets a color volume (the MDCV), and a display has a target color volume (what it can actually display).
09:53 pq: ezzieyguywuf, pkgdatadir variable from wayland-protocols.pc
09:57 pq: emersion, JEEB, re: sRGB vs G22 TF; https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/wayland_qa.md#q-should-srgb-content-be-decoded-with-the-piecewise-srgb-transfer-function
10:04 JEEB: yea that is more or less what I meant
10:05 JEEB: the refernece display is G2.2
10:05 JEEB: and I like how that win11 ICC repo is linked as example 8)
11:02 pq: JEEB, I may have got that win11 ICC link from you, I can't recall. :-)
11:06 JEEB: I think someone else posted it here before me, since I recall picking it up from here and then utilizing it elsewhere :)
11:07 pq: I could grep my logs, but can't bother.
11:11 JEEB: > 12:03 < JoshuaAshton> Oh wow, someone made a fix for Win11 using piecewise for SDR content: https://github.com/dylanraga/win11hdr-srgb-to-gamma2.2-icm
11:11 pq: cool!
13:09 wlb: wayland/main: Sebastian Wick * server: add const qualifier to function arguments where possible https://gitlab.freedesktop.org/wayland/wayland/commit/bdba21ec92bf src/ wayland-server-core.h wayland-server.c wayland-shm.c
13:09 wlb: wayland Merge request !326 merged \o/ (server: add const qualifier to function arguments where possible https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/326)
13:24 wlb: wayland-protocols Merge request !380 opened by Jonas Ådahl (jadahl) build: Bump version to 1.40 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/380
13:27 emersion: pq, so, deocde with gamma22, encode with srgb tf?
13:29 zamundaaa[m]: emersion: never mix them
13:29 emersion: aha
13:29 emersion: so pick one and do both encoding/decoding with it?
13:29 zamundaaa[m]: If you want the content to look like it would on the vast majority of displays, use gamma 2.2
13:30 emersion: so, clients all use gamma22 for encoding?
13:30 emersion: hm, no
13:30 zamundaaa[m]: No, it's more messy than that
13:30 emersion: they use srgb but expect gamma22
13:30 zamundaaa[m]: yes
13:30 emersion: but it doesn't matter what clients use
13:30 zamundaaa[m]: It does, when it comes to content creation
13:31 pq: emersion, the important part is that "encode with two-piece, decode with gamma22" happens exactly once on the pixel path from app to screen.
13:31 emersion: the important bit is that they expect gamma22 and any color transform in the middle should preserve gamma22
13:31 emersion: right
13:31 emersion: and gamma22 decoding gives something closer to what shows up on-screen
13:31 pq: An sRGB display will always decode with gamma22.
13:32 pq: When you get sRGB content from apps, you can assume it has been encoded with two-piece.
13:33 pq: You can push sRGB content unmodified to an sRGB display, and that achieves the "exactly once".
13:34 pq: If you need to roundtrip to an optical domain in between, then you can choose, but you have to use the same TF for both decoding and encoding.
13:34 pq: Then "exactly once" happens as it should.
13:35 wlb: wayland-protocols/main: Jonas Ådahl * build: Bump version to 1.40 https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/c7b582cb71ec meson.build
13:35 wlb: wayland-protocols Merge request !380 merged \o/ (build: Bump version to 1.40 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/380)
13:36 pq: If you have sRGB content but PQ display, you decode the content with gamma22 (the "exactly once" thing"), do the conversion to HDR and encode for PQ
13:37 emersion: all makes sense, thank you!
13:37 emersion: sorry about all of the questions!
13:38 pq: If you have PQ content and sRGB display; decode with PQ, tone-map down to SDR (assuming tone-mapping algorithm was defined in optical spaces), and encode with gamma22 so that when display decodes with gamma22 it produces what you encoded.
13:38 emersion: yup, encoding with srgb tf doesn't make sense in that case
13:39 pq: emersion, oh, no, not at all. If you want to give back on the same topic, you can suggest stuff to color-and-hdr. :-)
14:06 wlb: wayland-protocols New tag: 1.40 https://gitlab.freedesktop.org/wayland/wayland-protocols/tags/1.40
14:11 davidre: \o/
15:05 WhyNotHugo: Protocol definitions don't specify whether a given interface is an singleton or not. Is there any way to determine this, or should clients/libraries just keep a hardcoded list?
15:07 kennylevinsen: The protocol doesn't support singletons - that would require being able to return a newid *or* an old object ID
15:08 emersion: i think you mean "global"
15:08 emersion: there is an issue about this
15:08 emersion: i don't think clients need any kind of database like this - you need code to bind to a global anyways
15:10 pq: The singleton terminology tends to only apply to interfaces that are advertised via wl_registry, a.k.a "globals". The protocol XML codifies neither singleton'ess nor globals.
15:11 pq: Nor does the protocol codify whether a global can dynamically appear or disappear.
15:12 pq: WhyNotHugo, why would you need this information?
15:12 kennylevinsen: I guess it wouldn't hurt to formally codify even if no program will depend on it
15:13 zamundaaa[m]: pq: if xdg shell can appear twice, you'd need code guarding against that case to avoid leaks
15:17 WhyNotHugo: Client libraries sometimes special-case binding to single-instance globals. But trying to bind to a non-single-instance global (e.g.: a seat) is left as undefined behaviour.
15:20 pq: How would the protocol codifying globals and singletons help?
15:20 davidre: I wonder if people would start today if wl_output would not be a global but a wl_output manager
15:20 davidre: s/wl_output/wl\_output/, s/wl_output manager/wl\_output_manager/
15:21 davidre: (disregarding the question if wl_output should exist or not)
15:25 pq: I would probably need to see the code to undertand problem well, but it's too late today for me.
15:39 emersion: davidre: yeah, i think that's the way i would do it (but would also think avoir a better way to deal with server-side created object races)
15:50 WhyNotHugo: pq: codifying that objects are singletons would enable generated client libraries to prohibit using non-singletones in APIs for singletons (e.g.: detecting them at compile time)
15:51 WhyNotHugo: E.g.: https://docs.rs/wayrs-client/latest/wayrs_client/struct.Connection.html#method.bind_singleton
15:51 WhyNotHugo: (this is mostly the case in helpers which wrap around wl_registry).
15:51 WhyNotHugo: davidre: ya, output_manager is obvious in hindsight
15:52 pq: I guessed this was about a Rust abstraction :-)
15:54 pq: WhyNotHugo, is this a convenience function so that the caller does not need to shuffle thought a list of one global?
15:56 pq: and you want the app to fail to build if it tries to bind a non-singleton as a singleton?
15:58 pq: WhyNotHugo, are things like struct WlCompositor generated from XML?
16:00 pq: yeah, seems like it would be nice to codify globals and singletons in XML.
16:02 WhyNotHugo: Yes, it's a convenience function
16:02 pq: something like interface attribute generic-factory="wl_registry"
16:02 WhyNotHugo: All clients and stuff are auto-generated at compile-time from the XML files.
16:12 DemiMarie: pq: Would it make sense for the XML to specify the error one gets when trying to use a nonexistent enum value?
16:12 ezzieyguywuf: pq: thank you!
16:13 pq: DemiMarie, usually that's is documented.
16:13 ezzieyguywuf: I've been toying around with wayland and vulkan, and one thing I'm a bit confused about is the difference/relationship between a wl_surface and a VK_KHR_surface - it seems I can use vkCreateWaylandSurfaceKHR to create a VK_KHR_surface FROM a wl_surface, but it's unclear to me if I even need to do this
16:13 DemiMarie: pq: I'd like to autogenerate the validation code.
16:15 pq: DemiMarie, that would need to be an attribute of the request that uses the enum, since there may be multiple such requests in different interfaces without a common error code.
16:15 DemiMarie: pq: that is what I was thinking, yes
16:15 pq: in the arg tag, actually, since a request might have multiple enum args
16:16 DemiMarie: Also, mind reviewing my PR for busy-loops in the server?
16:16 pq: sounds doable, but I can't judge if it's worth it
16:17 pq: no, sorry
16:17 DemiMarie: Who should I ping for that?
16:17 pq: I have to prioritize harsly nowadays what I do
16:17 DemiMarie: Is it just a case of "be awake morning EU time"?
16:18 pq: I dunno, I don't track much who's active on libwayland anymore
16:19 pq: I should have stopped for the day already, I'll be back on Monday. \o.
17:03 wlb: wayland-protocols Issue #240 opened by Robert Mader (rmader) linux-dmabuf: Clarify how udmabuf should be handled https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/240
19:48 riteo: Hi, no idea if this is the right place. Can somebody please clear me up on whether the xkb_state from libxkbcommon is supposed to be per-window or per-seat? It looks like everybody is doing it per-window but looking in the documentation I see no reason as of why; we only have a wl_keyboard per seat.
19:50 orowith2os[m]: Multiseat situations, maybe? Think kiosks
19:51 riteo: well a seat is going to have a single keyboard focus anyways
19:52 riteo: like, I already have a xkb_state per seat
19:53 riteo: but I got told years ago that I should not do that for multiple windows but now that I'm actually doing that I don't know why I should.
19:53 orowith2os[m]: Maybe not? You could have several windows running that receive input events
19:53 orowith2os[m]: Either through automation or weird compositor setups
19:53 riteo: isn't the keyboard event sent from the wl_keyboard
19:54 riteo: like, currently I do wl_keyboard::key -> get seat state for that kb -> look at focused window id -> build "toolkit" input key event with the right id
19:54 riteo: (I say toolkit for clarity but it's still godot, as usual)
19:57 orowith2os[m]: I'm trying to make sense of the wl_seat stuff to see if it would cause problems, I'm not seeing anything about several seats not being allowed
19:57 orowith2os[m]: So you could, I guess, have two different wl_surfaces getting wl_keyboards from two different wl_seats
19:58 riteo: yes but doesn't it work, like, backwards
19:58 riteo: as in, wl_seats track keyboard focus?
19:58 riteo: wait a sec
19:59 riteo: ye wl_pointers and wl_keyboards get enter events
19:59 riteo: so like it should be fine to track everything per seat, it should be unnecessary to have a whole xkb state per window
19:59 riteo: but everybody's doing it different and I'm not sure why
20:00 riteo: like, my mental model seems to allow multiple seats per window fine
20:00 riteo: it's the seat that tracks the window after all
20:14 zamundaaa[m]: riteo: your mental model is correct
20:15 zamundaaa[m]: You could have two seats that have the same window focused, and keyboard state should be per seat
20:22 riteo: yay!
20:23 riteo: thank you zamundaaa for clarifying :DDDDDDDDDDDDDDDDDDD