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.
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.