Can you please clarify what you mean exactly by configuring the white point?

(In reply to Vlad Zahorodnii from comment #1)
> Can you please clarify what you mean exactly by configuring the white point?

There is an option in game to configure the whitepoint. You adjust a slider so that a white skull infront of a white background is barely visible. I did that on 6.2 and the value which was choosen was 950 (which somehow matches my displays max nits).

Now i have no way to adjust the slider so that this works at all. The white sull will always be fully visible, no matter what i do with the slider.

HDR simply does not work fin4 anymore as it seems. You notice that already when the game starts that the white lettering on black ground simply does not pop out anymore.

I tried to downgrade kwin to 6.2.x, but only go a black screen (even sddm did not work).


Br

(In reply to bugreports61 from comment #0)
> My settings in display settings:
> 
> Max SDR Brightness: 100
> Brightness: 40
That's pretty dark, resulting in a reference luminance of 43 cd/m². It is expected that games will be rather dark with that.

> Sadly i don't know how the Brightness slide interacts with my monitor. In
> HDR mode the monitor locks the brightness setting, but still using that
> display setting brightness sliders changes display brightness ?
> 
> I honestly dislike having that setting at all , as changing things there do
> not get reflected in the monitors brightness settings. Same in sdr mode.
It doesn't interact with the monitor at all, because the vast majority of displays indeed lock their internal controls in HDR mode.
The setting configures paper white for both SDR and HDR content.

> [HDR Layer] VkHdrMetadataEXT: mastering luminance min 0.000000 nits, max 10000000.000000 nits
That's suspicious, and might be causing the problem.
When HDR metadata is completely nonsensical like that, KWin just ignores it. Brightness of the game will be limited to SDR levels, causing this issue.
This logic isn't new at all, but maybe the new brightness logic makes its effect more obvious.

If you put KWIN_DISABLE_TONEMAPPING=1 into /etc/environment and reboot, does it work more like expected then?

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7186

Git commit 218055e215f8f3ec027682235ec31b5f17b305b7 by Xaver Hugl.
Committed on 18/02/2025 at 16:02.
Pushed by zamundaaa into branch 'master'.

wayland: make the fallback for broken HDR metadata less strict

If no HDR metadata is available at all, we assume that the application only emits
SDR levels - as specified by the Wayland protocol.
Because of that, resetting the HDR metadata entirely when it's nonsensical causes
luminance levels to be clipped to SDR for many broken games. This commit changes
the fallback to use luminance levels for HGIG Category 2 displays instead
(600 cd/m² max average, 1000 cd/m² max peak) which are pretty common.

M  +12   -11   src/wayland/colormanagement_v1.cpp
M  +6    -1    src/wayland/frog_colormanagement_v1.cpp

https://invent.kde.org/plasma/kwin/-/commit/218055e215f8f3ec027682235ec31b5f17b305b7

Git commit 43504c9c389218b3ed9fa9dcc8d1e4fe10f4b037 by Xaver Hugl.
Committed on 18/02/2025 at 16:29.
Pushed by zamundaaa into branch 'Plasma/6.3'.

wayland: make the fallback for broken HDR metadata less strict

If no HDR metadata is available at all, we assume that the application only emits
SDR levels - as specified by the Wayland protocol.
Because of that, resetting the HDR metadata entirely when it's nonsensical causes
luminance levels to be clipped to SDR for many broken games. This commit changes
the fallback to use luminance levels for HGIG Category 2 displays instead
(600 cd/m² max average, 1000 cd/m² max peak) which are pretty common.


(cherry picked from commit 218055e215f8f3ec027682235ec31b5f17b305b7)

Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>

M  +12   -11   src/wayland/colormanagement_v1.cpp
M  +6    -1    src/wayland/frog_colormanagement_v1.cpp

https://invent.kde.org/plasma/kwin/-/commit/43504c9c389218b3ed9fa9dcc8d1e4fe10f4b037

(In reply to Zamundaaa from comment #3)
> (In reply to bugreports61 from comment #0)
> > My settings in display settings:
> > 
> > Max SDR Brightness: 100
> > Brightness: 40
> That's pretty dark, resulting in a reference luminance of 43 cd/m². It is
> expected that games will be rather dark with that.

My goal is that the monitor is running at 100 nits. It has a max fullscreen luminance of 250 nits.
So u have to set Max SDR Brightness to 250 and the the Brightness at 40 to achieve that goal ?

In addition, what is the brightness slider doing when the monitor is running in sdr mode ?
Cause changing the brightness slider there does also not adjust it on the monitor settings. How is that interacting ?

I have to mention i have the following in the powerdevil service file (was a recommendation for an older kde bug):

[Service]
Environment="POWERDEVIL_NO_DDCUTIL=1"

> 
> > Sadly i don't know how the Brightness slide interacts with my monitor. In
> > HDR mode the monitor locks the brightness setting, but still using that
> > display setting brightness sliders changes display brightness ?
> > 
> > I honestly dislike having that setting at all , as changing things there do
> > not get reflected in the monitors brightness settings. Same in sdr mode.
> It doesn't interact with the monitor at all, because the vast majority of
> displays indeed lock their internal controls in HDR mode.
> The setting configures paper white for both SDR and HDR content.
>
So how can it make the picture brighter without telling the monitor to do so ? (sorry for dumb questions, i am a noob in that regard)

 
> > [HDR Layer] VkHdrMetadataEXT: mastering luminance min 0.000000 nits, max 10000000.000000 nits
> That's suspicious, and might be causing the problem.
> When HDR metadata is completely nonsensical like that, KWin just ignores it.
> Brightness of the game will be limited to SDR levels, causing this issue.
> This logic isn't new at all, but maybe the new brightness logic makes its
> effect more obvious.
> 
> If you put KWIN_DISABLE_TONEMAPPING=1 into /etc/environment and reboot, does
> it work more like expected then?
No, this does not help that time.

It worked last time to fix a hdr issue in 6.2 before you applied a fix, see here: https://bugs.kde.org/show_bug.cgi?id=494502

And on addition info: Downgrading to kwin 6.2.5 with also downgrading kdecorations (kwin_wayland for kwin 6.2.5 needed an older kdecoration lib) fixes the issues, i am fully able to set the whitepoint again with the slider.

In addition to my other questions, as its mentioned to be fixed, when will the fix land ?

In Plasma 6.3.2, as is written in the "version fixed in" text field.

(In reply to Nate Graham from comment #10)
> In Plasma 6.3.2, as is written in the "version fixed in" text field.

The time i asked this question it was not written there, it was added afterwards .

As 6.3.2 showed up today i did a retest:

My monitor is that one:
https://www.rtings.com/monitor/reviews/dell/alienware-aw3423dwf

KDE Setting:

Max SDR Brightness: 250
Brightness: 40

Situation with Plasma 6.2:

I could set the brightness of my monitor to my preferred value (40% of ~250 nits max fullscreen brightness) and was able to adjust the whitepoint setting in game (dead island 2) which mentioned 950 (which is basically matching the monitors 2% sustained peak brightness).

Situation with Plasma 6.3.2:

As long as i keep my  brightness value to 40%, the in game whitepoint setting needs to be adjust to ~ 1950.
To achieve basically the same situation like it was in 6.2 i have to set the brightness to 80% which sadly causes the ABL to jump in.
In addition i have to constantly change the brightness between desktop and games cause 80% is simply why to bright for me in desktop usage. This was not the case in 6.2 and is simply not acceptable imo.

Therefore a few questions show up:

1. Is this intended behaviour (i was reading in another issue that brightness needs to be  set to 203 nits (which would match with the 80% of 250) so that hdr works correctly with expected brightness ? ) ?
2. Why did the situation change so much between 6.2 and 6.3 ? Imo hdr in 6.2 worked perfectly fine already. ?
3. Is there anything that can be done to improve the situation ?

As HDR is constantly changing in KDE, it would be heavily appreciated to get some explanation on how it works and how settings need to be done based on monitor values to achieve the best possible outcome.

Many thx !

> In addition i have to constantly change the brightness between desktop and games cause 80% is simply why to bright for me in desktop usage. This was not the case in 6.2 and is simply not acceptable imo.
You need to configure the games to fit for the changed brightness capabilities of what they see as the monitor, not the desktop.

> Is this intended behaviour
Yes. Brightness of all content is adjusted to match the reference luminance / SDR brightness level.

> Why did the situation change so much between 6.2 and 6.3 ? Imo hdr in 6.2 worked perfectly fine already?
It worked OK for games, but not for other applications. This change indeed made things a bit more confusing for Windows games, but there isn't a lot we can do about that without making things painful for native Linux applications that want to make use of HDR.

> Is there anything that can be done to improve the situation?
Godot's HDR support will work well with Wayland and not need you to calibrate stuff per game, and I hope more game engines follow that example (as they probably already do the same thing on MacOS)... but for existing Windows games, you just have to configure them to values that work for your situation.