Hello everyone,
I’m trying to get HDR working on my ASUS Vivobook S14 OLED under Fedora 44 KDE Plasma (6.7.3), but I’m running out of ideas. I have spent quite a bit of time checking the entire display stack, and it looks like the hardware and kernel expose everything needed for HDR, but Plasma/KWin never actually enables HDR.
I am aware of KDE Bug 499673 regarding HDR detection issues, so I’m wondering if this is related or if there is something specific missing in my setup.
Small disclaimer: I used AI to help structure this post because I wanted to organize all the technical information and logs properly. The hardware details, commands, outputs, tests, and observations are mine. I’m not trying to pretend I know more than I do; I just wanted to make the information easier to follow for anyone willing to help.
Hardware
Laptop:
- ASUS Vivobook S14 OLED M5406WA
- Ryzen AI 9 365 (Strix Point)
- Radeon 880M integrated GPU
- AMDGPU driver
- Internal eDP OLED panel
Display panel:
- Samsung Display
- Model: ATNA40CU09-0
- 14-inch OLED
- 2880×1800
- 120 Hz
- VRR capable
Software stack
- Fedora 44 KDE
- KDE Plasma: 6.7.3
- KDE Frameworks: 6.28
- Qt: 6.11.1
- Wayland session
- Kernel: Linux 7.1.4
- Mesa: 26.1.4
- amdgpu driver
DRM/KMS information
The internal eDP connector reports:
Type: eDP
Status: connected
Modes:
2880x1800@120.00 preferred
2880x1800@60.00
Properties:
"max bpc": range [8,16] = 16
"Colorspace":
Default
BT709_YCC
opRGB
BT2020_RGB
BT2020_YCC
"HDR_OUTPUT_METADATA": blob = 0
"vrr_capable": 1
"panel_type": OLED
The HDR metadata blob remains:
HDR_OUTPUT_METADATA: blob = 0
which appears to mean that no HDR metadata is currently being committed through DRM/KMS.
EDID / DisplayID analysis
I decoded the EDID:
edid-decode /sys/class/drm/card1-eDP-1/edid
The panel does not expose HDR through a traditional CTA-861 extension, but instead uses a DisplayID 2.0 extension.
Important information:
Display Device Technology: Organic LED
Native Color Depth: 12 bpc
Native Maximum Luminance:
Full Coverage: 400 cd/m²
10% Window: 616 cd/m²
Native Minimum Luminance:
0.000500 cd/m²
Display interface capabilities:
Supported color space and EOTF standard combination:
DCI-P3
BT.2020 / SMPTE ST 2084
HDR metadata:
HDR Static Metadata Data Block
Electro optical transfer functions:
Traditional gamma - SDR luminance range
SMPTE ST2084
Supported static metadata descriptors:
Static metadata type 1
Desired content max luminance:
616.884 cd/m²
Desired content max frame-average luminance:
400 cd/m²
Desired content min luminance:
0.000 cd/m²
AMD DisplayID vendor block:
Vendor-Specific Data Block (AMD)
Version: 3
Minimum Refresh Rate:
48 Hz
Maximum Refresh Rate:
120 Hz
Maximum luminance:
616.884 cd/m²
Additional DRM color pipeline information
The AMD display engine exposes:
CURVE_1D_TYPE:
sRGB EOTF
PQ 125 EOTF
BT.2020 Inverse OETF
sRGB Inverse EOTF
PQ 125 Inverse EOTF
BT.2020 OETF
So the GPU/display pipeline appears to support the required HDR transfer functions.
Current behavior
- SDR works perfectly.
- 120 Hz works.
- VRR appears available.
- Wide gamut information is exposed.
- HDR metadata capability exists.
- EDID contains HDR10 information.
However:
- KDE System Settings does not show an HDR option.
- HDR mode never activates.
HDR_OUTPUT_METADATAstays at blob = 0.- No HDR metadata is sent to the panel.
Questions
Could this be related to KDE Bug 499673 (HDR detection issues)?
Does KWin currently detect HDR capabilities correctly from DisplayID 2.0 HDR blocks on internal eDP panels?
Is there a missing KWin configuration option, environment variable, or debug switch I should enable?
Could this be related to AMDGPU’s handling of HDR metadata on laptop OLED panels?
Would logs from:
kwin_wayland --verbose
journalctl -b | grep -i kwin
journalctl -b | grep -i hdr
drm_info
modetest
help diagnose this?
I am happy to test patches or provide additional debugging information.
Thanks to anyone who can help. I feel like the hardware side is already proven, so I’m mainly trying to find where the HDR capability detection/activation path is breaking.
Previous workaround / regression information
I also want to mention something important.
On KDE Plasma 6.6.6, I was able to force HDR detection by adding:
KWIN_FORCE_ASSUME_HDR_SUPPORT=1
to:
/etc/environment
then rebooting.
With this workaround on Plasma 6.6.6:
- HDR mode activated correctly.
- The OLED switched into HDR mode.
- HDR content worked.
- The behavior was basically what I expected.
On Plasma 6.7.3, the same workaround no longer behaves the same way.
Adding:
KWIN_FORCE_ASSUME_HDR_SUPPORT=1
still forces some HDR behavior, but HDR does not work correctly anymore.
- HDR would activate.
- The display would immediately go to maximum HDR brightness.
- I could not properly calibrate the HDR luminance behavior.
- The HDR brightness mapping seemed wrong.
This makes me wonder if there was a regression/change in KWin HDR handling between:
- KDE Plasma 6.6.6 → 6.7.3
or if newer KWin versions require more complete HDR metadata detection instead of only forcing the capability flag.
Since forcing HDR worked before, I suspect the issue is not the AMDGPU driver or the panel itself, but somewhere in the KWin HDR detection, metadata handling, or calibration pipeline.