Plasma 6.5 seems to squash Wayland Vulkan HDR mode into SDR color range

[kode54]

mpv Information

mpv v0.40.0-dirty Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on Sep 24 2025 17:56:15
libplacebo version: v7.351.0
FFmpeg version: n8.0
FFmpeg library versions:
   libavcodec      62.11.100
   libavdevice     62.1.100
   libavfilter     11.4.100
   libavformat     62.3.100
   libavutil       60.8.100
   libswresample   6.1.100
   libswscale      9.1.100

Other Information

- Linux version: Arch Linux
- Kernel Version: Linux copycat 6.18.0-rc3-1-cachyos-rc #1 SMP PREEMPT_DYNAMIC Mon, 27 Oct 2025 07:23:17 +0000 x86_64 GNU/Linux
- GPU Model: 03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 32 [Radeon RX 7700 XT / 7800 XT] [1002:747e] (rev ff)
- Mesa/GPU Driver Version: Mesa 25.2.5-arch1.2
- Window Manager and Version: Plasma kwin_wayland 6.5.0
- Source of mpv: Arch repos
- Latest known working version: Never worked without disabling tonemapping
- Issue started after the following happened: Re-enabled tonemapping

Reproduction Steps

1. Play the attached JXL screen shot

Expected Behavior

Screen shot should show bright spark explosion.

Actual Behavior

Screen shot shows same visible color range as SDR monitor, or as if I'm playing it on Cosmic beta 3, which has no HDR support.

Log File

output.txt

Sample Files

mpv-shot0001.jxl.gz (681 KiB)

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[kasper93]

Could you show stats (shift+I)? From your log it looks like the output is set to HDR10.

[kode54]

I'm gonna try disabling the tonemapper again. I guess they didn't actually fix it like they claimed they did.

[kasper93]

You can check newer mpv (master), it will set correct display luminance based on what compositor reports.

[kode54]

Yeah, that does the same thing without the tonemapper as stable does with the tonemapper. Here are the stats:

[kode54]

kscreen-doctor -o output:

Output: 1 DP-1 d0a9f63f-3e58-4dca-b04d-58294a36774e
	enabled
	connected
	priority 1
	DisplayPort
	replication source:0
	Modes:  1:3840x2160@60.00!  2:3840x2160@160.00*  3:3840x2160@143.85  4:3840x2160@120.00  5:3840x2160@119.88  6:3840x2160@120.00  7:3840x2160@100.00  8:3840x2160@60.00  9:3840x2160@59.94  10:3840x2160@50.00  11:3840x2160@30.00  12:3840x2160@29.97  13:3840x2160@25.00  14:3840x2160@24.00  15:3840x2160@23.98  16:2560x1440@159.80  17:2560x1440@120.00  18:2560x1440@59.95  19:1920x1080@120.00  20:1920x1080@119.88  21:1920x1080@100.00  22:1920x1080@60.00  23:1920x1080@60.00  24:1920x1080@59.94  25:1920x1080@50.00  26:1920x1080@30.00  27:1920x1080@29.97  28:1920x1080@25.00  29:1920x1080@24.00  30:1920x1080@23.98  31:1600x1200@60.00  32:1280x1024@60.02  33:1280x960@60.00  34:1280x720@60.00  35:1280x720@60.00  36:1280x720@59.94  37:1280x720@50.00  38:1024x768@75.03  39:1024x768@60.00  40:800x600@75.00  41:800x600@60.32  42:720x576@50.00  43:720x576@50.00  44:720x480@60.00  45:720x480@60.00  46:720x480@59.94  47:720x480@59.94  48:640x480@75.00  49:640x480@60.00  50:640x480@59.94  51:640x480@59.94  52:1600x1200@159.89  53:1280x1024@159.75  54:1024x768@159.72  55:2560x1600@59.99  56:2560x1600@159.94  57:1920x1200@59.88  58:1920x1200@159.87  59:1280x800@59.81  60:1280x800@159.78  61:3200x1800@59.96  62:3200x1800@159.98  63:2880x1620@59.96  64:2880x1620@159.95  65:1920x1080@159.88  66:1600x900@59.95  67:1600x900@159.82  68:1368x768@59.88  69:1368x768@159.86  70:1280x720@159.78 
	Geometry: 0,0 1920x1080
	Scale: 2
	Rotation: 1
	Overscan: 0
	Vrr: Automatic
	RgbRange: Automatic
	HDR: enabled
		SDR brightness: 203 nits
		SDR gamut wideness: 0%
		Peak brightness: 486 nits
		Max average brightness: 486 nits
		Min brightness: 0.0969 nits
	Wide Color Gamut: enabled
	ICC profile: none
	Color profile source: EDID
	Color power preference: prefer efficiency and performance
	Brightness control: supported, set to 100% and dimming to 100%
	DDC/CI: allowed
	Color resolution: automatic (10), range: [8; 16] bits per color
	Allow EDR: unsupported
	Sharpness control: unsupported
Output: 2 DP-2 edd03ce9-e04e-4b8a-b059-21bfc6db47aa
	enabled
	connected
	priority 2
	DisplayPort
	replication source:0
	Modes:  71:3840x2160@60.00*!  72:3840x2160@30.00  73:2560x1440@59.95  74:1920x1080@60.00  75:1920x1080@60.00  76:1920x1080@59.94  77:1600x900@60.00  78:1280x1024@60.02  79:1280x800@59.81  80:1152x864@59.97  81:1280x720@60.00  82:1280x720@60.00  83:1280x720@59.94  84:1024x768@60.00  85:800x600@60.32  86:720x480@60.00  87:720x480@59.94  88:640x480@60.00  89:640x480@59.94  90:640x480@59.94  91:1600x1200@59.87  92:2560x1600@59.99  93:1920x1200@59.88  94:3200x1800@59.96  95:2880x1620@59.96  96:1368x768@59.88 
	Geometry: 1920,0 1920x1080
	Scale: 2
	Rotation: 1
	Overscan: 0
	Vrr: Automatic
	RgbRange: Automatic
	HDR: incapable
	Wide Color Gamut: incapable
	ICC profile: /home/chris/.config/color/icc/devices/display/LGUltraHD.icc
	Color profile source: ICC
	Color power preference: prefer efficiency and performance
	Brightness control: supported, set to 50% and dimming to 100%
	DDC/CI: allowed
	Color resolution: automatic (10), range: [8; 16] bits per color
	Allow EDR: unsupported
	Sharpness control: unsupported

[kasper93]

Yeah, that does the same thing without the tonemapper as stable does with the tonemapper. Here are the stats:

This shows that compositor requests SDR signal as preferred one. You can see that in log for exact values. Either you need to enable HDR in kwin settings or there is something else going on.

[kode54]

Yes, I know. KDE 6.5 changed it so that the preferred transfer function will always be gamma 2.2.

[Zamundaaa]

This shows that compositor requests SDR signal as preferred one.

There's no SDR or HDR transfer functions, either can be done with any transfer function (assuming custom luminance values, which KWin does use).

If you need an "HDR" vs. "SDR" check, you can compare the max target luminance with the reference luminance. Ideally of course you'd just always use the luminance values without such a binary choice though.

[Headcrabed]

Can you post the log with newest version of mpv?

[kasper93]

This shows that compositor requests SDR signal as preferred one.

There's no SDR or HDR transfer functions, either can be done with any transfer function (assuming custom luminance values, which KWin does use).

That's big assumption my friend. Of course transfer function can encode various luminance ranges, but some transfers are assumed to be display referred and doesn't map to any absolute nits value when they are normalized to 0-1. Also some transfers, are better at representing high dynamic range content, hence PQ exists.

If you need an "HDR" vs. "SDR" check, you can compare the max target luminance with the reference luminance. Ideally of course you'd just always use the luminance values without such a binary choice though.

So, now all applications and games, that create VK_FORMAT_B8G8R8A8_UNORM / VK_COLOR_SPACE_SRGB_NONLINEAR_KHR swapchain are expected to renormalize their SDR output to 0-0.5 range? As you say that 0-1 is now HDR and full 0-486 brightness? And if you have 2000 nits TV, your SDR game will blast 2000 nits, if it's not updated?

Either way, it's not a big problem for us, we just need to adjust few knobs, pipeline internally is already compatible with any luminance range. Annoying part will be platform specific checks, because Vulkan on macOS and Windows will work differently.

[Zamundaaa]

some transfers are assumed to be display referred and doesn't map to any absolute nits value when they are normalized to 0-1

Images that are sent to a display (hence also to a compositor) are by definition always display referred, no matter what transfer function you use.

So, now all applications and games, that create VK_FORMAT_B8G8R8A8_UNORM / VK_COLOR_SPACE_SRGB_NONLINEAR_KHR swapchain are expected to renormalize their SDR output to 0-0.5 range? As you say that 0-1 is now HDR and full 0-486 brightness? And if you have 2000 nits TV, your SDR game will blast 2000 nits, if it's not updated?

The preferred image description in KWin is gamma22 with min and max luminance matching the display, as that's our blending space and thus the ideal representation to use when the application does color management itself.

If an app goes through Vulkan, it gets the default luminance values as defined by the Wayland protocol (for gamma22 that's max == reference == 80cd/m²) and if it uses the Wayland protocol directly, it may use custom min/max luminance values as well.

You can still use PQ for max>reference and sRGB for max<=reference, you just shouldn't unconditionally use the preferred transfer function without considering these other properties.

[kasper93]

If an app goes through Vulkan, it gets the default luminance values as defined by the Wayland protocol (for gamma22 that's max == reference == 80cd/m²)

And that's exactly what I meant, that some transfers are "SDR", we can discuss semantics, but if we use Vulkan, we shouldn't need to cross check if max==reference luminance, because there is no API for such query, it's implied.

[Zamundaaa]

You're not using Vulkan to query anything, you're using Wayland to query the preferred colorspace, so you have to take Wayland thing into account when using that information.