This is Carlos Soriano, Engineering Manager at the GPU team at Red Hat. I’m here together with Sebastian Wick, primary HDR developer at Red Hat, and Niels de Graef, GPU team Product Owner at Red Hat, to announce that we’re organizing the Display/HDR hackfest in Brno in the Czech Republic, April 24-26! The focus will be on planning and development of the technical infrastructure needed for various display technologies, specifically those that need GNOME Shell to work in tandem with the GPU stack. One of the main examples of this is HDR support, which we know you have all been waiting for!
The purpose of the hackfest is to bring together contributors from across the display/GPU stack. Attendees will include those from projects such as Freedesktop, GNOME, KDE, Mesa, Wayland and the Linux kernel. This is going to be a great opportunity to meet and collaborate on the holistic approach necessary to make these technologies work well across various vendors and projects.
The proposed length of the hackfest is 2 full days, and a third day for wrapping up during the morning and doing a local activity during the afternoon.
Now, you might be asking why are these technologies, such as HDR, important for us? And what is the plan to integrate them in Fedora? Well, let’s take HDR as a primary example, and start by explaining what HDR is.
What is HDR? – By Sebastian Wick
When most people talk about High Dynamic Range (HDR) they often refer not only to HDR but also to Wide Color Gamut (WCG). Both of these terms describe an improvement of display technologies.
The dynamic range of a display describes the ratio of the lowest luminance to the highest luminance it can produce at the same time. A high dynamic range thus means an increase in the highest luminance (colloquially called brighter whites) or a decrease of the lowest luminance (darker blacks), or both.
The color gamut of a display describes the colors it is able to reproduce. If a gamut is “wide”, it means the display is able to reproduce more chromaticities compared to a small gamut. To put it colloquially, it can show more colors.
We humans are able to perceive images which have up to a certain dynamic range and color gamut. The closer displays get to those capabilities the more immersive the resulting images are. HDR, in its broader meaning, is therefore all about being able to show more colors, and we can use HDR modes on displays to unlock their full potential.
From a technical perspective, enabling those modes and presenting content is not hard, as long as the display only has to show a single source. While this may work for some use cases, a general purpose desktop requires composition of various Standard Dynamic Range (SDR) signals, color managed SDR signals and various HDR signals to various SDR displays, color managed displays and HDR displays at the same time. You can take a look at Apple’s EDR concept if you want to see how this looks when done right.
There are no industry standards yet for this kind of composition and most HDR modes, unfortunately all the common modes, are also not designed for this use case. Instead they focus on presenting a single HDR source.
With the increase in composition complexity, offloading the composition and achieving a zero-copy direct-scanout scenario becomes much harder. But this is required to keep power consumption in check and thus improve battery life.
Wow, that sounds complex
Yeah, this all sounds more complex than someone could imagine, but we’re confident we can get there. Now, why is HDR important for us, and what is our plan for integrating it in Fedora once it is ready? Niels de Graef has been working as the primary HDR feature owner at Red Hat for a couple of months now and can help us understand that.
Why is HDR important for us, and what is our plan for integrating it in Fedora? – By Niels de Graef
By adding support for HDR, we want to be an enabler for several key groups.
On one hand, we want to support content creators who see HDR as a very interesting feature. It allows them to present their work to people the way they intend it to be seen, eliminating the effect of “washed down” colors due to the monitor only supporting a relatively small color space. For example: as an artist, you might want to specify exactly how bright the sun in a desert scene should look while making sure the rest of the scene does not degrade in detail.
As content creators go, an important stakeholder is the VFX industry, which consists of big players like Disney. Red Hat closely collaborates with the industry, which also recommends Red Hat Enterprise Linux (RHEL) as their choice of distribution. We want to make certain we get the industry’s feedback so we can incorporate it in this story and make sure we get this right from the start.
On the other hand, we want to enable Linux users. Hardware that supports HDR is becoming more commonplace and is becoming more affordable as of late. HDR is becoming more supported, and an increasing amount of content is making use of it. As long as we don’t have HDR support, Linux users will have a degraded experience compared to Windows and Mac users.
Finally, supporting HDR fits into the foundations of Fedora, where we want to do the right thing, making sure everyone is free to enjoy the latest innovations and features. This follows our move to Wayland, which, as a modern graphics stack, allows us to build new features like this.
We hope that you enjoy the work we’re doing to enable the Linux ecosystem and users to make use of the latest technologies. We’re definitely excited with what we are aiming to achieve. Thanks to everyone who is contributing to this effort, and the organization of the hackfest.
We hope to see you all in Brno in April!
FYI: Carlos, there’s a typo “Czech Replublic”
Oops. Thanks for the heads-up. Corrected.
What’s the current status of HDR?
I was curious about that as well.
Also: I know it’s a hackfest and not a conference but I wonder if the “outcome” can be shared somehow, even if it’s just code fragments.
There is comparatively little info to be found on these topics (especially for linux), well it really extends to such areas as wayland, graphics more general, vulkan (that one there is some out there in terms of code/tutorials), but overall it’s a long and hard digging for information if one wants to explore GPU stuff. But then again, perhaps I didn’t look hard enough.
Shame because I want to do more stuff, specificially Vulkan, same code works really nicely with both windows and linux (cmake).
Complicated, Cristain. Unlike audio which has all been neatly restandardized into Pipewire, display under Wayland has faced a number of arguments; the least of which has been heralded by Gnome Group’s typical bletcherous approach. (Whereas the tiny window managers have been pushing progress.)
Just beholding the baffling upgrade path of the GNU Image Manipulation Program having been held back for several years (Nearly 8 or 5, depending on how you count.) speaks volumes to the sticky bureaucracy there. People will happily branch things into the trunk, but nobody upstream is willing to mainline them for reasons which can only be described as arrogant obstinance.
It’s things like this that make me hopeful that Cosmic/ICED will completely sweep GNOME away.
Thanks, for introducing me to ICED. I wasn’t aware of a new graphics toolkit. This might actually change things for many applications if it finds wide adoption seeing as QT struggles thanks to it’s licensing.
It’s being charged by practically everyone on the Pop!OS team, so I give it good odds of potentially making waves. Wide adoption would be reliant on corporate factors, I’d wager.
But given what Cosmic/Iced has accomplished in such a short time compared to the time it took GNOME to refactor a 20 year standing issue to the point it became a running joke (the file picker), I have my hopes that Cosmic/Iced will be developer rather than dogma lead.
Qt is free software like any other. What blocks adoption of Qt is the fact you can only use it with C++ or Python, when most of the Linux ecosystem is written in plain C. Bindings to other languages for Qt either aren’t good quality, or just don’t exist.
We’re working on bidirectional Rust C++ bindings for Qt: https://github.com/KDAB/cxx-qt
GIMP being held back (assume you’re talking about their GTK3 port?) has absolutely nothing to do with GNOME at all. GIMP has suffered a significant lack of contributors for the last decade and a half. People are so obsessed with hating on GNOME, they start inventing things to be mad about.
Niels De Graef
The current status of HDR is that it’s not supported at all really. The complexity of this feature is that it needs major changes in several pieces of the Linux stack, from the kernel drivers (specifically in the drm subsystem) to userspace graphics all the way up to Wayland compositors like GNOME or KDE, and the applications that would display HDR content.
One of the reasons we specifically wanted to organise a hackfest is to make sure all those moving parts are aligned on the APIs and protocols they would use to deal with HDR as they implement it.
Obviously good news for those that need it. On a more general note will anything covered here help developers with scaling their apps for high res screens? 4K screens are fantastic but old guys like me sometimes have visual issues (text mostly) with the base gnome apps.
By the way I wish I could help but I suspect I’d be in awe at the complexity of this initiative.
Niels De Graef
Have you tried enabling the “Large Text” setting in GNOME Settings app (in the Accessibility section)? That configuration is specifically made for people who might have a hard time reading small text.
I have used Unix since 1982, on several platforms, the CDE on Sun & SGI etc…
GNOME 2 was fine, but I have tried and rejected every version of GNOME 3 as just clumsy, hard to use, often inadequate.
I have use Fedora MATE Compiz, since it inception: it just works !
I don’t hate GNOME but simpler, better desktops like MATE, XFCE, and even KDE which took so long, just work.
Will LxQt ever emerge ?
Does not Linux, need a good, not bloated clean Desktop like Linux-CDE was able to achieve, a long time ago ?
Can GNOME be saved from itself, with a serious fork ?
At some point will be the biding c++ Rust good enough so one (or more) desktop
written in Rust will emerge ?
I am not sure if this is useful, but valve works already on it, you should consider to get in touch with those guys, see Twitter post for details:
Niels De Graef
We definitely know about Valve’s effort already and made sure they got an invite too. Note that the work Valve did there is very specific to gamescope (their Wayland compositor) and can’t be reused for general HDR support on Linux unfortunately.
thank you for your response. I knew it’s for gamescope but didn’t knew it can not be reused, that’s too bad, but glad you had it on the radar. I wish you a good workshop and am already excited to hier what you all will come up with 🙂
On the topic of HDR, I’d like to raise a small flag on text clarity. Newer HDR-capable monitors are introducing new sub-pixel layouts. We now have new geometries with OLED’s WRGB layout, and the best-performing HDR monitors are even more exotic: QD-OLED with a triangular subpixel layout. Rendering text on a triangular (or WRGB) layout with the assumption that the monitor is a traditional RGB layout creates fringing, eye strain, and avoidance.
What’s the roadmap for support for this in Fedora? Getting HDR support for games or photo editing is exciting and great and all, but if one can’t look at their HDR screen for any extended period of time without health risks, I wonder if there might be different priorities when supporting HDR.
I’m really excited! I will absoluetly go there because I live in Slovakia! The neighboring country of Czech Republic!
Aside from gaming and content creation, HDR on Linux will probably be seldom used for media consumption on most “premium”/paid streaming services due to their use of digital rights management (DRM), reluctance from some service providers to provide Full HD or UHD streams to Linux clients and most Linux distribution’s inability to properly protect such content by providing a secure playback path.
Although the idea of supporting hardware-based DRM won’t fly on most Linux distributions probably won’t ever fly for somewhat obvious reasons, it’s something to note nonetheless.
Excellent! You are doing a great job! Congratulations!
This article really changed and cultivated new knowledge for geometry dash lite