03:49 <dookieman> hello

03:49 <dookieman> XWayland is not setting up proper dummy resolutions, like I setup a custom modeline on sway of 1400x1050@75 and that resolution isn't showing up under xrandr so xwayland apps aren't being displayed at the proper res

03:50 <dookieman> problem persist on KDE Wayland as well, so im pinning it on xwayland(23.1.1)

07:05 <ofourdan> dookieman: please give https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1118 a try

07:24 <pq> JoshuaAshton, right. What I meant is that scRGB allows you to go outside of even BT.2020 color gamut, but because no-one actually does (yet?), you are fine with hard-clipping to BT.2020. You could hard-clip to even smaller gamut if games provided the "mastering display" ColourPrimaries, which might make gamut mapping even better.

07:26 <pq> JoshuaAshton, for me, handling monitors is kind of separate from handling content. I cannot make the assumption that because monitors can only accept BT.2020 signal which they cannot even show colorimetrically, no-one would go beyond. That's not future-proof. Maybe you should use Display P3 gamut instead of BT.2020, since that some monitors in the wild are supposed to be capable of.

07:29 <pq> JoshuaAshton, my critique here is about saying "just clip to BT.2020 and it's fine" as some kind of universal absolute truth. It works well enough today for what you tested, but it's not universal.

07:32 <pq> JoshuaAshton, essentially it seems that your workflow is designed to rely on the gamut and tone mapping in monitors accepting BT.2020/PQ signalling, and that's fine. It's how industry meant it.

07:33 <pq> OTOH, HLG monitors can already be bought, and SBTM should be coming.

07:35 <pq> you can probably ignore those, but I must not when I'm designing the protocol and how to use it

07:37 <pq> so nothing wrong in either that I can tell

13:39 <wlb> weston Merge request !1228 opened by Marius Vlad (mvlad) meson.build: Bump to version 11.0.91 for the alpha release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1228

13:41 <wlb> weston Merge request !1228 merged \o/ (meson.build: Bump to version 11.0.91 for the alpha release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1228)

13:41 <wlb> weston/main: Marius Vlad * meson.build: Bump to version 11.0.91 for the alpha release https://gitlab.freedesktop.org/wayland/weston/commit/65ada65973e3 meson.build

13:42 <wlb> weston New tag: 11.0.91 https://gitlab.freedesktop.org/wayland/weston/tags/11.0.91

13:58 <wlb> wayland.freedesktop.org Merge request !52 opened by Marius Vlad (mvlad) releases: add weston 11.0.91 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/52

14:01 <wlb> wayland.freedesktop.org/main: Marius Vlad * releases: add weston 11.0.91 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/9a00f1696121 releases/weston-11.0.91.tar.xz releases/weston-11.0.91.tar.xz.sig releases.html

14:01 <wlb> wayland.freedesktop.org Merge request !52 merged \o/ (releases: add weston 11.0.91 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/52)

15:29 <bl4ckb0ne> is there a client equivalent of wl_event_loop_add_idle?

15:30 <bl4ckb0ne> im working on a window toolkit and im looking for a place to kickstart my frame loop

15:44 <soreau> bl4ckb0ne: I don't think so, probably have to use epoll or something

15:44 <bl4ckb0ne> yeah, i thought about doing an event loop of my own or offer ap ollable fd