Or stick to a LTS based distro, like *Ubuntu 20.04 
There are multiple aspects to take into account:
- Xorg is not actively developped anymore; the only this that get regular commits it mostly the XWayland part (Fedora is changing the packaging of that for the next release).
- Ubuntu, like Fedora has already done, defaults to Wayland. It does not mean that Xorg is not available anymore. It just means that on a default installation, and with the default desktop environment, it will start a wayland session. But it’s just a switch to do in the login screen to get an Xorg managed session
- Color management is not used by everyone, and so proabably not that problematic for a lot of people.
- If you want people to start moving and acting to a new system, you have to set it as a default, to start getting more feedback ,bug reports and make it evolve
2 Likes
I agree with all of that, but AFAIK, the proprietary nVidia driver does not work well with Wayland, and the open nvidia driver does not work with openCL. So, many of us are stuck with continuing to use X.
1 Like
That’s my understanding too.
But I’ve never had to do anything. I guess X is still the default on Fedora?
I run Fedora on one of my hosts, and I thought it now defaulted to Wayland. I’ll try to check…
And, Wayland is the default for Gnome, but X is default for KDE. KDE plans to change to Wayland default in the next release (Fedora 34).
1 Like
In fact Wayland on Nvidia EGLStream is already possible since Fedora 29, but not activated by default.
And there are development in progress both on the NVidia and Xorg/Waylang side to get this sorted out. See for example that news from Phornix
1 Like
Or people abandon it and move to systems that do have capabilities expected of contemporary display systems, such as color management.
11 Likes
Hello,
maybe someone could be interested:
https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-Hiring-For-Linux-HDR
1 Like
some progress Wayland's Weston 10 Alpha Brings Early Color Management Work, More Zero-Copy Scanout - Phoronix
4 Likes
Now that I found this thread I have a question. When people say “Wayland does not have proper color management”, what does that mean?
Currently I’m using Gnome with Xorg on Manjaro, I have calibrated my screen display with DisplayCal and a Spyder3 but the correction was minimal (yay Dell!). If I were to switch to Wayland at some point (for instance when I have to reinstall my system, i’ve had it for three years now), what specific problems will I have?
Will there be no correction at all when setting a profile?
Will the global gamma correction work, but color managed applications will not use the profile?
Will all the colors just be visibly wrong? Invisibly wrong?
Will there be error messages in for example darktable? Any indication that things may not be working as I think they are?
The final scenario (things being wrong but no way to know it) is very scary so if that is the case, why are there not big red warning labels on every Wayland package?
For my software, I got about 10 minutes into reading about how OSs do color management and just stopped. As a result, I do all the color management in my software, and assume the OS is just blatting that to the raw display, and it works fine in both Ubuntu and Windows.
Wayland posed a unique problem, though. Now this may be a bit dated, but when I implemented my dynamic display switching (display transform is switched and re-calculated when I move the window from one display to another), it suddenly stopped working on Ubuntu one day. Took me a bit to correlate that with the recent OS upgrade, which switched my default rendering library from X11 to Wayland. Turns out, Wayland version at the time didn’t provide a notification event/API to detect display switching… 
To be fair, it’s a challenging interface to design; if you want the OS to do more, the image software needs to provide more information to support. A lot of software is left in the lurch at that…
2 Likes
As things stand (and to be fair, I’m not tracking any recent changes, but I’d be surprised if there’s been any change in basic direction):
No way to calibrate (barring perhaps particular hacks that allow calibration curves on the main display - see Richard Hughes changes to allow colord to do something), since Wayland doesn’t believe in application software having access to the hardware.
No (easy) way for applications to know which display they are rendering to, so no way of applying the appropriate color conversion
- or -
a hacked up color management where the application source color space has to be transformed into some compromise RGB intermediate space that Wayland then color transforms onto the actual display.
No way to perform calibration or profiling, since Wayland doesn’t believe in application software having access to the hardware or display configuration.
My thoughts (from the view of someone who has a reasonable understanding of color management with regard to both color management tools and how applications use color management, as well as a grasp of how color management works on X11, OS X and MSWindows), on how color management could be incorporated in Wayland without burning it to the ground and starting again, are here.
AFAIK the basic issue is one of philosophy and resulting structure - the bright idea for Wayland and the big difference from X11 was to isolate the rendering code from frame buffer details, so that the application can do rendering without having to worry about where the pixels were going. This is a workable idea for many situations, but makes some assumptions that are simply wrong in the modern world. In the modern world RGB values are not interchangeable, since modern displays have different resolutions, different dynamic ranges, and different color spaces, so the rendering has to be specific to these details. You can then go down the path of imagining that the application can render to some intermediate frame buffer space and have Wayland re-render to the actual display, but it’s a can of worms - the result is far from perfect and will have many visual warts, since there will be noticable fidelity loss in such a process. Bottom line is that maximum fidelity display requires rendering to the display details. The thing that a modern display architecture can bring, is to make this process as easy as possible, and make it so that the vast majority of non-critical applications can get good results on the full range of displays without having to do anything at all. A display architecture that makes no provision for how it is going to be configured (i.e. profiled and calibrated) is seriously incomplete, and woefully behind existing systems. The configuration issue also seems to be a design philosophy problem - Wayland is not intended to be a complete graphics system, just part of one. Leaving significant parts “out of scope” is not a viable approach to enabling application development. Arriving at a situation where one of the most niche desktop environments (Wayland on Linux) has 6 different ways of configuring (or being unable to configure!) the display system and expecting CM applications to cater to all of them, is delusional.
8 Likes
Thanks for the summary, quite informative. Just a clarification:
I assume this is because you would be forced to render to a low-bit integer buffer, or am I wrong? If I am, can you elaborate? Thanks!
Have a think about the process of rendering.
Resolution: If you don’t know the DPI, should you render to a high resolution and assume that the display system (Wayland) will down sample to the actual resolution, since that will give the highest fidelity ? But given that there are some quite high res. displays out there now, what resolution is sufficient ? But rendering to a high resolution when you only have a medium or low resolution display is a huge waste of CPU/GPU power and display memory. And what about font hinting ? Rendering at high res, and down sampling throws away any advantage of font hinting for lower resolution displays.
(I don’t think Wayland is taking the approach - instead they’ve punctured their isolation between rendering and display to allow the renderer to aware of the display boundaries and DPI. Being an after thought, the mechanism is a bit ugly though. This at least is a win for other aspects of rendering that need to know which display they are on.)
Dynamic range: Do you render assuming HDR and assume that the display system will clip to maximum brightness ? But many HDR sources have hints and other information that may inform such a process, and allow it to be done in a much higher quality way, such as compressing highlights while maintaining color values (simply per channel clipping can result in very ugly wrong color blocks of pixels). What about non-HDR mapping source - what brightness should that be rendered to if you are rending as HDR in the assumption that the display process will clip it if the output is non HDR ? Too high and range will be clipped. Too low and the output may be too dim.
Color: What intermediate color space is chosen to render to ? If it’s big, then the display system will have to clip colors that lie outside the display space, causing color posterization, and even resulting in false colors if it takes a per component clipping approach. If it was to compress the out of gamut colors, then it risks unnecessarily desaturating colors that are within the gamut of the display. If the intermediate colorspace is small, then the full gamut of the display can’t ever be used. You simply can’t create an optimal gamut mapping from one color space to another without simultaneously knowing both color spaces.
4 Likes
I believe Red Hat recently made a hire to work on this.
Alright, thanks for the lecture! (And I mean seriously, no sarcasm 
I was naively assuming that you had some kind of basic info about the target, but certainly I didn’t think this through…
1 Like
Hello Everyone,
with the new ubuntu version 22.04 out supporting Wayland on basically all nvidia cards this topic becomes more interesting for many users here, I assume. Can someone with a good understanding update / summarize the possibilities to calibrate a monitor / use color management in Wayland?
2 Likes
I am occasionally following progress. Color management support is still not ready. There’s been steady, albeit slow work on it. If you want to track progress there’s this roadmap for the weston (reference) implementation: CM&HDR implementation roadmap (#467) · Issues · wayland / weston · GitLab And the protocol: WIP: unstable: add color management protocol (!14) · Merge requests · wayland / wayland-protocols
2 Likes
Couldn’t we simplify this if we used sort of a identity XYZ colorspace with floating precision (for HDR exposition information)? Given a source colorspace (whatever the compositor/app tells it is delivering) and given a destiny colorspace (what we want to see) and a display profile, couldn’t we do all sort of transformations?