00:10 emersion: the effect is even more noticeable without the multiplier
00:30 ezzieyguywuf: I noticed that my package manager installs some (all?) of the wayland xml files for me to use in wayland-scanner. Is there a cross-distro way to find these xml files? I'd like to set up a build script to generate the c bindings in my project
00:30 emersion: https://irc.emersion.fr/uploads/emersion/3b6ac1a2-IMG_20250129_012925_794.jpg
00:31 emersion: aka "the lipstick shader"
00:31 zamundaaa[m]: hah
00:31 zamundaaa[m]: Judging by the image, something's definitely wrong with the transfer function
00:32 emersion: I compared it with kwin on shadertoy (half screen wlr, other kwin) and it's exactly the same
00:33 emersion: also forcing sRGB in the shader and the issue is still here
00:34 zamundaaa[m]: wdym with "kwin on shadertoy"?
00:36 emersion: grabbed linearToPq() from kwin
00:36 emersion: from colormanagement.glsl
00:37 emersion: then used to render a gradient, half of it with wlroots' function, other with kwin, and both sides looked the same
00:37 emersion: (the functions are very similar either way)
00:38 zamundaaa[m]: okay
00:38 emersion: so i've ruled out the matrix and the TF, not sure what else could go wrong...
01:02 zamundaaa[m]: emersion: I took a look at your shader, and the TF does not look right
01:03 zamundaaa[m]: You're applying the sRGB TF, and then the modified PQ inverse TF from KWin - which has as input [0; 1]
01:03 zamundaaa[m]: PQ is [0; 10000] nits though, so that's mapping sRGB white to 10k nits
01:37 wlb: weston Issue #991 opened by n3rdopolis (n3rdopolis) Odd linker error in Debian Testing https://gitlab.freedesktop.org/wayland/weston/-/issues/991
06:32 emersion: zamundaaa[m]: isn't that just a multiplier?
06:35 emersion: decode sRGB to linear, blend, convert sRGB primaries to BT2020, (multiply), encode to PQ?
06:53 emersion: i should've linked the shader: https://gitlab.freedesktop.org/emersion/wlroots/-/blob/renderer-pq/render/vulkan/shaders/output.frag?ref_type=heads#L64
10:30 emersion: btw, what is the srgb/gamma22 thing again?
10:30 emersion: should i decode surfaces with srgb, then encode with gamma22?
10:30 emersion: hm, or rather the opposite: decode with gamma22, encode with srgb?
10:31 emersion: or just always use gamma22?
10:35 JEEB: that's the fun bit with mismatching OETF|EOTF
10:47 JEEB: but if you are making content to be displayed as G22 (which the sRGB reference display is), then encoding that as G22 would make sense
10:47 JEEB: windows decodes it as sRGB split trc
10:47 JEEB: macOS lets you pick your poison for unmarked SDR surfaces :D
10:48 JEEB: https://raw.githubusercontent.com/dylanraga/win11hdr-srgb-to-gamma2.2-icm/refs/heads/main/macos_crf.png
10:51 zamundaaa[m]: emersion: technically speaking, sure, but the difference is the concept of how it's supposed to work
10:51 zamundaaa[m]: Going from the content (SDR or HDR), you calculate some brightness of the content, and then send that to the screen, encoded as PQ
10:51 zamundaaa[m]: A multiplier is just messing around and hoping something works out, but with cd/m^2 you have some actual numbers to work with
10:52 JEEB: (this is generally only relevant for specified HDR output since most systems with the default SDR output just output unmarked SDR surfaces as-is)
10:52 emersion: let's say my SDR content is 80 cd/m2, and my HDR display has mastering display primaries set to 10k cd/m2
10:52 emersion: i should just set the multiplier to 10k/80?
10:53 emersion: (min_lum is zero in both cases)
10:53 zamundaaa[m]: Mastering display luminance is irrelevant here
10:54 emersion: okay, then assuming the SDR content is in [0; 1], multiply by 80 cd/m2?
10:55 emersion: or is the multiplication expected to look bad?
10:55 JEEB: if you are not doing HDR graphics white adjustment (which for testing and verification is OK), then you just do configuration and map that [0; 1] of [0, 80] nits to [0; 1] of [0; 10k] nits. then when you validate that, you add an argument which is the HDR graphics white
10:56 emersion: that sounds like multiplying by 10k/80
10:56 JEEB: the PQ trc is not linear I think?
10:56 zamundaaa[m]: emersion: it would be multiplying by 80/10k
10:57 JEEB: or wait, at this point are you in linear space
10:57 JEEB: sorry
10:57 emersion: er, yeah, got it the other way around :P
10:57 JEEB: and then when you add the HDR graphics white argument you can default it to 203 nits
10:58 zamundaaa[m]: But look at the PQ inverse EOTF on Wikipedia. To get the idea of how this works, it's important to use the real one
10:58 emersion: so, *2.03?
10:58 JEEB: but yea, first validate without the HDR graphics white adjustment
10:59 zamundaaa[m]: KWin only has the one with [0; 1] input range because it allows custom luminance levels for PQ internally
10:59 JEEB: I recall getting bad results with plain *2.03 but I might have been poking at the wrong values in mpv back then ^^; also it's a question of whether you consider it nits to nits (sRGB is supposed to be 80 nits, not 100 nits) or just "this is graphics white, whatever the nits - and it should get mapped to VALUE_FOR_203_NITS
11:00 JEEB: *VALUE_FOR_HDR_GRAPHICS_WHITE
11:08 emersion: so… essentially i should fix the multiplier and it should Just Work?
12:01 bitblt: hello there
12:01 bitblt: these last days I was trying to find out the cause of a slight (but really annoying) blurrying problem in native wayland applications
12:01 bitblt: I think I've found a problem in the fractional-scale-v1 protocol
12:01 bitblt: in order to be sure, I wrote a minimal poc wayland client that uses fractional scaling and renders some text with a bitmap font
12:01 bitblt: when resizing or moving pixel by pixel the toplevel window, for some positions and sizes the content becomes blurry
12:02 bitblt: I can reproduce this issue with many other client applications like foot and alacritty too
12:02 bitblt: I tracked this down, and it seems that some compositors (like the wlroot based ones) use position based scaling for toplevel window width and height:
12:02 bitblt: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/types/scene/wlr_scene.c#L349
12:02 bitblt: this is a problem, given that the wayland clients do not (and cannot) know their position
12:02 bitblt: so when calculating the (scaled) buffer size, for some window positions/sizes there might be a mismatch of about 1 pixels or more
12:02 bitblt: this causes blurriness, because the toplevel window is forced to scale up or down the client buffer that will possibly have different size
12:02 bitblt: this happens because the client calculates the buffer size just by using the scaling factor, which leads to discrepancies with the window size
12:02 bitblt: I suppose this can be solved with 2 ways: either the protocol will specify the window scaling algorithm to be position agnostic and clients must implement the exact same algorithm to scale their buffers
12:02 bitblt: or the protocol must be modified to return a suggested content buffer size alongside the scale, and this will be calculated (scaled) by the compositor in order for both the window and the content buffer to be the same size
12:06 kchibisov: bitblt: it's an issue in your compositor.
12:06 kchibisov: nothing is position dependent.
12:06 bitblt: kchibisov: so the above code in wlroots is incorrect?
12:06 vyivel: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3793
12:06 kchibisov: yes, it's a bug.
12:07 bitblt: emersion: have you thought about this?
12:07 bitblt: can I help somehow fix this?
12:08 bitblt: kchibisov: what would be the correct way to calculate the scaled width and height in this case according to the spec then?
12:08 kchibisov: protocol says how you do so.
12:08 kchibisov: there's also a PR to specify the exact formula.
12:10 bitblt: a pr in wayland protocols or in wlroots?
12:10 kchibisov: protocols.
12:11 bitblt: I saw that you opened an issue in wlroots here about this: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3705 but it got rejected by Nefsen402
12:11 kchibisov: because sway wasn't using wlr_scene back then.
12:11 kchibisov: now it uses and has this bug again.
12:11 bitblt: I suppose this was lack of understanding or it was unspecified back then?
12:11 bitblt: ah I see
12:16 JEEB: emersion: had a walk and basically I think if you are dealing with linear content it ends up in either case being LINEAR_SDR_VALUE * (HDR_GRAPHICS_WHITE_NITS / HDR_MAX_VALUE_NITS) when your output linear is in specific HDR nits like with PQ. since even if you first do for example ({80,100} / 10k) and then multiply by (HDR_GRAPHICS_WHITE_NITS / {80,100})
12:19 bitblt: kchibisov: can specify the link to this pr that specifies the exact formula please?
12:26 llyyr: bitblt: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/309
13:29 wlb: wayland Merge request !452 opened by Daniel Stone (daniels) build: Add -lm to pkg-config dependencies https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/452
14:40 emersion: daniels: sorry for the brainfart, should've read the commit message more carefully
15:03 daniels: emersion: please let's not set a precedent of apologising every time we're wrong - my fingers would fall off from the amount of typing I'd need to do :)
15:13 daniels: jadahl: wayland-devel@ are asking for your gracious and wise intervention (release w-p pls)
15:15 wlb: wayland-protocols/main: Xaver Hugl * stable/linux-dmabuf: clarify when the plane_set protocol error is sent https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/18a0117b9472 stable/linux-dmabuf/linux-dmabuf-v1.xml
15:15 wlb: wayland-protocols Merge request !376 merged \o/ (stable/linux-dmabuf: clarify when the plane_set protocol error is sent https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/376)