Color management is not just for HDR displays. It's one of the reasons creatives always leaned toward Macs - system-wide color management has been a thing for ages there.
Wayland wasn't initially designed with it in mind because they haven't consulted their supposed userbase for their use cases, instead focusing on a narrow problem space that was understandable for them personally, and codifying their assumptions. It's basically another case of "falsehoods programmers believe about X".
This is the thing that has always confused me about the path of Wayland's development. A lot of the original designers and implementers had worked on X11 and/or GUI toolkits for years prior to starting to build Wayland, but there's so much missing (like color management has been) that it feels like all those people somehow forgot all their experience when they started working on Wayland.
I suppose it could be that their experience taught them to build something minimal and then extend things later, but I think that approach has done Wayland a lot of reputational harm over the years.
So much of X was built on bad one time hacks that never died, that ossified into place.
It's zero surprise to me that Wayland folks didn't rapidly promote the first pass at color management to official status.
Headlines like this are misleading as fuck. It elevates the consternation of those wondering "why wasn't this here already?!". But this is the hopeful 1.0 of a long road, of compositor specific tries, of countless iterations & tweaks.
The case for respecting a long hard process are vastly vastly vastly undersold. Short un-understanding quickly dominates. It's easy to say why wasn't something there? But in 20 years, it would be way worse and way harder to say "why was such a bad thing approved?". It just takes a lot of time, for incredibly open ended problems to find reasonably good satisfactory resolution, that multiple implementers will feel is a good sound protocol to work from. It isn't a desire for minimalism that drove Wayland protocols, it's a shock horror & critical terror at what the sloppy past had allowed to grow up & a recognition that what gets 1.0'ed needs to face a much higher standard than what happened in the past, needs a far higher level fo confidence & future sightedness. Don't ship slop.
Appease the user of now, or build an enduring legacy that can keep building: the early-game people will forever protest & scream about how bad the late-game builds are at doing the thing, but the late game people almost never ever get the respect & accolades for ascertaining & achieving the true long term objectives. But if they weren't there, there's such a real chance the whole enterprise might have fallen over & collapsed.
I'll invoke Cunningham's Law here. If I remember correctly, Wayland was designed to support a wider range of display targets than X11, such as set-top displays, car dashboards, and other specialized systems. In these cases, the full functionality of a traditional desktop environment isn't required, so it isn't included in the base system.
I kinda had this "wayland was actually designed for embedded use cases and [therefore lots of things don't matter]" also in the back of my mind, but I failed to find any evidence at all for this actually being the case. Nevermind that embedded Linux generally didn't use X11 back then and doesn't use Wayland today.
> I suppose it could be that their experience taught them to build something minimal and then extend things later
Without the "extend things later" part. Wayland is/was severely underspecced because the devs had a pretty big trauma from the way X11 was developed. The idea was that by keeping it very minimal they could punt everything off to the layers above Wayland, where iteration is quicker. The higher layers would also be less foundational, meaning that development there wouldn't be stuck in committee quagmire for years.
Color management in particular is very bad to have as an afterthought. You need to build everything around it conceptually, and make every part of the pipeline color-aware, propagating the metadata end-to-end and optimizing it to exclude unnecessary transformations. Microsoft recognized the problem in Vista and still struggles with it in modern Windows versions.
> I suppose it could be that their experience taught them to build something minimal and then extend things later, but I think that approach has done Wayland a lot of reputational harm over the years.
Even then, I'd expect color gamut and depth support to be a top priority, second major release, sort of feature.
...Why does the wikipedia page for Wayland say that color management was added in 2013?
>I think that approach has done Wayland a lot of reputational harm over the years.
Only if you consider Wayland to be a finished complete replacement for X11 — which distros have... oops! The reality is that in linux, the users act like developers (in the sense that they know how to fill out bug reports) so they get treated like developers and dogfooded.
From a business perspective, distros like Fedora are basically testing for RHL, no?
There are more creatives in the world than those that fit into 10% desktop market, and in the 90's, Apple had even less, in a world where Atari, Amiga and Acorn also existed.
Wayland wasn't initially designed with it in mind because they haven't consulted their supposed userbase for their use cases, instead focusing on a narrow problem space that was understandable for them personally, and codifying their assumptions. It's basically another case of "falsehoods programmers believe about X".