The latest alpha of the upcoming Blender 5.0 release comes with High Dynamic Range (HDR) support for Linux on Wayland which will, if everything works out, make it into the final Blender 5.0 release on October 1, 2025. The post on the developer forum comes with instructions on how to enable the experimental support and how to test it.
If you are using Fedora Workstation 42, which ships GNOME version 48, everything is already included to run Blender with HDR. All that is required is an HDR compatible display and graphics driver, and turning on HDR in the Display Settings.
↫ Sebastian Wick
It’s interesting to note that Blender on Windows won’t be getting HDR support, and that’s because Windows’ HDR support is subpar compared to Wayland on Linux, and requires a ton more work which the Blender team isn’t going to do. It seems the Wayland developers made all the right choices when it comes to HDR support. Needless to say, X11 doesn’t have HDR support.
The design of the Wayland color-management protocol, and the resulting active color-management paradigm of Wayland compositors was a good choice, making it easy for developers to do the right thing, while also giving them more control if they so chose.
↫ Sebastian Wick
Weird. I was told Wayland was an unusable mess.
That’s absolutely amazing. From far behind on HDR support, to well ahead. Amazing!
The various DEs do need a global “last mile” or “device output” brightness configs though for its HDR – paper white and max luminance. In bazzite at least, (and especially running game mode) there isn’t a way to adjust those default values, and apps (games) internal settings don’t seem to do much, at least not consistently.
On Windows, they actually did finally fix all their dumb unmanaged stuff, but they for some incomprehensible reason, left the feature that fixes it (treating untagged content as sRGB – a feature request I put in more than 1 decade ago) OFF by default…
I’ve been doing a lot of cross-platform UI coding lately, and Wayland has actually been one of the nicer APIs to work with. Very verbose, but you can see the purpose behind every piece and it makes a lot of sense.
In other I was right news, wayland continues to proves my point about Linux desktop being unstable, KiCad has a post about how their program’s GUI functions aren’t possible on Wayland: https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/
When it needs to be a drop in replacement, the Linux world instead decides 20 years of basic desktop functionality should be illegal, or someone else’s problem.
dark2,
From link…
Wayland devs did this on purpose because they feel that mouse and windows positions are privileged information that application developers shouldn’t have access to. In testing some applications I used for work I encountered every one of these issues as well. I happen not to like these kinds of interfaces as a personal preference, but nevertheless is does represent something wayland has been designed not to support on purpose. It’s why “xeyes” doesn’t work correctly on wayland. While it doesn’t impact me too much, I do feel sorry for KiCad and other projects that are broken. Wayland devs dictating restrictions on users and software is distasteful for FOSS and I think they deserve criticism for it.
I recently watched a video about an SDL3 developers attempt to request the ability for a program to pick a preferred monitor be built into Wayland rather than have each DE implement it their own way (or not), and wow the circular reasoning and intentional misunderstanding on behalf of the Wayland devs in the thread was bizarre.
@Drumhellar
I am probably known as a bit of a Wayland apologist and shill.
The thread on primary displays was just an absolute embarrassment. It was the very worst of “Wayland is working as designed” to justify not being able to do simple things that every windowing system needs to do. It was crazy.
I have been an apologist for Red Hat as well as I do not think they deserve the hate they get and I am thankful for all of the software I run that they wrote. But, more and more, I see Red Hat taking control of Linux as “their” platform and only caring about things that matter to them. Red Hat dominates GNOME and it is the GNOME folks that most often pull this “can you give me an example of why you need to do that” crap in Wayland. It is all part of the same, “It works for us in the way we want it to work” gatekeeping culture that Red Hat is creating.
Fullscreen display switching needs to be supported under Wayland as a standard interface, allowing each compositor to implement it differently is going to completely stuff Linux desktop adoption. Games won’t be consistent and that’s going to be a major deal breaker for anyone adopting the platform. Not to mention it stuffs live performance displays. E.g anyone trying to use Linux for Live stage shows will be forced to move back to Windows/Mac.
While I understand the logic, allowing it to be set by the user/distro/org’s security policy is how to do it, not just a blanket “no” to everyone. At some point you have to admit your weekly rubbish bin doesn’t need Fort Knox level security.
Nice to see Blender get a mention here :), I’ve on Wayland integration in Blender (not HDR though) regarding Wayland being a mess or not … I can see both sides of this argument.
At first supporting Wayland is a lot of work because it’s a lower level protocol that requires a lot of attention to all sorts of details that other API’s manage for you (you need to implement your own key repeat for e.g.).
Longer term though I’ve found it enables better integration – the cursor grabbing support in Wayland for example required a fair amount of efforts to get working however now it avoids problems present on macos/win32/x11.
The one downside that’s hard to overlook are bugs which only impact specific compositors or older versions of those compositors… supporting all these combinations can feel a bit like browser compatibility for web development in the 90’s.
While some similar issues existed with X11, things like input handling worked the same way between different desktops which isn’t always the case with wayland.
@ideasman42
> all these combinations can feel a bit like browser compatibility for web development in the 90’s.
This is an interesting comment and highlights the issue in a way I had not thought of before. That said, a few differences:
1 – Most developers are using toolkits like GTK and Qt that are going to abstract away what is under the hood for most of what they do. So, I expect it is a lot less annoying that just trying to get a web page to work in the era of Internet Explorer.
2 – It will not be long until we have a suite of a half-dozen well known environments that all work well by following the standards (and where the standards themselves have matured). We are almost there now with KDE, GNOME, Hyperland, COSMIC, and Niri for example. This will throw a spotlight on if the problem is “Wayland” or the specific compositor. The expectation will be the compositors work.
It may sound like I am putting a lot of pressure on small projects “to support all of Wayland” but the reality is that, like the app devs, most compositor writers are using a framework. If you are using Wlroots, or Louvre, or Smithay, or whatever Hyperland calls its toolkit, you are a lot of the way there already and it is a similar level of effort to building a window manager in the X days. Niri, for example, use Smithay as an example uses Smithay (same as COSMIC) for the base and then uses the GNOME version of xdg-desktop-portal to support things like screen capture. Niri did not even add Xwayland support, relying on Xwayland-satellite. The Niri dev is able to concentrate on window management.
At least, I hope all this is the case. As a user, I am quite happy with the state and direction of Wayland at the moment. But a world were being a Linux desktop dev resembles being a 90’s web dev would not be a good place.
Well … that doesn’t sound like it would reduce the layers of abstractions 😉
Wayland somehow failed at least when it comes to making things less complicated and cumbersome.
Overall everything just became a whole lot messier for Linux Desktop.
Android for Desktop will probably steal the show anyway as soon as it gets an X11 emulation.
@tanishaj
re: 1) agree with your point regarding toolkits, however inconsistency is between the compositors will still impact tool-kits.
re: 2) at 1st I had hoped this as well … and perhaps long-term this will be the case. However I think the web analogy holds in this case too – since wayland is an evolving set of protocols with room for new compositors to implement those differently and for there to be new compatibility issues.
I’m also less optimistic about composites fixing their own bugs. Since working on Wayland I ran into various issues which are reported and have not yet been resolved, some examples:
– https://github.com/hyprwm/Hyprland/issues/4478
– https://gitlab.gnome.org/GNOME/mutter/-/issues/2311
– https://gitlab.gnome.org/GNOME/mutter/-/issues/2658
– https://gitlab.gnome.org/GNOME/mutter/-/issues/3636
nevertheless as time passes I would hope the more serious issues are handled – so long term the basics (at least) should be well supported.
It’s possible I have some negative bias – as an application vendor we hear all the reports from users running into strange problems, I would hope most don’t hit these kinds of issues 🙂
Wayland isn’t “a mess”, it’s just different. It has done a lot of maturing over the past 5 years. A lot of that motivated by some distros “forcing the issue”. But, I’ll admit, there will be “fall out”, especially for long running “old things” that don’t work particularly well with Xwayland and aren’t open source. A tribute to longevity, but also a reminder of the importance of FOSS.
For the record, Nvidia did work on and propose an HDR extension for X11 and I think they had it working with opengl software using FP16. My understanding is that Xorg maintainers didn’t want to accepted changes to X11 and wanted the features to be exclusive to wayland instead, which is why X11 never got HDR support.
https://www.phoronix.com/news/X11-DeepColor-Visual-RFC
I feel like you haven’t been told this in a really long time, and like most people are actually incorrectly interpreting people’s legitimate gripes with Wayland being unable to accommodate their specific use case. Every post about Wayland has a couple people saying, “The specific thing I do doesn’t work reliably on Wayland,” followed by a score of people either willfully misinterpreting that as a claim that Wayland isn’t at all ready for general usage, or talking about all the ways Wayland is better than Xorg without ever addressing the specific issue said user complained about.
It’s also weird to write this considering that most OSnews readers seem to be onboard with Wayland.
Interesting how Thom’s source for claiming Blender won’t be getting Windows support doesn’t back up his claim at all. It’s just one developer saying he won’t work on it, but anyone else is free to pick it up. And of course, all the search engine AIs are already regurgitating his claim. Also remember when they said they wouldn’t work on an Apple Metal port because they wouldn’t spend the resources on a non-cross platform API? (Apple almost certainly came in and paid for that one to get done).
Also the actual reasoning is here, and not that it’s “a ton more work”, it’s that Windows doesn’t provide a standard API for HDR, and they don’t want to access it the same way as video games. they’ll just wait for it to be incorporated into Vulcan. https://projects.blender.org/blender/blender/pulls/133159