Not sure about the current state but there was some initiative to implement it. And as far as I know, the deliberately lean protocol will easily allow for this extension, that’s the cool part of Wayland.

Having a bunch of pixels with no knowledge of which color space they're in is useless.

Wayland thinks color management belongs in the app.

The main difference, though, is not this disagreement, but your righteous insistence that your opinion is not an opinion but a very simple obvious fact. I can tell you from having been part of many dev teams of many major app having to do color management that such apps really, really like to be in control.

So no, the lack of color management in wayland is not such an obvious wrong decision. It's debatable, with pros and cons.

At least since it wants to touch pixel data. Alternatively they could have given up on that and never introduced wl_buffer, leaving all the buffer management and drawing up to the client.

edit: At least HDR has finally made Wayland devs wake up and smell the coffee. A good write-up here[1], with ongoing talk in the merge request[2].

Lots of good work going on there, but should be part of core and not an extension. Maybe it's time for Wayland2 soon?

[1]: https://ppaalanen.blogspot.com/2020/11/developing-wayland-co...

[2]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...

It is hard to get everything right at once, so starting small is not bad, imo. Wayland has a really sane way of extension querying so it is not like clients will suffer due to these — they are already written in a way to query the capabilities.

> Wayland has a really sane way of extension querying so it is not like clients will suffer due to these

A client shouldn't be able to use Wayland without considering the color space of the pixels it's providing. By not having it in core from day one, there's already apps out there which will need patching to work properly.

Here's[1] a random Wayland hello world example I found. It memcpy's the image it wants to display into a wl_buffer. What color space is that pixel data in? How can this work correctly without changes when the Wayland color management protocol lands?

[1]: https://github.com/emersion/hello-wayland/blob/master/main.c...

Clients that query for this yet theoretical only color space extension can then ask the server for the color balance of the given screen and fill their buffers accordingly. The existing buffer protocol could also be extended to contain information about the color space used for server-side handling of this information, though as the other commenter mentioned, it is best handled by the client, the protocol has to display it only.

On the other hand X was created ages ago. Wayland was released in 2008.

> Clients that query for this yet theoretical only color space extension can then ask the server for the color balance of the given screen and fill their buffers accordingly.

Ok, lets say that's how it's done. I set my display to AdobeRGB or BT.2020. My legacy hello world application knows nothing of this just copies its data into the buffer blissfully ignorant of this. If Wayland does nothing more than to display the pixels, the hello world image will look like crap.

Ok, let's say we patch the hello world application, and all the other existing Wayland applications, to respect the output color space. Now I plug in a second monitor which is sRGB, and drag the hello world application over on it. If the hello world application does nothing more, it looks like crap again.

For this to work, it has to be notified it's on a new screen, and fill in new pixel values for the new screen. And every application must handle this or it will look like crap.

But more asking than telling, why wouldn’t defaulting to sRGB for unlabeled buffers work? The compositor knows that this monitor is in C color space, and it knows how to convert between the two, than a simple shader can trivially convert the sRGB hello world app to the monitor’s color space - even in the multiple monitor with different spaces case.

Of course that might not be the intention of the client, but if they didn’t bother with it than they likely are okay with whatever is the default.

If Wayland is to do color management, that's a reasonable approach. Doesn't work at all if the client is supposed to do it.

But are you sure Wayland uses sRGB now? I couldn't find any information regarding the implicit color space currently used by Wayland...

> but if they didn’t bother with it than they likely are okay with whatever is the default

Not like they had a choice now is it?

However you're still in a bit of a mess due to lack of an explicitly documented implicit color space. And it's still a bit of a footgun for developers who don't know they need to care about this.

It's a bit like XML files without the encoding attribute. Except for text you can try to analyze the bytes and find a likely encoding, no such thing for pixel data.

That's a strange way to look at it. It's more like the Wayland folks decided that basically everything of import is out of scope of the protocol. This way any graphical system built on top of Wayland is ridiculously inelegant, but hey, at least there is no responsibility on Wayland itself.

I remember that episode... at some point it was basically impossible to display an image that uses the exact same color as some color used in your CSS. Lot's of logos with just the wrong. I'm sure the web platform could be extended to properly support color management in some way, but what Firefox did back than wasn't it.