Wayland Color Management Protocol Might Be Close to Merging
phoronix.com
phoronix.com
In another way it's pretty weird that Wayland, designed in the late 2000s, made no provisions for something other than 8-bit and "presume sRGB".
Arguably, this should have been added from the start. On the other hand, HDR displays were basically non-existent in 2000-s. It's unlikely that developers could have gotten everything right without ever testing the protocols.
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".
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.
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?
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?
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.
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.
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.
Not to mention, Mac OS X supported color management (and exporting color profiles) since its first public release in 2001. Even today, it's trivial on a Mac to e.g. connect a monitor and export its color profile into an ICC file, which can then embed into a QuickTime container, PNG image, etc.
> Even today, it's trivial on a Mac to e.g. connect a monitor and export its color profile into an ICC file
And you can use the ICC profiles in Wayland: https://wiki.archlinux.org/title/ICC_profiles#Wayland This capability has existed for a long time.
The protocols being merged allow _each_ _application_ to work within its own color profile, including more-than-8-bit colors, exposing this information to the composer. The composer can then dynamically translate the color formats, according to the output capabilities.
So if you move a window from an HDR-capable external screen to a laptop's crappy LCD, you'll get reasonable image, instead of a black window (or a washed out image).
The colors on the screen will look more like on a photo print. In addition, if your monitor supports more than 8 bits per pixel color information, then you'll be able to see more vibrant colors.
(Note that W and Wayland are wholly unrelated)
The implementation is slightly different to make things work better as both older decisions are cleaned up and newer features like per-monitor HDR pipelines are made more approachable.
might. Call us when it is.