The Digital Canvas of Paldumais

Mastodon LinkedIn

Investigating HDR Detection Failure on Fedora KDE with an ASUS OLED Panel

Published on

After installing Fedora 44 KDE on my ASUS Vivobook S14 OLED, one of the first things I wanted to test was HDR support.

The hardware itself should not be a problem. This laptop has a high-end OLED panel:

Windows already enables HDR correctly on this machine, so I expected Fedora KDE to detect the same capabilities.

Instead, KDE reported: 

HDR: incapable
Wide Color Gamut: incapable

At first, I suspected that Fedora was not reading the display capabilities correctly. After debugging the graphics stack, I found a more interesting situation: the display reports HDR correctly, but the information is not making its way properly into KWin's HDR detection.

Checking the EDID Information

The first step was checking whether the kernel could read the display EDID. 

cat /sys/class/drm/card*-eDP-*/edid > /tmp/panel.edid

Then I decoded it: 

sudo dnf install edid-decode

edid-decode /tmp/panel.edid

The result showed that the OLED panel was correctly exposing HDR capabilities. 

Display Device Technology: Organic LED

The DisplayID extension contained: 

Supported color space and EOTF standard combination:
DCI-P3, BT.2020/SMPTE ST 2084

The HDR static metadata block was also present: 

HDR Static Metadata Data Block

Electro optical transfer functions:
SMPTE ST2084

Static metadata type 1

Brightness information was also correct: 

Native Maximum Luminance:
400 cd/m²

10% Rectangular Coverage:
616 cd/m²

Minimum Luminance:
0.0005 cd/m²

From the EDID perspective, everything looked correct.

The Problem Appears Between DRM and KWin

The next step was checking what the Linux DRM layer exposes to user space.

I installed drm_info: 

sudo dnf install drm_info

Then: 

drm_info | grep -i -A5 hdr

The important output was: 

"HDR_OUTPUT_METADATA": blob = 0

This was the interesting part.

The DRM connector exposes the HDR property, but no HDR metadata blob is currently attached.

The pipeline currently looks like this: 

OLED Panel

    |
    | EDID contains HDR10 metadata
    | ✅

AMDGPU DRM Connector

    |
    | HDR_OUTPUT_METADATA exists
    | but blob = 0
    | ⚠️

KWin

    |
    | Cannot confirm active HDR capability
    | ❌

HDR disabled

Why This Matters for Developers

From a user perspective, KDE only sees: 

HDR: incapable

But the hardware capability is clearly present.

A possible issue is that KWin currently depends too heavily on the DRM connector state instead of considering the HDR information already available through EDID/DisplayID.

Another possibility is that AMDGPU should create or expose the correct HDR metadata blob for internal eDP OLED panels when the EDID advertises HDR static metadata.

The issue appears related to KDE HDR detection behavior and is similar to the discussion tracked here:

KDE Bug 499673 - HDR detection issues

Testing a Workaround

KWin includes an experimental environment variable: 

KWIN_FORCE_ASSUME_HDR_SUPPORT=1

This bypasses normal capability detection and forces KWin to assume HDR support.

I tested it temporarily: 

export KWIN_FORCE_ASSUME_HDR_SUPPORT=1

Then restarted my KDE session.

If this changes: 

HDR: incapable

to: 

HDR: capable

then the problem is most likely detection rather than missing hardware support.

Making the Workaround Permanent

If the workaround behaves correctly, it can be added globally: 

sudo nano /etc/environment

Add: 

KWIN_FORCE_ASSUME_HDR_SUPPORT=1

Then reboot.

ICC Profile vs EDID

Another important detail: EDID and ICC profiles are not interchangeable.

The EDID describes what the display supports:

The ICC profile describes how colors should be corrected:

For this ASUS panel, the manufacturer profile is: 

M5406WA_1002_834C419D.icm

The ICC profile improves SDR accuracy, but it does not enable HDR.

Conclusion

This investigation showed that the OLED panel itself is not the problem.

The display correctly reports:

The issue appears to be somewhere in the Linux HDR pipeline between DRM/AMDGPU and KWin's HDR capability detection.

For developers investigating similar bugs, the important information is:

Hopefully this helps other users with modern OLED laptops, and hopefully it provides useful information for improving HDR support in KDE Plasma.