This sounds like a bug that was fixed some time ago - the desktop window is stealing focus when it gets created, so every time the display reconnects to the PC.

Because you’re on Debian with Plasma 5.27.5, you don’t have that fix though.

I don’t actually believe this to be the case, if it was people who use custom ICCs would get extremely wonky results that don’t typically happen

They wouldn’t, because applying ICC profiles is opt-in for each application. Games and at least many video players don’t apply ICC profiles, so they do not see negative side effects of it being handled wrong (unless they calibrate the VCGT to follow the piece-wise TF).

With Windows Advanced Color of course, that may change.

I think I am a bit confused on the laptop analogy then, could you elaborate on it?

What analogy?

How monitors typically handle this is beyond me I will admit, But I have seen some really bonkers ways of handling it so I couldn’t really comment on whether or not this holds true one way or another. Just so I am not misinterpeting you, are you saying that “if you feed 300nits of PQ, the monitor will not allow it to go above it’s 300nits”? IF so this is not the case on what happens on my TV unless I am in “creator/PC” mode. In other modes it will allow it to go brighter or dimmer.

Yes, that’s exactly what happens. TVs do random nonsense to make the image look “better”, and one of those image optimizations is to boost brightness. In this case it’s far from always nonsense of course (on my TV it was though, it made the normal desktop waaay too bright).

unless I am in “creator/PC” mode

Almost certainly just trying to copy what monitors do.

With libjxl it doesn’t really default to the “SDR white == 203” reference from the “reference white == SDR white” common… choice? not sure how to word it… Anyways, libjxl defaults to “SDR white = 255” or something along those lines, I can’t quite remember. The reasoning for this was simple, that was what they were tuning butteraugli on.

Heh, when it came to merging the Wayland protocol and we needed implementations for all the features, I was searching for a video or image standard that did exactly that. The protocol has a feature where you can specify a non-default reference luminance to handle these cases.

It is indeed the case that users wont know what transfer function content is using. but they absolutely do see a difference other then “HDR gets brighter then SDR” and that is “it’s more smooth in the dark areas” because that is also equally true.

That is technically speaking true, but noone actually sees that. People do often get confused about bit depth vs. HDR, but that’s more to do with marketing conflating the two than people actually noticing a lack of banding with HDR content. With the terrible bitrates videos often use nowadays, you can even get banding in HDR videos too :/

When you play an HDR and an SDR video on a desktop OS side by side, the only normally visible differences are that the HDR video sometimes gets a lot brighter than the SDR one, and that (with a color managed video player…) the colors may be more intense.

Again, the reference luminance mapping is all about how applications should use the Wayland protocol.

How to map SDR to HDR can indeed be made much more complicated, from simple gamma adjustments to some full blown ITM meant for images or videos, like what BT.2446 suggests, but as far as applications are concerned, those are edge cases that they don’t really need to be prepared for.

It’s not like they have a different choice - unless the compositor supports custom reference luminance levels (which KWin does, but not all others do), then they need some logic to calculate peak luminance levels. If the compositor steps outside of those common expectations for reference luminance mapping, then the result may not be ideal, but there is no way for the application to do better.

For one it assumes all sRGB monitors utilize gamma2.2 for decoding images

Assuming that all monitors do anything specific at all would be a folly, no. There are no assumptions there, the sRGB spec has no ambiguity when it comes to the transfer function of the display.

That a certain percentage of displays don’t behave like expected is annoying, but doesn’t really change anything (beyond allowing the user to change the assumed transfer function in SDR mode).

this is why windows HDR uses the inverse oetf. Decoding content graded on a pure 2.2 display with the inverse oetf is way better then decoding content graded on an inverse oetf display with a pure 2.2. Windows took the safe route of making sure most content looks at least OK. I would not say that windows HDR is wrong, it’s not right, but it’s not wrong either. this is just the mess that sRGB gave us.

The most likely actual reason Window uses the piece-wise transfer function for HDR is that it did that in SDR mode too - where however the default ICC profile was also piece-wise sRGB, so it canceled out on 99% of PCs, and had no negative effects.

Another time you should be using the inverse sRGB OETF to linearize content when the original content was encoded using the sRGB oetf and you want to go back to that working data, but this applies less to compositors and more to authoring workflows.

Makes sense.

People have been adjusting monitor brightness for ages. Sometimes manually, sometimes with DDC etc.

That’s a very different thing. Pushing viewing environment adjustments to the display side makes some amount of sense with SDR monitors - when you get an SDR display with increased luminance capabilities vs. the old one, you change the monitor to display the content comfortably in your environment.

With HDR though, if the operating system considers PQ content to be absolute in luminance, you can’t properly adjust that on the monitor side anymore, because a lot of monitors completely lock you out of brightness controls in HDR mode, and the vast majority of the ones that do allow you to adjust it, only allow you to reduce luminance, not increase it above “PQ absolute”.

Another issue that is brought up is “graphics white” BT.2408 is a suggestion, not a hard coded spec, many different specs or suggestions use a different “graphics white” value.

I didn’t claim that PQ had only one specification that uses it, I split up SMPTE ST 2084, rec.2100 and BT.2408 for a reason. I didn’t dive into it further because a hundred pages of diving into every detail that’s irrelevant in practice is counter productive to people actually learning useful things.

A good example of this is JXL.

Can you expand on what you mean with that?

2408 also very explicitly says ‘The signal level of “HDR Reference White” is not directly related to the signal level of SDR “peak white”.’

That “directly” is very important, as it does very much make both these signal levels the same. As I wrote in the blog post, the spec is all about broadcasts and video.

Other systems do sometimes split these two things up, but that nearly always just results in a bad user experience. I won’t rant anymore about the crapshow that is HDR on Windows, but my LG TV cranks up brightness of its UI to the absolute maximum while an HDR video is playing. If they would adhere to the recommendations of BT.2408, they would work much better.

this is important to note because this directly contradicts the some of the seemingly core assumptions made in the article, and even some of the bullet points like “a reference luminance, also known as HDR reference white, graphics white or SDR white” and “SDR things, like user interfaces in games, should use the reference luminance too”

No contradictions at all. The Wayland protocol defines these things to be the same, so for application developers they just are the same, end of story.

This needs to be expanded upon that this does NOT correlate to what the general user understands HDR and SDR to be. HDR and SDR in the terms of video content is no more then a marketing term and without context it can be hard to define what it is, However it is abundantly clear from this quote here that how they are interpreting HDR and SDR (which is a very valid technically inclined way of interpreting it) does NOT fall inline with general user expectation.

That’s just absolute nonsense. The very very vast majority of users do not have any clue whatsoever what transfer function content is using, or even what a transfer function, buffer encoding or even buffers are, the only difference they can see is that HDR gets brighter than SDR.

And again, this too is about how applications should use the Wayland protocol. This is the only way to define it that makes any sense.

They did fix that a while ago though?

TV manufacturers are part of the cartel HDMI forum, which benefits from there being a big ecosystem of non-member devices that are forced to have HDMI ln them and pay licensing fees for it.

does X11 support actually measuring and calibrating colour?

To the same level that Wayland does - it doesn’t actively do anything for or against it. There are tools that happen to be built for X11, and which you can also use on Wayland (with a very small amount of additional manual steps vs. how it works on X11)

You can’t. Apps need to support shortcuts in order to receive them…

For Discord, the X11 compatibility page has working options though.

Umm yes, they did take ages to support it. It took like 7 years…

It was implemented over two years ago.

Do motherboard/monitor/IC/etc manufactures need to submit their own kernel patches well in advance of product releases, like what AMD and Intel do for their CPUs and GPUs? Are we just waiting for them to give a shit?

Yes. There isn’t really any other good solution.

Why does Nvidia need to support night light?

They don’t, but they needed to support the KMS API for applying lookup tables to the image sent to the screen - desktops relied on that functionality without a fallback, so when it wasn’t available, you just didn’t get the feature.

Can’t someone from Wayland just write a simple shader in any shader language that does colour adjustments and apply it to the desktop?

There’s no such thing as “someone from Wayland”, just the developers of the DEs (well, the project is named after a town, but I’m sure that’s not what you meant).

But, yes, you can use a shader. We implemented that in KWin and we’re using it when the driver or hardware doesn’t support the functionality we need… but that has a noticeable performance impact, so it’s still necessary for the driver to support it natively.

That’s not right. Most monitors use 8 bits per color / 24 bits per pixel, though some are still using 6 bpc / 18bpp.

HDR doesn’t mean or really require more than 8bpc, it’s more complicated than that. To skip all the complicated details, it means more brightness, more contrast and better colors, and it makes a big difference for OLED displays especially.

You could also try using KDE Plasma instead of Gnome, which survives GPU resets.

Okay, then the driver doesn’t allow Plasma to turn it on for some reason. You can report that at https://gitlab.freedesktop.org/drm/i915/kernel/-/issues, maybe someone from Intel can help.

No I can’t move my mouse to the external monitor.

Do you mean that it stays on the internal display, or that it doesn’t show up on the external one?

Or to ask it differently, can you move a window where the monitor should be?

My laptop detects the monitor correctly so it shows up in the KDE plasma display configuration but the monitor is not getting any input.

So the system thinks it’s enabled? Can you move the mouse cursor to it?

It’s an Electron problem, yes. The API is there, just waiting to be used.

I understand that it’s an absolute brightness standard, not like the relative levels in SDR

The standard is also relative brightness actually, though displays (luckily) don’t implement it that way.

why does it end up washing out colors unless I amplify them in kwin? Is just the brightness absolute in nits, but not the color?

It depends. You might

• have a driver bug. Right now only AMD has correct color space communication with the display, that doesn’t work correctly on Intel and NVidia yet
• have a display that does a terrible job at mapping the rec.2020 color space to the display
• be just used to the oversaturated colors you get with the display in SDR mode

Why does my screen block the brightness control in HDR mode but not contrast?

Because displays are stupid, don’t assume there’s always a logical reason behind what display manufacturers do. Mine only blocks the brightness setting through DDC/CI, but not through the monitor OSD…

Why is my average emission capped at 270nits, that seems ridiculously low even for normal SDR screens as comparison

OLED simply gets very hot when you make it bright over the whole area, the display technology is inherently limited when it comes to high brightness on big displays