ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<emersion>
the effect is even more noticeable without the multiplier
ezzieyguywuf has joined #wayland
<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
<zamundaaa[m]>
emersion: technically speaking, sure, but the difference is the concept of how it's supposed to work
<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
<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
<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)
pavlushka has joined #wayland
<emersion>
let's say my SDR content is 80 cd/m2, and my HDR display has mastering display primaries set to 10k cd/m2
<emersion>
i should just set the multiplier to 10k/80?
<emersion>
(min_lum is zero in both cases)
<zamundaaa[m]>
Mastering display luminance is irrelevant here
<emersion>
okay, then assuming the SDR content is in [0; 1], multiply by 80 cd/m2?
<emersion>
or is the multiplication expected to look bad?
<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
<emersion>
that sounds like multiplying by 10k/80
<JEEB>
the PQ trc is not linear I think?
<zamundaaa[m]>
emersion: it would be multiplying by 80/10k
<JEEB>
or wait, at this point are you in linear space
<JEEB>
sorry
fmuellner has joined #wayland
<emersion>
er, yeah, got it the other way around :P
<JEEB>
and then when you add the HDR graphics white argument you can default it to 203 nits
<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
<emersion>
so, *2.03?
<JEEB>
but yea, first validate without the HDR graphics white adjustment
<zamundaaa[m]>
KWin only has the one with [0; 1] input range because it allows custom luminance levels for PQ internally
<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
<JEEB>
*VALUE_FOR_HDR_GRAPHICS_WHITE
<emersion>
so… essentially i should fix the multiplier and it should Just Work?
Brainium has joined #wayland
pavlushka has quit [Ping timeout: 480 seconds]
<bitblt>
hello there
<bitblt>
these last days I was trying to find out the cause of a slight (but really annoying) blurrying problem in native wayland applications
<bitblt>
I think I've found a problem in the fractional-scale-v1 protocol
<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
<bitblt>
when resizing or moving pixel by pixel the toplevel window, for some positions and sizes the content becomes blurry
<bitblt>
I can reproduce this issue with many other client applications like foot and alacritty too
<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:
<bitblt>
this is a problem, given that the wayland clients do not (and cannot) know their position
<bitblt>
so when calculating the (scaled) buffer size, for some window positions/sizes there might be a mismatch of about 1 pixels or more
<bitblt>
this causes blurriness, because the toplevel window is forced to scale up or down the client buffer that will possibly have different size
<bitblt>
this happens because the client calculates the buffer size just by using the scaling factor, which leads to discrepancies with the window size
<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
<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
<kchibisov>
bitblt: it's an issue in your compositor.
<kchibisov>
nothing is position dependent.
<bitblt>
kchibisov: so the above code in wlroots is incorrect?
<kchibisov>
because sway wasn't using wlr_scene back then.
<kchibisov>
now it uses and has this bug again.
<bitblt>
I suppose this was lack of understanding or it was unspecified back then?
<bitblt>
ah I see
<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})
kts has joined #wayland
<bitblt>
kchibisov: can specify the link to this pr that specifies the exact formula please?
rasterman has quit [Remote host closed the connection]
<emersion>
daniels: sorry for the brainfart, should've read the commit message more carefully
<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 :)
<daniels>
jadahl: wayland-devel@ are asking for your gracious and wise intervention (release w-p pls)