ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
feaneron has joined #wayland
kasper93 has quit []
kasper93 has joined #wayland
karolherbst has joined #wayland
Hypfer has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
Brainium has quit []
Hypfer has joined #wayland
LoneStarr has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
karenw has quit [Ping timeout: 480 seconds]
kts has joined #wayland
Hypfer has quit [Ping timeout: 480 seconds]
Hypfer has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
kts has quit [Quit: Konversation terminated!]
LoneStarr has quit [Read error: No route to host]
Sid127 has joined #wayland
kts has joined #wayland
narodnik has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
mripard has joined #wayland
sima has joined #wayland
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
leon-anavi has joined #wayland
rasterman has joined #wayland
tzimmermann has joined #wayland
mvlad has joined #wayland
garnacho has joined #wayland
glennk has joined #wayland
Calandracas has quit [Ping timeout: 480 seconds]
Calandracas has joined #wayland
<wlb>
weston Merge request !1795 closed (drm-debug: enable drm-debug if launch weston has debug option)
dcz has quit [Read error: Connection reset by peer]
dcz has joined #wayland
dcz has quit [Read error: Connection reset by peer]
<pq>
Is it the current practice in wayland-protocols to bump interface versions on *all* interfaces affected by the global rather than just the ancestry of the interface modified?
<JEEB>
contains references to 100 nits in 2080-1, and probably in the other ones as well
<JEEB>
-3 being reference viewing environment for HDTV images
<JEEB>
other SMPTE docs probably also refer to that value as well
<JEEB>
BT.1886 for good measure makes it a variable since in real life people have their displays set differently, and thus the graphics white point is different
<JEEB>
but the BT.709 marked content (or whatever that ends up EOTF'd as BT.1886) can be assumed as 100 nits mastered
<JEEB>
then on display you take into account your display graphics white brightness if you happen to know it
<pq>
excellent
<pq>
whoa, what? those SMPTE docs are freely available?!?!?!!
<JEEB>
yea, last year the unthinkable happened
<pq>
I should not be this happy.
<JEEB>
the new SMPTE lead caught up to the world
<pq>
omg
<JEEB>
and /doc/ is just a plain page listing everything that's free
<JEEB>
but yea, this means that you get all of 2084, 2086 as well as the dynamic HDR metadata from 2094 (which contains the actual specs for D's and Samsung's and Philips' formats)
<JEEB>
and I think technicolor
<JEEB>
because of course everyone made their own thing
<JEEB>
and SMPTE is happy to take money to publish people's corporate outputs
<swick[m]>
if we're starting to ramp up for a version 2 we might want to think about adding something to let clients communicate that they do want some HDR "headroom" and let compositors communciate that they could create headroom
<swick[m]>
something that android already does and that is required for the thing that zamundaaa has been showing off as well
<pq>
ok
<pq>
anyone writing that up?
<swick[m]>
but I guess that would require zamundaaa to wire things up and show that it's feasable
<swick[m]>
I should...
fmuellner has quit [Ping timeout: 480 seconds]
<pq>
doesn't matter if it misses bump 2, there will be bump 3 I'm sure.
<swick[m]>
right, that one should be purely additive as well
<pq>
ah, BT.1886 defaulted to 100 cd/m² already >_<
<pq>
just the pita left
<kennylevinsen>
mmmm. pita
<zamundaaa[m]>
<swick[m]> "if we're starting to ramp up for..." <- What new API would you add for that?
<zamundaaa[m]>
The HDR metadata we have already works well for it imo
<swick[m]>
well, it has the same problem as choosing a refresh rate with VRR
<swick[m]>
if the app renders for the preferred image description, the compositor doesn't know what it actually would like to render for
<swick[m]>
for video I think you're right
<zamundaaa[m]>
That works already, the preferred image description has the potential headroom as max_cll
<pq>
That surprises me.
<zamundaaa[m]>
Might get some tone mapping until the display is adjusted, but I think it's nothing to worry about too much
<swick[m]>
yeah, no, that doesn't sound right
<swick[m]>
max_cll should guide tone mapping for the currently available headroom
<swick[m]>
not for some potential thing
<zamundaaa[m]>
It's the same as with any LCD
<zamundaaa[m]>
Many of them slowly adjust the backlight to adjust to the content
<zamundaaa[m]>
So you don't get the headroom immediately at all times either
<pq>
EDID provides "desired maxCLL", so I would have expected the prferred image description maxCLL to mean the same.
<pq>
to *mean* the same, not *be* the same
<pq>
that is, compositor preferring the client does not exceed it
<pq>
which makes it identical to target color volume
<pq>
we could have a surface event and request outside of image descriptions for "compositor could go this high" and "client would like to go this high". Maybe there is no need for both.
feaneron has quit [Ping timeout: 480 seconds]
<pq>
one might be enough, perhaps the request is better
<swick[m]>
the request on the surface would solve the issue on its own
<swick[m]>
but, it's helpful to keep in mind that sometimes a decision has to be made beforehand
<pq>
since cd/m² numbers depend on the image description numbers, it should probably be a multiplier
<swick[m]>
firefox for example currently queries all output image descriptions for the available headroom to decide if they are going to download/stream an hdr video
<swick[m]>
having something outside of the surface telling clients, the system could provide up to X headroom somewhere on the outputs, seems useful
<pq>
right
andyrtr_ has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
<zamundaaa[m]>
There is a problem to be solved with that, but I think giving clients a headroom number won't really do it
<zamundaaa[m]>
If I have the laptop at 100% brightness, there is no headroom I can make available to apps
<zamundaaa[m]>
I would still like browsers to load the HDR version of videos though, for when I turn the brightness down
<pq>
I wonder if that should not be solved in the browser with a "always load HDR material" setting?
<pq>
How's that different from reporting the preferred image description with HDR headroom even when you cannot display any?
kts has joined #wayland
<swick[m]>
turning down the "brightness" to make more headroom available is a completely valid strategy, so I would make the compositor report that it can create headroom, even if it might not be possible at the very moment
<swick[m]>
we already have a mechanism which tells you about the available headroom right now which is the preferred image description
nerdopolis has joined #wayland
<zamundaaa[m]>
If we make it clearly just about less dynamic clients, which should use the image description, then it would be fine I guess
<pq>
What do you mean?
<zamundaaa[m]>
The image description is used by for example games to render exactly for the display
<pq>
You mean the preferred image description?
<zamundaaa[m]>
Yeah
<zamundaaa[m]>
If the user has the brightness setting at 100% and I still reported HDR headroom in the image description, then the game would render for that HDR headroom
<zamundaaa[m]>
And then the compositor would tonemap it down again
<pq>
why are games different from videos in a browser?
<zamundaaa[m]>
Games render for the screen at hand
<pq>
in what range you would want them to use
mahkoh has joined #wayland
<zamundaaa[m]>
Videos are mastered for a different display
<zamundaaa[m]>
pq: games should render exactly for the preferred image description, so I want it to match as closely as possible to what I can actually display. The best case is that the compositor just blits the buffer to the screen
<pq>
ok, and for videos you don't? you always want the max HDR version?
<swick[m]>
well, that's the question
<swick[m]>
do you need to stream in the HDR version or is the SDR version sufficient?
<zamundaaa[m]>
I don't want the version the browser loads to depend on the brightness slider
<swick[m]>
or the display it is currently on
<zamundaaa[m]>
yeah
<pq>
sounds like the browser should just *not* listen to the compositor
<zamundaaa[m]>
I've also seen videos where my tone mapping was a lot better than the SDR version of the same video on YouTube, so there's also that :)
<zamundaaa[m]>
But that's not going to be a universal thing (I hope)
<swick[m]>
pq: and do what exactly?
<mahkoh>
mpv was patched some time ago to always perform produce output in the preferred image description. hyprland developers complained about this because they want applications to always render in the "source" image description so that hyprland can automatically switch outputs to HDR on demand.
<pq>
swick[m], always load the max HDR version as zamundaaa[m] wants.
<zamundaaa[m]>
I'd imagine a properly mastered movie will have much better tone mapping than what my real-time shader can do
<swick[m]>
pq: downloading the HDR version when the SDR version is sufficient will not be appreciated by users on metered connections
<pq>
zamundaaa[m], only if you actually ask the version closest to your current display.
<pq>
swick[m], sure, so a browser setting.
<zamundaaa[m]>
I don't think a setting in every internet-related app is good UX
<swick[m]>
dunno, that seems to manual
<swick[m]>
yeah
<pq>
Why should the compositor be able to convey this complicated choice, when it depends on the type of a client what the user wants?
<pq>
What you ask is conflicting.
<swick[m]>
at the end of the day, the compositor knows that on a certain monitor/config, it might be possible to create HDR headroom, or not
<zamundaaa[m]>
The client can of course still provide a setting, but the ootb experience I want is that the user gets HDR content if we have a good chance to display it better than the SDR version. And if we can't, they should still get the SDR version from the provider
<swick[m]>
and we can make that information available, so why shouldn't we
<pq>
oh, there is an "if" there
<zamundaaa[m]>
IIRC Windows has a centralized setting for this too
Moprius has joined #wayland
<pq>
I'm trying to think how to formulate that...
<pq>
If one can adapt to the preferred image description, always do that. But somehow with videos, even if choosing the SDR stream would be a perfect fit, the client should choose a HDR stream, if... the compositor indicates it might be able to increase HDR headroom?
<swick[m]>
yes
<pq>
but games must not do so, because...?
<zamundaaa[m]>
Games should be able to dynamically enable and disable HDR
<zamundaaa[m]>
Browsers generally have to choose before starting the video stream
<pq>
I can always reload the web page?
<swick[m]>
yes, but why should you have to reload the web page after changing the brightness slider?
<pq>
because browsers didn't implement anything better
<swick[m]>
or moving it to another screen
<swick[m]>
yes, but that's what we want to change :P
<pq>
no, you're basing a proposition on the assumption that browsers will not implement anything better, so you work around it by making them choose the HDR video even if it was unnecessary
<swick[m]>
and we should have a mechanism (no matter if it's max_cll or something else) to indicate that a surface wants a certain amount of headroom, otherwise it is all a bit pointless
<pq>
yes, I agree on the request
<swick[m]>
okay, so your argument is that browsers should try to figure out a way to dynamically adjust to the preferred image description?
<pq>
yes
<pq>
that would be ideal
<swick[m]>
I agree with that, but I'm also unsure how realistic that is
<pq>
they may not be able to match the preferred image description, but at least they should be able to switch between available streams
<swick[m]>
so maybe we start with the surface request and punt the other thing for now?
<pq>
yup, that would be easy.
darkcreepy has joined #wayland
Moprius has quit []
<darkcreepy>
Hi, quick questions about the tablet protocol, what's the reasoning behind allowing non-zero pressure when tools are not in logical contact? Also, I assume that because clients are only aware of logical contact, it does not matter if the compositor choses to have non-zero pressure when not in physical contact, right?
<kennylevinsen>
the way it is defined is to clarify that contact is not "pressure > 0", but that logical contact might only happen past some threshold (e.g., "pressure > 100")
<darkcreepy>
I guess that answers my question, thanks
feaneron has joined #wayland
fmuellner has joined #wayland
fmuellner_ has quit [Ping timeout: 480 seconds]
kts has quit [Remote host closed the connection]
mahkoh has quit [Quit: WeeChat 4.6.3]
__0x1eaf has quit [Quit: Lost terminal]
Brainium has joined #wayland
<pq>
swick[m], I think I would be ready to land the color-management minor v2 changes on Monday, but I guess we want to wait for the EDR request MR?