Why does it matter that it is merged into an extension that will become core, or it was already core at inception?

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.

> Why does it matter that it is merged into an extension that will become core, or it was already core at inception?

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

I am not knowledgeable enough on the topic, but as far as I know X didn’t have a wide-spread way to manage colors either — so I guess clients like that would default to “don’t care about it”, which will translate to some default color space.

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.

> as far as I know X didn’t have a wide-spread way to manage colors either

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.

I tried looking at how is it done in Apple’s Quartz compositor but couldn’t find it.

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.

> But more asking than telling, why wouldn’t defaulting to sRGB for unlabeled buffers work?

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?

I don’t think it has any implicit color space in use right now, I mentioned/asked for confirmation whether this approach could work.

Yeah it's the best approach given the current state, and that seems to be what they're going for in the MR.

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.