SUMMARY I have ENABLE_HDR_WSI=1 always set for mpv, independent of display's HDR mode. It appears this vulkan layer slightly transforms the colors in SDR mode, resulting in the faintest gray in what should actually be black. Interestingly setting --background-color='#00000000' (thus setting alpha=0% for the background) has the black borders around the video be true black, while the video content is sligthly non-black. I though #494128 or #494134 could be related, but after logging out and back into 6.2.1, this issue still persists. Also setting kscreen-doctor output.2.minBrightnessOverride.0 didn't help. Actually I don't see any minbrightness information in kscreen-doctor -o. Enabling HDR mode for the display restores proper colors for SDR content. I do want HDR_WSI enabled for mkv at all times, since this is a jellyfin-mpv-shim, which is configured to enable HDR mode, whenever HDR content is detected - otherwise I'd need to run a SDR jellyfin-mpv-shim as well and select the player depending on content. But maybe vk_hdr just isn't built to support this? STEPS TO REPRODUCE 1. Run mpv with ENABLE_HDR_WSI env variable set. 2. Don't enable HDR mode for the display, since we are only going to watch SDR content now. 3. Maybe set --background-color='#00000000' for true black borders around the video. OBSERVED RESULT There's a faint glow in black parts of the video - OLED pixels should be off though. EXPECTED RESULT Black is black, pixels stay off. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.2.1 KDE Frameworks Version: 6.7.0 Qt Version: 6.8.0 Kernel Version: 6.11.3-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 PRO 4750U with Radeon Graphics Memory: 46.3 GiB of RAM Graphics Processor: AMD Radeon Graphics ADDITIONAL INFORMATION current vk_hdr_layer
Could you attach the command line output when you run mpv? It should print some HDR metada, which KWin may be using to do black point compensation (wrong)
(In reply to Zamundaaa from comment #1) > Could you attach the command line output when you run mpv? It should print > some HDR metada, which KWin may be using to do black point compensation > (wrong) [HDR Layer] Created HDR surface [HDR Layer] Enabling format: 64 colorspace: 1000104008 [HDR Layer] Enabling format: 58 colorspace: 1000104008 [HDR Layer] Enabling format: 97 colorspace: 1000104002 [HDR Layer] Enabling format: 97 colorspace: 1000104005 [HDR Layer] Enabling format: 64 colorspace: 1000104008 [HDR Layer] Enabling format: 58 colorspace: 1000104008 [HDR Layer] Enabling format: 97 colorspace: 1000104002 [HDR Layer] Enabling format: 97 colorspace: 1000104005 btw. with HDR display mode enabled, it looks OK.
hmm, I wasn't able to reproduce this; on my external monitor, the default black bars in mpv turn off the local dimming (which I force-enabled in SDR mode), and I don't see a difference vs. SDR application's black levels. Are you using an ICC profile?
(In reply to Zamundaaa from comment #3) > hmm, I wasn't able to reproduce this; on my external monitor, the default > black bars in mpv turn off the local dimming (which I force-enabled in SDR > mode), and I don't see a difference vs. SDR application's black levels. > > Are you using an ICC profile? No, ICC profile is "None". I left these lines out: HDR Layer] Creating swapchain for id: 5 - format: VK_FORMAT_R16G16B16A16_UNORM - colorspace: VK_COLOR_SPACE_SRGB_NONLINEAR_KHR [HDR Layer] Creating swapchain for id: 5 - format: VK_FORMAT_R16G16B16A16_UNORM - colorspace: VK_COLOR_SPACE_SRGB_NONLINEAR_KHR My command looks like this: ENABLE_HDR_WSI=1 mpv <file> --no-config --background-color='#00000000' --target-colorspace-hint=yes --vo=gpu-next --gpu-context=waylandvk with display HDR enabled it looks fine, without it, the black bars are blacker than the content (due to alpha values being set to 00. Without background-color they'd be slightly gray as well).
As a workaround for now I just set gpu-context=wayland instead of waylandvk for SDR content - this way the vk layer isn't used and SDR looks alright again. With profile-cond=get("video-params/sig-peak", 0) > 1 waylandvk is set and HDR gets enabled through a lua script and kscreen-doctor. Btw. I have had the issue of enabling HDR sometimes not properly triggering the display since the inception of HDR in kwin. This happens when I turn it off and on again, it appears it's not sending the proper mode to the display. The HDR logo doesn't show and colors are washed out.
I think I see how this could happen; if the min. luminance HDR metadata is zero, but the transfer function's minimum is not completely zero, then that minimum would be mapped to a value >0 by black point compensation. (In reply to FK from comment #5) > Btw. I have had the issue of enabling HDR sometimes not properly triggering > the display since the inception of HDR in kwin. This happens when I turn it > off and on again, it appears it's not sending the proper mode to the > display. The HDR logo doesn't show and colors are washed out. That's a GPU driver bug, which you can report at https://gitlab.freedesktop.org/drm/amd/-/issues
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6656
Please test that MR, to see if it actually helps
This seems to fix it for me. Thanks!
*** Bug 494907 has been marked as a duplicate of this bug. ***
Git commit cef6656ff57e19e7eb551f81ee5b03028a7f38a9 by Xaver Hugl. Committed on 24/10/2024 at 14:10. Pushed by zamundaaa into branch 'master'. core/colorspace: ensure that we don't create elevated blacks with black point compensation There are cases where the minimum luminance can be lower than the transfer function's minimum; in those cases, the transfer function's minimum would get mapped to a value greater than black in the target transfer function. To avoid that, this just takes the max. of the metadata and transfer function minimum M +1 -1 autotests/test_colorspaces.cpp M +5 -2 src/core/colorspace.cpp https://invent.kde.org/plasma/kwin/-/commit/cef6656ff57e19e7eb551f81ee5b03028a7f38a9
Git commit f702ad9c4cee58e8e438e3d22ff202a80ac8b3ff by Xaver Hugl. Committed on 24/10/2024 at 14:27. Pushed by zamundaaa into branch 'Plasma/6.2'. core/colorspace: ensure that we don't create elevated blacks with black point compensation There are cases where the minimum luminance can be lower than the transfer function's minimum; in those cases, the transfer function's minimum would get mapped to a value greater than black in the target transfer function. To avoid that, this just takes the max. of the metadata and transfer function minimum (cherry picked from commit cef6656ff57e19e7eb551f81ee5b03028a7f38a9) M +1 -1 autotests/test_colorspaces.cpp M +5 -2 src/core/colorspace.cpp https://invent.kde.org/plasma/kwin/-/commit/f702ad9c4cee58e8e438e3d22ff202a80ac8b3ff