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.

Hi,

sadly with the upgrade to kwin 6.6 the same issue showed up again.

I have set the following in the hdr setup tool:

1. Max peak brightness 940
2. Max overall brightness 250
3. Brightness: 250

Setting the option:

Asume hdr applications are calibrated for that screen to off or on does not make a difference.


Many thx !
Pingubot

I can also confirm that after 6.6 HDR is broken (on intel+NVIDIA at least):

Note that 1 and 2 run on Intel while 3 (games) run on NVIDIA

1. Chromium does not support anymore. Any tests online do not work and videos on yotube have bt709. Display info from chromium:
So technically primaries are HDR but transfer is gamma22? And 8 bits per pixel?

2. Firefox does not support HDR without forcibly enabling it.
If just `gfx.wayland.hdr` is on, hdr *does not work, but it used to*
If `gfx.wayland.hdr.force-enabled` is on, then hdr does work

3. Games run on NVIDIA via Proton do see HDR and work correctly

==== SYSTEM INFO ===

Operating System: Fedora Linux 43
KDE Plasma Version: 6.6.0
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.1
Kernel Version: 6.18.10-200.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × 12th Gen Intel® Core™ i7-12650H
Memory: 32 GiB of RAM (31.0 GiB usable)
Graphics Processor 1: Intel® Graphics
Graphics Processor 2: NVIDIA GeForce RTX 3060 Laptop GPU
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: Vivobook_ASUSLaptop N7601ZM_N7601ZM
System Version: 1.0

=== KSCREEN DOCTOR INFO ===

Output: 1 eDP-1 ece136f5-6f86-4693-86ff-33ed630b546e
        enabled
        connected
        priority 1
        Panel
        replication source:0
        Modes:  1:3840x2400@60.00*!  2:1600x1200@59.87  3:1280x1024@59.90  4:1024x768@59.92  5:2560x1600@59.99  6:1920x1200@59.88  7:1280x800@59.81  8:3840x2160@59.98  9:3200x1800@59.96  10:2880x1620@59.96  11:2560x1440@59.96  12:1920x1080@59.96  13:1600x900@59.95  14:1368x768@59.88  15:1280x720@59.85 
        Custom modes: None
        Geometry: 0,0 1536x960
        Scale: 2.5
        Rotation: 1
        Overscan: 0
        Vrr: incapable
        RgbRange: Automatic
        HDR: enabled
                SDR brightness: 600 nits
                SDR gamut wideness: 80%
                Peak brightness: 600 nits, overridden with: 600 nits
                Max average brightness: 590 nits, overridden with: 590 nits
                Min brightness: 0.0046 nits
        Wide Color Gamut: enabled
        ICC profile: none
        Color profile source: sRGB
        Color power preference: prefer efficiency and performance
        Brightness control: supported, set to 100% and dimming to 100%
        Color resolution: automatic (10), range: [6; 12] bits per color
        Allow EDR: always
        Sharpness control: unsupported
        Automatic brightness: unsupported

=== CHROMIUM DISPLAY INFO ===

Display(s) Information
======================
Info                          : Display[64] bounds=[0,0 1536x960], workarea=[0,0 1536x960], scale=2.5, rotation=0, panel_rotation=0 external detected
Color space (all)             : {primaries:BT2020, transfer:GAMMA22, matrix:RGB, range:FULL}
Buffer format (all)           : RGBA_8888
Color volume                  : {name:'rec2020', r:[0.7080, 0.2920], g:[0.1700, 0.7970], b:[0.1310, 0.0460], w:[0.3127, 0.3290]}
SDR white level in nits       : 600
HDR relative maximum luminance: 1
Bits per color component      : 8
Bits per pixel                : 24

Hi,

one additional info from my side:

When setting KWIN_DISABLE_TONEMAPPING=1 i am able to at least somehow use the ingame slider to set max peak brightness.
But sadly it does not work correctly. I should be able to set peak brightness up to 940 (this worked fine in the past with the in game testpicture). If i set the whitepoint via the ingame slider the test picture shows it is a value of 750 instead of 940nits.

The issue with the 750nits instead of 940nits is already in 6.5.5 . 

Br,
Pingubot

> Asume hdr applications are calibrated for that screen to off or on does not make a difference.
Un-checking that option doesn't remove the previous calibration.
If you want to remove it, or modify it, you can do so in ~/.config/kwinrc (the Windows_HDR section). For scRGB games, Reference was previously assumed to be 80, for PQ, it was 203.

If the values are not set, KWin defaults to
Reference=203
MaxFrameAverage=600
MaxLuminance=1000

(you may need to restart kwin to apply the new values, I don't remember which command can be used to make it re-load the config)

(In reply to Jakub from comment #14)
> I can also confirm that after 6.6 HDR is broken (on intel+NVIDIA at least):
> 
> Note that 1 and 2 run on Intel while 3 (games) run on NVIDIA
> 
> 1. Chromium does not support anymore. Any tests online do not work and
> videos on yotube have bt709. Display info from chromium:
> So technically primaries are HDR but transfer is gamma22? And 8 bits per
> pixel?.
> 2. Firefox does not support HDR without forcibly enabling it.
> If just `gfx.wayland.hdr` is on, hdr *does not work, but it used to*
> If `gfx.wayland.hdr.force-enabled` is on, then hdr does work
You've set your display so that reference / SDR luminance is the same as peak luminance. In other words, your display settings make it SDR, so the browsers don't bother loading HDR videos.

> 3. Games run on NVIDIA via Proton do see HDR and work correctly
Nvidia doesn't support HDR in its Vulkan driver, you need to do additional setup to work around it. Using gamescope is probably the easiest way to do it.

Reconfiguring my peak luminance to != reference luminance did work, thanks a lot! That's obviously an issue on my end, but maybe putting some warning/note would be a nice idea - I am confident that setting peak luminance == reference luminance (I did not change my settings) was still triggering browsers to display the HDR video in kwin 6.5.x (even if it technically did not make sense).

As for the 3., I think the 595 will support, but even with 580 with Proton-GE and PROTON_ENABLE_HDR=1 games did show the HDR option and it did look different with it on (and it looked semi-correct, but in 6.5 it looked completly broken), altough I did not verify if the colors are really HDR or only pretend to be. Thanks nevertheless!

For me, the issues are solved.