Red Hat's Display/HDR Hackfest Scheduled For April

[phoronix]

Phoronix: Red Hat's Display/HDR Hackfest Scheduled For April

As mentioned a few weeks back, Red Hat has been working to arrange a developer "hackfest" to further work out plans and development around HDR display support on the Linux desktop. They are aiming to bring together graphics driver developers, desktop developers, and other Linux stakeholders -- including possibly the likes of Valve -- to work out planning of high dynamic range monitor support over the next year or two for the Linux desktop. That Red Hat HDR hackfest has now been organized to happen in late April...

https://www.phoronix.com/news/Red-Hat-HDR-April-2023

[Danny3]

Cool, but I hoped it would've been this month or lately in march.
The later they talk about, the later they start working on it.

[stompcrash]

Is there any documentation that describes how this HDR stuff works? I imagine it is not as simple as with SDR where you simply specify how much red, green, and blue you want in a color. Probably you can't even say you want a specific pixel as bright as possible, and the next pixel over is black.

[Rauros]

From, https://wiki.gnome.org/Hackfests/ShellDisplayNext2023,

Direct scanout on non-compositing GPUs - Leads: Michel, Jonas

• NVIDIA Advanced Optimus equivalency

I hope this one moves forward. Linux, compared to Windows is terrible when it comes to Optimus and Advanced Optimus stuff.

[furtadopires]

The hope is to bring together all relevant parties from hardware vendors and driver developers as well as GNOME developers and those working on other levels of the stack

How long between this reunion and the first accusations of Gnome/Redhat "developing a pattern that only benefits them (gnome) and not listening to others"?

[fitzie]

Is there any documentation that describes how this HDR stuff works? I imagine it is not as simple as with SDR where you simply specify how much red, green, and blue you want in a color. Probably you can't even say you want a specific pixel as bright as possible, and the next pixel over is black.

when you specify in SDR how much red/green/blue you want, those are already brightness levels. the problem is about matching brightness levels of mixed SDR/HDR content with the capabilities of the display and what looks good. HDR adds profiles so that there is more context of what those color settings were really meant to represent. like full white was supposed to be 1000 nits, etc.

that's at least my understanding. not an expert.

[TheLexMachine]

when you specify in SDR how much red/green/blue you want, those are already brightness levels. the problem is about matching brightness levels of mixed SDR/HDR content with the capabilities of the display and what looks good. HDR adds profiles so that there is more context of what those color settings were really meant to represent. like full white was supposed to be 1000 nits, etc.

that's at least my understanding. not an expert.

There is a new HDMI/DisplayPort software feature (Source-Based Tone Mapping) that lets any HDR-capable display tell the GPU it's HDR capabilities and functions, so that the GPU can tune it's output accordingly, for HDR, SDR, or a mixture of both.

[luno]

Is there any documentation that describes how this HDR stuff works? I imagine it is not as simple as with SDR where you simply specify how much red, green, and blue you want in a color. Probably you can't even say you want a specific pixel as bright as possible, and the next pixel over is black.

https://www.youtube.com/watch?v=nDnbWaIMJJA I learned a lot about HDR froṁ this talk

[ALRBP]

How long between this reunion and the first accusations of Gnome/Redhat "developing a pattern that only benefits them (gnome) and not listening to others"?

It would not be a problem if GNOME was a good DE

[joshx1]

i was actually looking into colour profiles yesterday in Wayland, which led into involved HDR as well.

The protocol discussions have been interesting. There has been a bunch of activity in the past couple of months.

https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/124

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2356

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14

And then there is this https://gitlab.freedesktop.org/wayla...s/-/issues/130