Red Hat's HDR Hackfest Sounds Like It Was A Success

[phoronix]

Phoronix: Red Hat's HDR Hackfest Sounds Like It Was A Success

Red Hat organized an HDR hackfest to bring together all the Linux desktop stakeholders around the desktop, display drivers, and related infrastructure for helping to make progress on High Dynamic Range (HDR) display support. The event took place last week at Red Hat's Brno office in the Czech Republic and sounds like it was quite a success...

https://www.phoronix.com/news/Red-Hat-HDR-Hackfest-Recap

[Flaburgan]

People getting together, discussing and working to make the stack more compatible and future proof. Free software at its best.

[NomadDemon]

Holy cow ! its one of best things happen this year.

HDR is broken everywhere [even windows]. maybe something will change finally

[wswartzendruber]

This is going to be fun. In the same way Dr. McCoy says, "Well this is fun," when the Enterprise-A is getting hammered by torpedoes.

I'm guessing there are two assumptions that can safely be made here:

1. They are going to output PQ instead of HLG.
2. They are going to use ITU-R specifications instead of SMPTE.

So they'll probably output BT.2100 PQ using BT.2408 guidelines for displaying sRGB inside of PQ.

Then there's the question of how to send metadata. Function calls will probably need to be implemented for players to set the current MaxCLL and maybe MaxFALL values (thereby making the PQ output HDR10). Dynamic metadata should probably be supported as well. I reckon the compositor will allow both static and dynamic metadata to be set from multiple sources, and then compile these differing (and continuously updating) values into a single set of values that may then be passed to the display, if the current display link even supports dynamic metadata.

[aufkrawall]

HDR is broken everywhere [even windows].

How is that? Seems to work just fine with mpv and somewhat recent games that use Windows instead of proprietary vendor API.

[furtadopires]

How is that? Seems to work just fine with mpv and somewhat recent games that use Windows instead of proprietary vendor API.

On windows, I was having problems with mpv losing color in full screen mode (not sure if they already fix it), also Netflix official app constantly flicking in full screen so I had to watch on the browser instead.

For games not every game just works in HDR. For example Insurgency Sandstorm I have to tweak the configuration files so the screen don't get too dark, and in Zombie Army 4 it get too bright for some reason.

So while HDR kind of works on Windows it isn't on 100% of cases, which make a standardization more than welcome in my opinion.

[stormcrow]

How is that? Seems to work just fine with mpv and somewhat recent games that use Windows instead of proprietary vendor API.

No, a couple of special cases on Linux doesn't mean it works in any practical sense. Windows's HDR support is limited and doesn't handle SDR in HDR mode very well at all. Macs are the only systems that handle HDR remotely well, including SDR in HDR displays, but even it has corner cases where things are problematic. Then there's all that "fake HDR" content out there that's really just SDR encapsulated in HDR but looks almost as bad as the washed-out way Windows does SDR on HDR. The whole thing is just one big turd even if you have a Mac with a good quality display because something is going to come along and force you to turn off HDR. On Windows you might as well just leave it off till you know something is actually in HDR format. And Linux... pfeh.

Maybe some good will come of the meeting, but it'll be years before it trickles down to distros and probably will result in more bickering between Intel, AMD, and Nvidia.

[emblemparade]

How is that? Seems to work just fine with mpv and somewhat recent games that use Windows instead of proprietary vendor API.

You must have low standards. Yes, it can work, and actually we can achieve similar results to Windows in Linux right now. But we want much more. We want to reach a point in which HDR support is transparent and automatic. Have every app render as per its ability, to the limits of hardware capability, without users having to switch modes in their desktops and in hardware. It's absurd that you have to turn off HDR (hardware and/or software!) to support legacy SDR properly. Compare to having to turn your resolution down to 1080p from 4K in order to get apps working properly. Sure, you can do that and it "works", but we can do much better.

[Quackdoc]

This is going to be fun. In the same way Dr. McCoy says, "Well this is fun," when the Enterprise-A is getting hammered by torpedoes.

I'm guessing there are two assumptions that can safely be made here:

1. They are going to output PQ instead of HLG.
2. They are going to use ITU-R specifications instead of SMPTE.

So they'll probably output BT.2100 PQ using BT.2408 guidelines for displaying sRGB inside of PQ.

Then there's the question of how to send metadata. Function calls will probably need to be implemented for players to set the current MaxCLL and maybe MaxFALL values (thereby making the PQ output HDR10). Dynamic metadata should probably be supported as well. I reckon the compositor will allow both static and dynamic metadata to be set from multiple sources, and then compile these differing (and continuously updating) values into a single set of values that may then be passed to the display, if the current display link even supports dynamic metadata.

Im not sure the assumptions will be accurate. ideally a compositor should be able to output whatever based on it's needs, PQ should be the common middle ground though. you can reliably map HLG to PQ iirc, as well as converting dovi into pq compatible streams (though this has been fairly jank when done with libplacebo). but if there is only HLG content on screen, the compositor should be able to output that.

as for displaying srgb inside of pq, this is more complicated, I find the current recommendations to be very lacking when it comes to consumers. I think it will be up to the compositor to implement normalization. I could see them doing bt.2446a inverse mapping and then doing normalization on top of that. I find this gives the best results myself.

this ties into MaxCLL and MaxFALL. these should simply be in the wayland protocol. I *think* dynamic data currently works with amdvlk? I believe I heard someone mention it on a forum or irc. in the end, I think a lot of it will be up to the compositor to implement, im just hoping compositors give us the flexibility to customize it.

[aufkrawall]

Windows's HDR support is limited and doesn't handle SDR in HDR mode very well at all.

SDR content in Windows HDR mode with Windows handling gamut mapping looks exactly the same as in SDR mode with gamut mapping handled by display on OLED. Opinions telling otherwise are wrong. And non self-emissive display types are nonsensical for HDR anyway. It "just works" for people with OLED when games/applications properly support it. Sorry if this doesn't fit your sense of reality in which Windows always sucks...