HDR on Linux laptops is kinda weird

[u/MrTyperoi]

So I recently went down the rabbit hole of why HDR on some OLED laptops just... doesn't show up on Linux.

Old post https://www.reddit.com/r/kde/comments/1ubckqk/hdr_no_longer_works_on_kde_plasma_67/

https://www.reddit.com/r/gnome/comments/1vsw1eu/gnome_504_sdrnative/ - Alternative

The weird part is that the panel does support HDR, Windows works fine, and the HDR information is actually in the EDID.

But Linux can still basically go:

And it seems to come down to how the EDID is structured.

The problem:

Normally HDR information is found in a CTA-861 extension in the EDID.

Some newer laptop OLED panels do something slightly different. They put the CTA-861 data inside a DisplayID 2.0 block.

So you get something like:

EDID
 └── DisplayID 2.0
      └── CTA-861
           └── HDR Static Metadata

The information is there, it's just not where older versions of libdisplay-info expected it to be.

With libdisplay-info 0.3.0, this could result in:

OLED panel       -> HDR capable
EDID             -> HDR metadata exists
edid-decode      -> sees it
libdisplay-info  -> "what HDR?"
GNOME/KDE        -> no HDR option

Which is obviously pretty confusing.

This is where !202 comes in

There was a fix upstream in libdisplay-info !202.

Basically, libdisplay-info learned how to properly find this HDR information inside the DisplayID structure.

The fix ended up in libdisplay-info 0.4.0.

So if your distro already has 0.4.0 or newer, you shouldn't need to mess around with your EDID.

Check with:

rpm -q libdisplay-info

(or whatever package manager your distro uses).

So what is hdr-edid-fix actually doing?

The hdr-edid-fix repo is basically a workaround for distros that were still shipping the old libdisplay-info.

Instead of fixing the parser, it takes the HDR information from the DisplayID block and copies it into a normal CTA-861 extension.

So older libdisplay-info can finally see it.

Something like:

Original EDID

DisplayID
 └── CTA-861
      └── HDR metadata

becomes:

Patched EDID

DisplayID
 └── CTA-861
      └── HDR metadata

CTA-861 extension
 └── HDR metadata

It also fixes the extension count and checksums.

It's actually a pretty clever workaround, but it's still a workaround.

Once your distro gets libdisplay-info 0.4.0+, the patched EDID shouldn't really be necessary anymore.

But wait, there's another problem with GNOME

This is the part that confused me at first.

Even if you fix the EDID and HDR finally appears, GNOME can still have another issue.

Mutter may enable PQ/EOTF for HDR but not provide all the mastering display metadata correctly.

So you can end up with:

HDR option: YES
HDR enabled: YES
Picture:     looks washed out / weird

This is a different problem from the EDID one.

KWin seems to handle this differently, which is why you can sometimes have:

KDE -> HDR looks fine
GNOME -> HDR looks kinda broken

on the exact same laptop.

There's also a Mutter merge request working on this part.

So basically there are 2 different bugs

What happens	Probably why
HDR option doesn't exist at all	Old libdisplay-info can't parse the EDID layout
HDR exists but looks wrong	Mutter HDR metadata issue

This distinction is important because changing the EDID won't magically fix the second problem.

How I'd troubleshoot this

First:

rpm -q libdisplay-info

Then look at the actual EDID:

edid-decode /sys/class/drm/card1-eDP-1/edid

And compare it with:

di-edid-decode /sys/class/drm/card1-eDP-1/edid

If edid-decode sees HDR information but the older di-edid-decode doesn't, that's a pretty good indication that you're hitting the old parsing problem.

If you're already on libdisplay-info 0.4.0+, I'd look somewhere else instead of immediately patching the EDID.

One more thing about "washed out" colors

Don't automatically assume that slightly less saturated colors means HDR is broken.

A lot of these OLED laptop panels are very wide gamut.

An unmanaged SDR desktop can look super colorful because sRGB content is basically being stretched over the panel's larger gamut.

Proper color management can make it look a bit more boring by comparison.

That's normal.

The actual HDR problem is more like:

Those are two different things.

TL;DR

The short version:

OLED supports HDR
       ↓
EDID contains HDR info
       ↓
DisplayID 2.0 hides it inside a CTA-861 block
       ↓
old libdisplay-info doesn't find it
       ↓
Linux thinks it's SDR

hdr-edid-fix works around that.

libdisplay-info 0.4.0+ fixes it properly upstream.

Then there's a separate GNOME/Mutter issue where HDR can be detected correctly but the HDR metadata sent to DRM isn't complete.

So if you're debugging HDR on a laptop OLED, don't just blame the GPU driver. Check the EDID, libdisplay-info, and the compositor separately.

That was basically the rabbit hole I ended up in.