ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Moprius has quit []
lebster has joined #wayland
nerdopolis_ has joined #wayland
nerdopolis is now known as Guest21888
nerdopolis_ is now known as nerdopolis
Guest21888 has quit [Read error: Connection reset by peer]
<linkmauve>
orowith2os[m], Weston has a bunch of simple clients, but we removed support for wl_shell eons ago.
<linkmauve>
As for damage, wl_surface::damage is deprecated and mostly means full damage nowadays, since you can’t really know its correct coordinates. You want to always use wl_surface::damage_buffer.
<linkmauve>
So if you receive both kinds of damage, just consider that everything has changed.
<linkmauve>
I wouldn’t recommend going for fullscreen-shell, xdg-shell is what you want for standard clients really.
<linkmauve>
It isn’t that complex, and as danieldg said you can just stub all the requests you don’t implement yet.
<linkmauve>
There is surprisingly little you need before you can display a client.
kelnos has quit [Remote host closed the connection]
kelnos has joined #wayland
kasper93 has joined #wayland
kasper93 has quit []
kasper93 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
sima has joined #wayland
tzafrir is now known as Guest21901
Guest21901 is now known as tzafrir
<LoneStarr>
PSA: Never buy a used HP 15 laptop if you intend to use the touchpad! My battery for the external mouse failed, and the default hardware is so buggy. Its not a software issue.
dcz has joined #wayland
karenw has quit [Ping timeout: 480 seconds]
moxie has quit [Quit: WeeChat 4.6.3]
moxie has joined #wayland
shoragan has quit [Ping timeout: 480 seconds]
LoneStarr has quit [Ping timeout: 480 seconds]
tzafrir is now known as Guest21904
kts has joined #wayland
moxie has quit [Quit: WeeChat 4.6.3]
moxie has joined #wayland
tzimmermann has joined #wayland
kts has quit [Quit: Konversation terminated!]
dcz has quit [Ping timeout: 480 seconds]
__0x1eaf has joined #wayland
Drakulix has quit [Ping timeout: 480 seconds]
leon-anavi has joined #wayland
Drakulix has joined #wayland
MrCooper has joined #wayland
kts has joined #wayland
shoragan has joined #wayland
coldfeet has joined #wayland
rasterman has joined #wayland
Guest21904 is now known as tzafrir
<pq>
I never understood why clients should go out of their way to use wl_surface.damage_buffer if wl_surface.damage fits their internal workings better.
kts has quit [Ping timeout: 480 seconds]
tzafrir is now known as Guest21913
coldfeet has quit [Ping timeout: 480 seconds]
coldfeet has joined #wayland
garnacho has joined #wayland
coldfeet has quit [Ping timeout: 480 seconds]
<llyyr>
pq: where do the requirements min_L < maxCLL <= max_L and min_L < maxFALL <= max_L come from in the protocol? I see the commit message adding those requirements mentions ANSI/CTA-861-I Annex P, but that only justifies maxFALL <= maxCLL
<llyyr>
quite a few real world HDR files don't fulfil these requirements
<pq>
llyyr, they come from common sense.
<pq>
e.g. max content light level must be greater than min luminance, otherwise you can only have a completely black image.
<pq>
and: neither content max nor frame-average luminance can exceed max luminance - if they did, max luminance would be incorrect.
<JEEB>
I think the thing that was discussed was max content being able to be higher than max mastering display?
<llyyr>
I don't know enough to say if that's right or wrong, but VK_EXT_hdr_metadata doesn't have such requirements and the impedance mismatch between color-management-v1 and the vulkan extension is quite painful for clients that aim to support multiple platforms (i.e. mpv)
<JEEB>
which is a normal state, where the mastering display just says that the tone / gamut mapping could take into account that the mastering person did not see beyond the display's capabilities
<pq>
we're talking about max_luminance, not mastering max luminance, right?
<JEEB>
apparently things fail when content max luminance is higher than mastering max luminance?
* JEEB
just read that and is quite unsure of why the max content light level should be at all related to mastering (display) light levels? :D one describes the content, the other display.
<pq>
I see two options: a) keep it as is, and make game developers fix their programs and quirk those in drirc that don't; or b) we silently accept obviously nonsense values, do whatever with them, and let game developers be none the wiser.
dcz has joined #wayland
<llyyr>
well mpv hits these with real HDR files, this isn't about a game
<pq>
JEEB, my argument is that pixels you cannot see correctly by definition in mastering are garbage.
<pq>
llyyr, that's much easier, mpv can second-guess the values automatically.
<JEEB>
it most often means that they are just cut at that point with display
<JEEB>
so the mastering person still has the histogram, but basically that's considered as white for him
<pq>
JEEB, so you should cut the signal as well.
<JEEB>
the mastering display thing is a tone / gamut mapping hint basically
<pq>
and we're not even talking about validating the signal, we're only asking for the metadata to be consistent
<JEEB>
given that displays get fed wider signals all the time, I don't really consider this stuff invalid?
<kasper93>
consistent with what?
<pq>
JEEB, yes, that's what it's used for, but it's not defined as "arbitrary values that can be used for tone mapping". AFAIK, it's defined as the mastering display capapbility.
<pq>
kasper93, itself.
<JEEB>
so basically what you're saying is that I should not signal the actual content light levels if I happen to master 1000 nits content on my display
<pq>
JEEB, I'm saying saying your content light levels cannot exceed what your display can show.
<kasper93>
pq: I don't think Wayland should impose restrictions on industry wide HDR metadata values. I'm not saying I don't agree with your interpretation, but it's only yours. This restriction is not defined anywhere. And I have multiple real HDR movies, both new and old, that have CLL > Mastering Display Luminance.
<kasper93>
now, what should I do? Clamp real files metadata?
<JEEB>
and it's quite normal to have highlights that go beyond the mastering display, since mastering displays often are limited to around 1000 nits, while you have small highlights like with mad max fury road
<JEEB>
and in that case, is it really correct to not have correct content information on the metadata?
<pq>
That is in the mastering sense. You can of course prepare content in a non-mastering environment where the display is tone mapping already, but then you can and should choose your limits and stick to them.
<pq>
Broken HDR material are plentiful. I'd rather they are fixed up in Wayland clients rather than compositors.
<JEEB>
like, I kinda understand the logic of "it's idiotic to only master based on a graph", but that's what's being done, where f.ex. until 1000 nits or so the display can show you stuff, and then the rest is based on a signal graph
<JEEB>
but in that case both metadata is not dumb by themselves and they can be utilized correctly to tone and gamut map better into limited displays.
<pq>
I don't believe that, because the bigger the gap to be tone-mapped away, the more uncertain is the quality of the result. However, there is one case:
<pq>
Creating works on a mastering display that is *less* capable than the expected viewer displays.
<JEEB>
yea
<pq>
That's painting blind.
<JEEB>
yes, painting stuff based on visualizations
vincejv has quit []
<JEEB>
and for better or worse, we have actual content that is created like that, where the mastering display metadata makes sense and where the content light levels etc make sense
<pq>
It's just blind. There is no workable theory to predict image appearance from stimuli.
fmuellner has joined #wayland
<pq>
You said the mastering metadata is used to guide tone mapping. How can it guide tone mapping into something bigger than the mastering display? Do you also believe in automated inverse tone-mapping (taking SDR content and algorithmically adding HDR details)?
mahkoh has joined #wayland
<JEEB>
generally it means that you can (if required) ignore content beyond those limits, since it can be expected that clipping occurred there
<mahkoh>
linkmauve: wl_surface.damage is not deprecated and does not mean full damage. it is likely to be more efficient for the compositor to work with wl_surface.damage than with wl_surface.damage_buffer since there are many transformations that can be performed by the client on a buffer. damage_buffer is only more convenient for some clients.
<JEEB>
and while content that is there can be mapped into smaller spaces, you can't really generate what is not there from something. :)
<JEEB>
(while I've seen fun attempts at that, I don't really consider that more than a curiosity and probably doesn't have much to do with original intent)
<pq>
Clients could just drop all HDR metadata on the floor by default, too. That's what displays tend to do.
<linkmauve>
mahkoh, oh? I’m probably confusing with Mesa then, where it can’t know the surface scale and thus can’t use wl_surface::damage at all, and thus has to either damage the whole surface or use wl_surface::buffer_damage.
<mahkoh>
Yes, I believe that is the usecase damage_buffer is for.
fmuellner has quit [Ping timeout: 480 seconds]
<pq>
As long as the HDR metadata is in the protocol, I would very much want to enforce that it is both sensible and fully utilized in compositors. My fear is that if we allow slack there, it will remain useless.
<JEEB>
anyways, if I offended you I'm sorry. It's just that mastering display being smaller than content is such a normal occurance in video. and since generally both seem otherwise valid, there is not much to complain about (there's a whole separate thing where the metadata is clearly invalid, which is not something that's being discussed)
<pq>
JEEB, no worries, the requirement *are* something I cooked up.
<llyyr>
is it not possible to specify the same requirements for the vulkan extension, or for mesa to try to clamp values itself (with a drirc config maybe)?
<JEEB>
and yes, it's effectively either being done blind, or then previewed on a separate display which is then not marked on the metadata since it goes even further from general end user display things
<pq>
llyyr, I'd be happy with those, but I don't really work there.
<JEEB>
since my TV can do 1500 nits on a small area and 800 nits on full display, for example. so something like mastering for 1000 nits with clipping is something that I could see, since you're not supposed to have more than one mastering display info block in the content
<JEEB>
even in the case where the display could show higher values and thus show that
<JEEB>
but after all these years I've basically learned to interpret mastering display metadata as the clipping limit if things need to get remapped for display
<kasper93>
pq: For context, here are few movies released in recent years and thieir metadata. https://0x0.st/s/p5IWx3jDLOExrnDarmn0VA/8kKZ.txt We (mpv) can clamp this metadata to Wayland expectation, but I'm more than certain we will get users complaining that "HDR pass-through" mode doesn't work correctly and doesn't send metadata they expect to be sent.
<pq>
I would claim the "normal occurrence" to be just a common mistake. But if you can show the disconnect to be useful rather than just skip metadata validation in clients, that would be really good.
<pq>
JEEB, yeah, the clipping limit thing is what I run with.
<JEEB>
it is useful as a second "content range to care about". if your display is more capable than the mastering display, you can utilize the content data, while if you are less capable you know that you do not have to care about the wider range as much
<pq>
kasper93, FWIW, I expect a lot of complaints from HDR metadata pass-through anyway, because the display behavior is impossible to follow in a compositor simply because it's totally arbitrary and unknown.
<pq>
JEEB, that sounds a little bit like the "roll-off" for highglights one cannot display as-is.
<kasper93>
that's beyond our control. But if we prove that we pass HDR metadata as-is, than user can understand why it doesn't work
<kasper93>
if we pass some clamped metadata, user can infer that's it's our fault
<pq>
kasper93, that's a good point.
<pq>
My dream is that users will determine the compositor's tone mapping superior to their own display's.
<pq>
I believe that is the goal we should aim for.
<kasper93>
I think you can say it's "common mistake" or just a byproduct of mastering pipeline. Mastering display metadata is almost always 1000 or 4000 nits, that's just a preset. While maxCLL is calculated from final movie, if you boost something too much it will go over mastering display, It can be one frame or something.
<pq>
If maxCLL and maxFALL can break through MDCV, then should compositors use a modified MDCV where max L is max(maxCLL, max mastering L)?
<kasper93>
I've seen many cases where maxCLL is like 996 nits or 1010, which both are resonable, just not within our expectation
<pq>
hmm, no, not max(). I maxCLL is set, just take it as the max luminance in MDCV?
<kasper93>
I was asking the same question myself
<pq>
*if
vincejv has joined #wayland
<JEEB>
if we take the case where MDCV is smaller than CLL, if you think about the case of f.ex. MDCV having 1000 nits and CLL being 1500 nits or so. if your display can show everything in MDCV, then it means that everything within that should be shown as-is, and higher things can be mapped according to CLL. then in case where display is not capable of MDCV, you can use MDCV as the important light level range
<zamundaaa[m]>
pq: KWin does that already
<zamundaaa[m]>
And it seems to work well in practice
<JEEB>
and if MDCV is wider than CLL, then you just care about CLL
<pq>
JEEB, but using one formula for one luminance range and another formula for another range may break the picture.
<kasper93>
ignoring dynamic metadata, if set tone map curve mastering display->target display, it will make it look like on the mastering display, in theory. While if CLL >>> MDCV we would compress dynamic range way more and possibly not "clip" highlights, but it wouldn't be accurate how it was looking on mastering display
<kasper93>
*(While if we use CLL and CLL >>> MDCV)
<pq>
JEEB, shape perception from shading is pretty sensitive to changing the tone curves.
<JEEB>
kasper93: yea, which is why I limited CLL usage to when your display is more capable than MDCV
<JEEB>
and in theory it's OK to always limit the region of interest to MDCV if it's smaller
<pq>
JEEB, what do you do with CLL if the display is more capable than MDCV?
Sid127 has joined #wayland
<JEEB>
if CLL > MDCV then it is the base value set for mapping the things wider than the display's capabilities
<pq>
and that will affect the reproduction of pixels inside the MDCV as well?
<JEEB>
I would expect that the MDCV value range would be left intact in that case, but maybe I'm thinking this in too simple terms
<JEEB>
of course interpretation of the content may be different depending on the amount of content that is way wider (more bright) than MDCV
<pq>
if you leave it intact, then you have a "kink" in your curves, which risks breaking the picture in subtle ways (think shape from shading)
<pq>
assuming the picture was well-formed above the kink to begin with, which I think it cannot have been as it was never viewed correctly in mastering.
<pq>
GIGO
<pq>
JEEB, kasper93, zamundaaa[m], could you document somewhere (if there isn't already) how you use maxCLL, maxFALL and MDCV together?
<JEEB>
at least the fury road stuff that raised a curfuffle by having many bright sand dune etc scenes (and then one miniscule 9000 nit highlight that raised the max one to that point) seemed to be relatively sane content wise. granted when things get brighter the actual visible details start dropping off, which makes things look simpler
<pq>
Likewise as raised in the Display Next hackfest, we need to document that changing reference luminance levels requires a gamma adjustment.
<pq>
Looking at https://0x0.st/s/p5IWx3jDLOExrnDarmn0VA/8kKZ.txt I cannot help but think: "This movie is intended to be viewed on a peak 1000 cd/m² display. Some pixels shall have luminance of 1350 cd/m²."
<JEEB>
that's actually more or less how I interpret it as well. It's just that the latter bit I'd rather not get rid of metadata wise.
<pq>
"This 12V battery gives out 18 volts!" :-p
<kasper93>
pq: In mpv/libplacebo CLL/FALL is not used at all for tone mapping currently. It's only used to set HDR metadata in "pass-through" mode. MDCV is used for tone-mapping. (in a nutshell)
<pq>
kasper93, ok, good to know.
<pq>
I guess many displays that use metadata at all, ignore MDCV and use only maxCLL and/or maxFALL?
<kasper93>
We use other dynamic metadata for tonemapping (if available) which is like CLL but per frame. And there is dynamic peak luminance computation. So in practice we don't use MDVC as much for tonemapping, mostly because it's static and generally not suitable for all scenes.
<pq>
I think the pass-through argument is the best argument for removing the validation of maxCLL/maxFALL against MDCV.
<kasper93>
Hard to say about the displays, at least mine is using MDCV and ignoring CLL, at least from limited testing the other day.
<pq>
I bet there are displays doing all possible combinations and variations.
<JEEB>
yea, what displays do is hard to say without actual testing, as it's all closed and proprietary
<kasper93>
sure
<pq>
Anyone want to take action (put something in Gitlab) for relaxing the maxCLL/maxFALL validation and usage, lest we forget?
<kasper93>
also quietvoid (he knows HDR ;p) says the CLL is not reliable in general. And suggests to not use it for tone-mapping.
<pq>
haha
<pq>
yet we need it in the protocol because pass-through...
<JEEB>
lol
Sid127 has joined #wayland
<JEEB>
I understand that fully with regards to it being static and thus not representable of the whole shebang, but otherwise I've mostly seen the values be generally OK outside of clearly invalid stuff
<JEEB>
but I would not be surprised if there was invalid stuff
<pq>
How do you recognize invalid stuff?
feaneron has joined #wayland
<zamundaaa[m]>
<kasper93> "also quietvoid (he knows HDR ;p)..." <- Well, I'd say that none of the HDR metadata is proper reliable. The end result is usually good enough though
<JEEB>
that's stuff like the value range being incorrect (hello Sony HDR sample)
<zamundaaa[m]>
In KWin we just discard the most obviously wrong HDR metadata. Some games claim max_cll of a million nits for example
<JEEB>
wrong *1000 somewhere I guess?
Moprius has joined #wayland
<zamundaaa[m]>
Probably. IIRC it was a bunch of games that had the exact same nonsense in there, so it was probably some bug in the game engine
<pq>
How can we educate app developers to improve the quality of the metadata?
<JEEB>
but yea, for stuff where the value range is sane and not completely bonkers/incorrect, then it's mostly looking if anyone who's done more effort complains or otherwise facepalms at a piece of video content
<pq>
Protocol errors? crush to sRGB? Compositor complaint dialogs?
<zamundaaa[m]>
pq: native Wayland games should pretty much always have exactly the preferred HDR metadata and do their own tone mapping (as they do that anyways). In that way, games have it easy
<zamundaaa[m]>
For everything else... Most current HDR content is videos and some photos, outside of improving mastering applications there's probably nothing we can do
<pq>
What would be the incentive for anyone to check up on authoring apps?
Sid127 has joined #wayland
Brainium has joined #wayland
<pq>
I see HDR metadata pass-through as a problem, even a bigger problem than compositors diverging in their tone mapping.
<pq>
It feels like the X11 design of color management.
<pq>
Assuming the metadata was correct, it won't remain correct unless the compositor shovels the pixels through as-is. And that means ignoring e.g. brightness settings.
vincejv has quit [Remote host closed the connection]
<llyyr>
guess this is why most displays won't let you change brightness/contrast or any other settings in "HDR mode"
<pq>
No, that's purely a misunderstanding of BT.2100/PQ.
vincejv has joined #wayland
<pq>
The display uses the metadata and does not forward the picture along to someone else, so it is completely free to adjust it.
<pq>
or should I say, it strips the metadata from the picture anyway, while turning the electrons into light for humans.
<pq>
I meant the DE brightness settings.
<pq>
...which exists because of the misunderstanding.
dcz has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
<pq> "What would be the incentive..." <- The only way I can think of is to get all the desktop market share. Or get most of the other vendors to care and use the metadata too
<zamundaaa[m]>
Including mobile of course
<pq>
If garbage metadata works well enough, why look into it?
<zamundaaa[m]>
We should probably also take a look at dynamic metadata, which I think is more likely to be correct if it exists
<pq>
IOW, if metadata is off, what can we "degrade" to make it apparent that things could be better, but not make existing materials unusable?
<pq>
good thing the HDR10+ dynamic metadata was revised to be simpler
nerdopolis has joined #wayland
<pq>
Is the reason for dynamic metadata that the movie can be luminance-compressed scene-by-scene, making dark scenes brighter and bright scenes darker? Any other reasons? Are the algorithms to use the metadata standardised?
<zamundaaa[m]>
pq: I would personally adjust the tone mapper for that, yeah. I don't know if that's what it was created for though
<pq>
kasper93, about mpv's HDR metadata pass-through, where have users had that before Wayland? mpv on DRM KMS directly?
<zamundaaa[m]>
I would expect all the hardware decoders to output per-frame data like max luminance already, so I'm not sure what problem dynamic metadata in videos solves that the decoder feature wouldn't
<zamundaaa[m]>
On the Wayland side, we'd of course need the app to provide the dynamic metadata either way
zvarde1988303206779191685873 has joined #wayland
<JEEB>
pq: windows via d3d11 was the first one I think
<pq>
You wouldn't want to use per-frame statistics to directly drive tone-mapping, that would be flickery restless. I think it needs to be scene-by-scene.
<pq>
JEEB, oh, mpv runs on Windows, ok.
<JEEB>
I don't recall if the direct DRM PR got merged
<zamundaaa[m]>
It would certainly need to be adjusted slower than frame by frame, yeah
<zamundaaa[m]>
I guess per-scene can still do a better job than just smoothing the per-frame data though
<JEEB>
but the vulkan full screen API had that via libplacebo
<pq>
zamundaaa[m], but you'd want it to change abruptly on scene switch.
<JEEB>
don't recall whether macOS via moltenvk had it
<pq>
so you'd implement scene change detection...
<pq>
Another comment from Troy made me think of metadata pass-through yet again, and it seems it's for... replicating Windows behaviour? Should we really cater for that?
kasper93_ has joined #wayland
kasper93 is now known as Guest21924
kasper93_ is now known as kasper93
kts has joined #wayland
<kasper93>
pq: before wayland, it was VK_KHR_display with AMDVLK or gamescope. drm kms was also added last year of hdr.
<kasper93>
on windows d3d11 and vulkan api works
<pq>
ok, ouch.
<pq>
kasper93, and you think it is very likely that people will complain if Wayland doesn't do metadata pass-through?
<pq>
well, the compositor at hand
kasper93 has quit [Read error: Connection reset by peer]
Guest21924 has quit [Ping timeout: 480 seconds]
kasper93 has joined #wayland
kasper93_ has joined #wayland
kasper93 is now known as Guest21926
kasper93_ is now known as kasper93
<JEEB>
yea, since when trying to validate these flows they will attempt to see that input matches output
<JEEB>
in the nicer cases they will ask, in the less nicer cases they will complain that this is a bug
<kasper93>
zamundaaa[m]: yes, getting good enough output is easy. Even not doing anything with metadata works, and some users prefer that even, for clipped look...
<pq>
Personally I expect that we will be changing compositor tone and gamut mapping algorithms many times before we find a good compromise.
<kasper93>
at least for movie playback many people wants perfect picture, and those I'm concerned about
<kasper93>
pq: yes, historically people are very nitpicky about this. And if I can say, "I'm sending everything as-is" I would be more happy
<kasper93>
instead of "yeah, we sanitize the data that's why XYZ software works better for you, sorry"
karenw has joined #wayland
<pq>
right
<kasper93>
sorry, if I missed some messages, but my network card started resetting for some reason
<pq>
I don't think you missed any.
<JEEB>
I actually kinda wish we understood how the max brightness values in EDID (full screen and limited screen) affected display tone mapping. since I'd love to be able to have f.ex. mpv tone map into display's capabilities, and then not having the display do anything
Guest21926 has quit [Ping timeout: 480 seconds]
<pq>
JEEB, we heard in Display Next hackfest, that the standard approach is to take the EDID values and echo them back in HDR metadata, and hope for the best.
<pq>
err, common approach
<pq>
until actual SBTM happens
<JEEB>
so max content light to the limited frame and average to full frame? (in my case the TV says ~1500 for limited and ~800 for full)
<pq>
and zamundaaa[m] said some displays bork when doing that :-P
<JEEB>
or of course smaller if the content doesn't go that high
Max1 has joined #wayland
<pq>
I guess that depends on what blocks the EDID actually has.
<pq>
I think we need to approach this HDR thing such that it will break many times for many loud users.
<pq>
That said, I'm not too opposed to relaxing the maxCLL and maxFALL validation.
<kasper93>
JEEB: your display is reporting maxCLL 800 and maxFALL 1500?
<zamundaaa[m]>
<pq> "kasper93, and you think it is..." <- So far we haven't gotten any complaints about metadata pass-through specifically
<kasper93>
FYI, on Windows DXGI only provides MaxFullFrameLuminance in output description
<zamundaaa[m]>
Some people do complain about not passing everything to the display as-is, but most of those were about gaming. Most of the rest were just about a complete misunderstanding of how the mastering process works on Wayland
<kasper93>
HDR is hard... each issue involves some sort of educating the user how things work
<MrCooper>
zamundaaa[m]: can the compositor even pass through the metadata in the windowed case? Note that I suspect some previous messages here might have meant "pass-through" between the Wayland client and compositor, not necessarily to the display
<kasper93>
and it's always hard to explain why windowed mode looks different than fullscreen...
<kasper93>
MrCooper: only in fullscreen I guess
<zamundaaa[m]>
[@_oftc_MrCooper:matrix.org](https://matrix.to/#/@_oftc_MrCooper:matrix.org): you could do it approximately, yes. Not with good results though
<zamundaaa[m]>
About pass-through from client to compositor, I've argued for it before
<zamundaaa[m]>
But the main argument against it was that the client can sanitize metadata with more context than the compositor, which is reasonable too
karenw has quit [Quit: Deep into that darkness peering...]
LoneStarr has joined #wayland
kts has quit [Quit: Konversation terminated!]
<JEEB>
kasper93: maxfullframeluminance of 800 and the other one with limited (whatever its name was...) is exposed as 1500 nits in dxdiag
<kasper93>
wow, dxdiag shows that? :D
<JEEB>
at least the report, yes
<JEEB>
> Display Luminance: Min Luminance = 0.010000, Max Luminance = 1499.000000, MaxFullFrameLuminance = 799.000000
tzimmermann has quit [Quit: Leaving]
<JEEB>
finally found one report which did not only have my lulzy dell display
<kasper93>
Ok, but that's Max Luminance and Max Full Frame
<JEEB>
yea
<kasper93>
on Wayland it also gives maxFALL which seems to be the same value as Max Luminance
<kasper93>
I think maxFALL doesn't make sense for monitor/display description
<JEEB>
funky, but now it makes sense that they talked about "echo them back in HDR metadata", since none of these are exactly ST 2086 metadata
<kasper93>
it's parameter of the HDR content, anyway..