5 ms·

You think that color management belongs in the window manager / compositor. Wayland thinks color management belongs in the app. The main difference, though, i

You think that color management belongs in the window manager / compositor. 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.

magicalhippo 5y ago
My point is, regardless of who does what when it comes to color management Wayland simply cannot be agnostic about it. 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-color-management-and.html https://ppaalanen.blogspot.com/2020/11/developing-wayland-co... [2]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
- kaba0 5y ago
  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.
  - magicalhippo 5y ago
    > 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#L130 https://github.com/emersion/hello-wayland/blob/master/main.c...
    - kaba0 5y ago
      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.
      - magicalhippo 5y ago
        > 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.
        kaba0 5y ago
        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.

magicalhippo 5y ago

My point is, regardless of who does what when it comes to color management Wayland simply cannot be agnostic about it. 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-color-management-and.html https://ppaalanen.blogspot.com/2020/11/developing-wayland-co... [2]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...

kaba0 5y ago
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.
- magicalhippo 5y ago
  > 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#L130 https://github.com/emersion/hello-wayland/blob/master/main.c...
  - kaba0 5y ago
    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.
    - magicalhippo 5y ago
      > 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.
      - kaba0 5y ago
        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.