SUMMARY SDR brightness setting affects HDR brightness (Plasma 6.2 beta) STEPS TO REPRODUCE 1. Install kwin 6.1.90-1 2. Enable hdr. 3. Open hdr video in mpv launched with `ENABLE_HDR_WSI=1 mpv --vo=gpu-next --target-colorspace-hint --gpu-api=vulkan --gpu-context=waylandvk --player-operation-mode=pseudo-gui --target-gamut=bt.2020` command. 4. Use the sdr brightness slider or kscreen-doctor to change sdr brightness. 5. Brightness of video changes OBSERVED RESULT Brightness of the video changes in relation to the sdr brightness. Opening the same video side by side in normal mpv, the hdr one remains brighter / darker than the same video opened in normal mpv based on the brightness of the video, but is moreso affected by the sdr brightness setting. EXPECTED RESULT Sdr brightness doesn't affect hdr brightness or the setting should be labeled differently SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.1.90 KDE Frameworks Version: 6.6.0 Qt Version: 6.8.0 Kernel Version: 6.10.10-arch1-1 (64-bit) ADDITIONAL INFORMATION I've seen https://bugs.kde.org/show_bug.cgi?id=478860 but this seems to be happening again in plasma 6.2 beta, wasn't sure if I should necro that one so I made a new report. Doesn't happen if I downgrade kwin to 6.1.5-2. Monitor connected to amd igpu via dp. Effect compounds with system tray brightness slider. Possibly related to https://bugs.kde.org/show_bug.cgi?id=494128 (elevated black levels). The SDR brightness slider doesn't affect the black level unless system tray brightness slider is turned low so I filed these seperately.
Yes it does, and this is intentional. The slider changes the reference luminance of the screen, which basically defines the brightness of "normal" white - for SDR that's 100% brightness, HDR can simply do more than 100%. However, this is only supposed to be relevant for 6.3; in 6.2, the frog color management protocol (which the Vulkan layer uses) still gets "pass through" and should not be affected. If you resize the window after changing the setting, does it go back to the brightness level it had before? > or the setting should be labeled differently Do you have any suggestions? Fixing the text for the ContextualHelpButton next to the slider is easy as we can put a sentence or two in it, but the name of the option needs to be short and ideally intuitively understood. "reference luminance" or "reference brightness" are short, but noone will understand them without reading the help button text.
Thanks for the quick reply! > If you resize the window after changing the setting, does it go back to the brightness level it had before? No, it stays the same. What's the default value for reference brightness? Is it supposed to be calibrated against a piece of paper or something? I think it would be useful if there was still an option to have passthrough or a nice suggested default for the setting that approximates it. As for the name I think I saw 'paper white' being used before, again not sure if that's what this is. What's the brightness (of a video) that makes hdr equivalent to sdr? Could it be possible to have a slider that adjusts this value for personal taste? (eventually)
(In reply to lojcsgit from comment #2) > Thanks for the quick reply! > > > If you resize the window after changing the setting, does it go back to the brightness level it had before? > > No, it stays the same. That's weird. I just compiled the 6.2 branch and the video definitely snaps back to the brightness it had before changing the setting. > What's the default value for reference brightness? Is it supposed to be > calibrated against a piece of paper or something? That depends on your screen; for new output configs KWin defaults to 500 nits, or if your display can't show 500 nits in fullscreen, whatever the maximum value of the screen is. > I think it would be useful > if there was still an option to have passthrough or a nice suggested default > for the setting that approximates it. As for the name I think I saw 'paper > white' being used before, again not sure if that's what this is. It's quite literal, it refers to the brightness a sheet of paper would have in the room you're in. Pass through would *not* provide that, because the screen doesn't know about the room any more than KWin does, and most screens even lock the user out of brightness controls in HDR mode. The best approximation we have for paper white is the user setting the brightness level they're comfortable with - that's what the SDR brightness setting + the brightness slider are there for. That gives me an idea though: As the setting only exists to limit the brightness slider, so that you don't accidentally set it too high (above some reference luminance, displays start doing weird tone mapping for GUI elements), perhaps we can just show it as exactly that: An override for the max. brightness level of the brightness slider. I still need to add some brightness level override GUI for other values anyways... with that, this slider would just be gone from the main display settings page, and we could show the normal brightness slider instead (for HDR and SDR screens). > What's the brightness (of a video) that makes hdr equivalent to sdr? Could > it be possible to have a slider that adjusts this value for personal taste? > (eventually) In 6.3, an HDR video showing the reference luminance will already have the same brightness as an SDR video showing 100% white. In 6.2 the SDR brightness value to match the SDR content to (most) HDR videos is 203 nits.
I tried it again and it's working like you described. I must've made a mistake. > As the setting only exists to limit the brightness slider So it's going to be an approximate passthrough for shades darker than reference and some amount of overshoot to avoid crushing brighter ones? Sounds good, I think that's how my monitor's brightness setting works too Thanks for your time, I'm marking this resolved
(In reply to lojcsgit from comment #4) > So it's going to be an approximate passthrough for shades darker than > reference and some amount of overshoot to avoid crushing brighter ones? > Sounds good, I think that's how my monitor's brightness setting works too Mostly yes. When KWin applies tone mapping, it may reduce the brightness of the reference for a given window by up to 33% to get a range of brightness values to put that "brighter than reference" stuff into (mostly used on screens that can't do HDR though) > Thanks for your time, I'm marking this resolved There's still the bit about this not behaving as expected in 6.2, which should be fixed.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6567
Git commit ad26698241fd2c201bf502564d9cd1597ea35267 by Xaver Hugl. Committed on 05/10/2024 at 13:01. Pushed by zamundaaa into branch 'Plasma/6.2'. wayland/frog color management: restore pass through behavior The previous code emulated "pass through" behavior by adjusting the reference luminance to the preferred color description's reference luminance, but that doesn't work out in all situations, like when the preferred color description changes but the client doesn't commit any color management changes on its surface. This approach fixes that by just adding a boolean flag for this pass through mode to the color description, and setting it in the protocol implementation. This commit is 6.2-only, as the master branch has dropped this pass through emulation and doesn't need such hacks for HDR content to behave properly on settings changes. M +8 -2 src/core/colorspace.cpp M +3 -0 src/core/colorspace.h M +2 -4 src/wayland/frog_colormanagement_v1.cpp https://invent.kde.org/plasma/kwin/-/commit/ad26698241fd2c201bf502564d9cd1597ea35267
Is it app dependent as to whether this is fixed? Now gamescope isn't affected by the SDR brightness slider, but wine wayland and mpv still are.
Yes, ish. Only apps using the frog protocol get "passthrough", if you're using a different Vulkan layer from mine, one that uses the upstream protocol, it'll behave differently.
(In reply to Zamundaaa from comment #9) > Yes, ish. Only apps using the frog protocol get "passthrough", if you're > using a different Vulkan layer from mine, one that uses the upstream > protocol, it'll behave differently. I'm using your layer. Perhaps that's the cause, gamescope is using the protocol directly, but mpv and others use the layer.
Seems the issue is finally fixed by using KWIN_DISABLE_TONEMAPPING=1
I'm experiencing this bug in 6.3.1. MPV with the aforementioned vulkan layer is affected by the "Maximum SDR Brightness" slider, as is gamescope. KWIN_DISABLE_TONEMAPPING=1 has no effect either way. Resizing the window as suggested above also has no effect.
Yes, that's intentional, see bug 499934