09:57pq: swick[m], interesting, sounds like it's already implemented: https://github.com/colour-science/colour/issues/647
09:59JEEB: had that visualization of gamut demoed to me at the nhk r&d open days
10:00pq: cool
10:00pq: I went through colour refrence docs, and could not find it. No wonder, as the function names do not have "gamut" nor "rings" in them.
10:01JEEB: fun :)
10:18wlb: weston Merge request !468 closed (ivi-shell: Set view mask solely based on source rectangle)
10:29qyliss: just want to check my understanding: calling wl_display_roundtrip() here guarantees that the compositor will have received the wl_surface.commit event, generated the xdg_surface.configure event in reply, and the client listeners will have run, before wl_surface_attach() is called on the next line, right?
10:29qyliss: https://github.com/emersion/hello-wayland/blob/77e270c19672f3ad863e466093f429cde8eb1f16/main.c#L164
10:32pq: yes
10:33qyliss: so if wl_surface_attach() is getting called early and I get an error that the xdg_surface isn't configured yet, that means my compositor is buggy, because it's replying to the wl_display.sync before it's configured the surface?
10:33pq: it's a toy example, where calling wl_display_roundtrip() in that specific context is fine.
10:35qyliss: (I'm very occasionally seeing a crash because the compositor receives wl_surface.attach before xdg_surface.ack_configure)
10:36qyliss: so my best guess is that this is a bug with the compositor, and it's doing things out of order, confusing the client
10:36pq: xdg_surface spec says: "...perform an initial commit without any buffer attached. The compositor will reply with an xdg_surface.configure event."
10:37pq: I guess that implies that a roundtrip should be enough.
10:37llyyr: what compositor is this?
10:37pq: I'd perhaps explicitly wait for the configure event though
10:37qyliss: https://github.com/talex5/wayland-proxy-virtwl
10:38qyliss: cool, that's all the info I need to open a clear issue, thanks
10:38pq: is that proxy itself replying to wl_display.sync instead of forwarding that to the parent?
10:38qyliss: I think so
10:38qyliss: let me check
10:38pq: that would not work
10:38pq: it would break everything that ever relied on wl_display.sync
10:38qyliss: no, I don't think it is
10:39pq: good
10:39qyliss: https://github.com/talex5/wayland-proxy-virtwl/blob/f49f69a314e2cdec4cb6833d690be5f24009c2b1/relay.ml#L1308-L1316
10:39qyliss: I'm not very good at reading OCaml, but that looks like it's forwarding it
10:40pq: libwayland-server will automatically and immediately reply to any wl_display.sync, so a proxy cannot use that.
10:48qyliss: opened this issue: https://github.com/talex5/wayland-proxy-virtwl/issues/58
11:00emersion: yeah, it's better to not rely on roundtrip for getting the first configure…
11:03pq: oh, I thought you believed it must be enough to roundtrip as it's in your demo.
11:06wlb: weston/main: Leandro Ribeiro * backend-drm: fix possible leak of struct drm_output https://gitlab.freedesktop.org/wayland/weston/commit/f9ef4e64ea12 libweston/backend-drm/ drm-internal.h drm.c fb.c
11:06wlb: weston Issue #421 closed \o/ (Ensure drm_outputs get destroyed on shutdown https://gitlab.freedesktop.org/wayland/weston/-/issues/421)
11:06wlb: weston Merge request !641 merged \o/ (Fix possible leak of struct drm_output https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/641)
11:08JEEB: emersion: btw thanks for your drm DB, it lets me check before hand whether "HDR_OUTPUT_METADATA" is listed or not for a specific piece of hardware :)
11:09emersion: :)
11:09JEEB: I hope now with a 8550U intel I have a new enough intel to also check stuff on it, since it shows blob = <nil> there :)
11:09JEEB: (Intel UHD 620)
11:11emersion: that's expected, it'll only be set to non-nil if user-space has programmed it
11:12emersion: the presence of the prop indicates whether the driver supports it
11:12emersion: note, AMD patches have landed recently for HDR_OUTPUT_METADATA
11:14pq: you mean AMD patches for Colorspace?
11:14emersion: oh, err, i mixed these up
11:16qyliss: emersion: oh, so is the compositor's behaviour here actually acceptable?
11:16wlb: wayland-protocols Issue #148 opened by Corentin Noël (tintou) xdg-shell: Allow a xdg_surface to never be rotated https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/148
11:21wlb: weston/main: Philipp Zabel * libweston: add weston_backend::shutdown callback https://gitlab.freedesktop.org/wayland/weston/commit/6d699c3f5419 libweston/ backend-drm/drm.c backend-rdp/rdp.c backend-vnc/vnc.c backend-wayland/wayland.c backend-x11/x11.c backend.h compositor.c
11:21wlb: weston/main: Philipp Zabel * backend-wayland: use to_wayland_backend https://gitlab.freedesktop.org/wayland/weston/commit/fcde7fae6623 libweston/backend-wayland/wayland.c
11:21wlb: weston/main: Philipp Zabel * libweston: move weston_compositor_shutdown call out of backends https://gitlab.freedesktop.org/wayland/weston/commit/90c11cf40e5c libweston/ backend-drm/drm.c backend-headless/headless.c backend-pipewire/pipewire.c backend-rdp/rdp.c backend-vnc/vnc.c backend-wayland/wayland.c backend-x11/x11.c compositor.c libweston-internal.h
11:21wlb: weston Merge request !1280 merged \o/ (libweston: move weston_compositor_shutdown call out of backends https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1280)
11:30wlb: weston Merge request !467 closed (ivi-shell: don't check for event_mask in update_prop)
11:33qyliss: hmm https://github.com/talex5/wayland-proxy-virtwl/issues/58#issuecomment-1609301723
11:34qyliss: is it plausible that sway could be triggering the callback before sending configure?
11:40jadahl: qyliss: you cannot rely on a roundtrip to know you have received a configure event
11:41qyliss: okay, so hello-wayland shouldn't do that?
11:41emersion: sway sends configure immediately
11:42jadahl: qyliss: no, that'd be a bug
11:44jadahl: qyliss: but my guess for the proxy thing is that it's something else. how does the proxy work btw? is there some libwayland-server.so server that proxies messages for a set of interfaces to the host?
11:45qyliss: my understanding is that apart from XWayland, it just relays everything
11:45jadahl: how does it relay things?
11:46qyliss: either by directly opening a unix connection to another compositor (not very useful, I assume mostly for testing), or via virtio-gpu, where the proxy runs in the guest, and crosvm on the host connects to the host compositor
11:47jadahl: qyliss: some light browsing it does seem to depend on libwayland in some way, and has a set of protocols it forwards. then a naive guess is that wl_display.sync() is implemented by libwayland-server.so, which means that it doesn't actually roundtrip all the way to the host compositor, which will break a bunch of assumptions
11:48qyliss: I don't think it does
11:48qyliss: I linked the code earlier where it appears to forward sync to the host
11:48qyliss: https://github.com/talex5/wayland-proxy-virtwl/blob/f49f69a314e2cdec4cb6833d690be5f24009c2b1/relay.ml#L1308-L1316
11:48jadahl: ah, then that's not it then I guess
11:48qyliss: I could be wrong, as I said, I'm not very good at reading OCaml
11:50emersion: qyliss: https://github.com/emersion/hello-wayland/pull/19
11:50qyliss: thank you :)
11:59JEEB: emersion: nice re: colorspace, that was a weird mismatch
12:03pq: yeah :-D
12:05wlb: wayland Merge request !320 closed (Draft: tests: unbreak os_wrappers_dupfd_cloexec on FreeBSD)
12:15wlb: wayland Merge request !325 merged \o/ (tests: manually wrap libc functions https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/325)
12:15wlb: wayland/main: Simon Ser * tests: manually wrap libc functions https://gitlab.freedesktop.org/wayland/wayland/commit/4ec379ebcc4d src/wayland-os.c tests/os-wrappers-test.c
12:26vbt: Hello. wayland noob here. I am adding some feature to a panel based on layer shell. i wanted to reduce the width of panel to 1px. i was told to use wp_viewporter. panel is in gtk.
12:26vbt: what's the good method to do so?
12:35wlb: weston Merge request !1284 merged \o/ (toy-toolkit: Fix rotations https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1284)
12:35wlb: weston/main: Derek Foreman * toy-toolkit: Fix rotations https://gitlab.freedesktop.org/wayland/weston/commit/f0196739ae42 clients/window.c
15:21wlb: weston Merge request !1285 opened by Daniel Stone (daniels) Create and destroy subsurface views at source, many view/surface cleanups https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1285 [Core compositor], [Desktop shell], [libweston API]
21:21wlb: wayland/main: Alex Yang * debug: Replace "@<id>" with "#<id>" in logs https://gitlab.freedesktop.org/wayland/wayland/commit/6d3334657180 src/connection.c src/wayland-client.c src/wayland-server.c tests/queue-test.c
21:21wlb: wayland Merge request !319 merged \o/ (debug: Replace "@<id>" with "#<id>" https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/319)
23:54wlb: weston Merge request !1286 opened by Daniel Stone (daniels) tests: Add cross-thread breakpoints and paint-node test https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1286 [Testing]