03:24 <tokyovigilante> although I am a bit surprised that creating a swapchain without that bit, and then rendering to it didn't give any validation layer errors

05:23 <tokyovigilante> ah seems I didn't actually have validation layers enabled properly either... Message: vkCreateSwapchainKHR(): pCreateInfo->imageUsage contains flag bits (0x10000) which are not recognized members of VkImageUsageFlagBits.

05:23 <tokyovigilante> Better late than never :)

05:50 <kennylevinsen> still odd behavior

05:51 <kennylevinsen> the driver should reject the buffer if it doesn't like it

05:51 <kennylevinsen> so I still kinda think a driver bug may be in play

06:06 <tokyovigilante> Yup, I can't replicate it in a tidy sample either, a single-file C++ rewrite with the same error still renders in fullscreen (i'm assuming without direct scan-out). However finding the bug and then fixing it in my Nim app allows fullscreen rendering with the BGRA8 buffer

08:17 <wlb> weston Merge request !1758 merged \o/ (xdg-shell: fix weston crash while send configuration https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1758)

08:17 <wlb> weston/main: liang zhou * xdg-shell: fix weston crash while send configuration https://gitlab.freedesktop.org/wayland/weston/commit/4e4d7993baff libweston/desktop/xdg-shell.c

08:17 <pq> emersion, re: intel's 32-bit LUTs; I'd have to take a look. Busy times.

08:20 <pq> emersion, re: wide gamut; zamundaaa[m] is right AFAIK.

08:24 <pq> emersion, the KMS connector property "Colorspace" sets infoframe bits that tell the sink how to interpret the values on the cable. The "default" setting means interpretation defined by the sink.

08:25 <pq> The "BT2020" setting means the signal is using BT.2020 primaries for encoding the colorimetry. What the sink actually does with that information is... well. Maybe it just applies a matrix to get to the monitor native primaries and leaves it at that.

08:27 <pq> In any case, the assumed display EOTF is power-2.2 until you use the HDR_OUTPUT_METADATA to indicate another encoding in the signal.

08:28 <pq> Actually, the default EOTF is indicated in EDID. Power-2.2 is a common claim. Whether a monitor really does that is another question.

08:32 <pq> For us window system developers, the more predictable monitor the better. We don't need to drive an unknown "generic monitor", we can driver the specific monitor at hand. Broadcasting and content delivery systems don't have that luxury, which leads to content being the same for all and each display doing something to make the best of its capabilites.

08:32 <pq> We window system developers would do that "something" in our compositors, or even allow video players to do it.

08:34 <MrCooper> FWIW, I just discovered that this monitor correctly signals the colour preset (sRGB/P3/BT.709) chosen in the OSD menu via DDC VCP code 14

08:38 <MrCooper> hmm, actually that seems to define only "sRGB" (which is correctly signalled), "Display Native", colour temperatures between 4000-11500K, and "user presets" (which this monitor signals for P3/BT.709)

08:40 <pq> I'm not familiar with DDC VCP at all.

08:40 <MrCooper> looks like that might at least allow switching the monitor to sRGB mode

08:43 <MrCooper> yep, "ddcutil setvcp 14 1" does that

08:44 <wlb> weston Issue #1025 opened by Marius Vlad (mvlad) Mapping fullscreen application at start-up causes from flicker/flashes https://gitlab.freedesktop.org/wayland/weston/-/issues/1025 [Core compositor]

08:46 <pq> heh, 2 of my 3 monitors fail either DDC comms or VCP detect. And the fourth monitor I use for HDR testing is not listed at all.

08:47 <wlb> weston Issue #1026 opened by Marius Vlad (mvlad) lua-shell: Add input support/grabbing functionality https://gitlab.freedesktop.org/wayland/weston/-/issues/1026 [New Feature], [lua-shell]

08:48 <emersion> pq: i see!

08:53 <pq> MrCooper, isn't VCP 14 the color temperature? i.e. the white point

08:53 <MrCooper> pq: sounds like this monitor is an exception then :(

08:54 <pq> It's labelled here as "Select color preset", but the choices being in Kelvins is a tell.

08:54 <MrCooper> true

08:55 <MrCooper> is sRGB commonly associated with a colour temperature though?

08:56 <pq> I don't know what the convention is, but sRGB defines both white point and the primaries.

08:57 <pq> That is, unless the monitor was already using sRGB primaries, there should be a change in observed saturation between sRGB and not.

08:58 <pq> white point changes the color of white, but primaries would affect the color of the 100% red, green and blue.

09:00 <MrCooper> the monitor intermittently blanks when switching the profile, so it's hard to be sure of that with eyeballing

09:24 <kennylevinsen> a camera that can be set to fully manual exposure and white balance would be best for such comparison

09:24 <kennylevinsen> (or a colorimeter/spectrometer if one feels fancy)

09:29 <MrCooper> and unchanging weather conditions :)

09:49 <pq> if a camera can be fully manual, weather (the environment) would not affect the measurement unless directly shining on the target.

09:51 <pq> we'd also assume the gamut of the camera to be larger than that we measure.

09:53 <pq> it should be ok for different / not different testing

10:07 <MrCooper> it's more that the backlight level changes based on the ambient light sensor; I could disable that, I don't care enough to bother with any of that right now though :)

10:08 <pq> oh

13:09 <wlb> wayland-protocols/main: Xaver Hugl * staging: add ext-background-effect-v1 https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/dac6393216d2 staging/ext-background-effect/README staging/ext-background-effect/ext-background-effect-v1.xml meson.build

13:10 <wlb> wayland-protocols Merge request !272 merged \o/ (staging: add ext-background-effect-v1 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/272)

14:20 <wlb> weston Issue #1027 opened by liang zhou (snow) Use after free issue on Hotplug https://gitlab.freedesktop.org/wayland/weston/-/issues/1027

14:21 <wlb> weston Issue #1028 opened by liang zhou (snow) Use after free issue on Hotplug https://gitlab.freedesktop.org/wayland/weston/-/issues/1028

14:29 <wlb> weston Issue #1027 closed \o/ (Use after free issue on Hotplug https://gitlab.freedesktop.org/wayland/weston/-/issues/1027)

15:21 <swick[m]> there actually is a "default" colorimetry infoframe now which specifies that the monitor shall interpret the signal on the cable as colorimetry as specified by the EDID/DisplayID

15:22 <swick[m]> but so far I've not seen support for that in any display...

15:52 <emersion> swick[m]: hm, but isn't that the default behavior?

15:52 <emersion> without the infoframe, the signal gets interpreted according to the thing specified in EDID?

18:12 <swick[m]> you'd think so but in practice it really wasn't the case so they introduced this just to drive home the point about the expected behavior of monitors