9 ms·

I've been using Wayland (on Fedora) for a while, and it's been fine. No crashes, no weird performance problems. I wouldn't even know it's not X... ... EXCEPT T

I've been using Wayland (on Fedora) for a while, and it's been fine. No crashes, no weird performance problems. I wouldn't even know it's not X... ... EXCEPT THAT it doesn't support color management (or at least, Chrome doesn't support it under Wayland, I'm never clear where exactly the problem lies), so my wide color gamut monitor goes fluorescent in Wayland, while staying properly subdued in X. There, I've now fulfilled the contractual obligation to gripe about Wayland in every post about it.

orbital-decay 3y ago
Every time I want to try it I see complaints about color management, and it raises all red flags I have with me. Is it really true? How can something so basic and vital be neglected?
- nsajko 3y ago
  Yeah, it's crazy how Wayland is being pushed as a replacement for X.
  - andrewaylett 3y ago
    The people who wrote and worked on X for many years decided to write and work on Wayland instead. No-one's forcing you to switch, but conversely no-one's forcing the folk who used to work on X development to keep doing that. I did see one of the long-standing developers wondering whether it would have been better-received if they'd called it X12 :P.
  - djbusby 3y ago
    Well, X is definitely showing its age and some week-spots. I think we need something. And given how huge X is - in both features and users - it's gonna be really hard. And, it seems only Wayland is making any progress - even if slow. The other options are slower or non-existent.
    - nsajko 3y ago
      X is suboptimal, but Wayland is way worse.
  - Jasper_ 3y ago
    X is not color-managed either.
    - mkozlows 3y ago
      I promise you that color management works in X, at least with Chrome.
      - Jasper_ 3y ago
        X is color-managed to the same degree that it is in Wayland. That is, all buffers are sRGB, and the application needs to convert output buffers in sRGB format. Chrome certainly takes great care to do color management of the content displayed in the window, but again, it is limited to sRGB output. This is the same in Wayland and X. Color management needs improvement across the kernel & drivers, the compositors, and the applications. For more details on implementing color management, see Henry Wentland's 2022 XDC talk about implementing HDR (a feature that requires robust color management up and down the stack). You might notice that it primarily focuses on Wayland. [0] https://www.youtube.com/watch?v=nDnbWaIMJJA https://www.youtube.com/watch?v=nDnbWaIMJJA
        mkozlows 3y ago
        Okay, my situation is that I have a monitor that displays a larger than RGB color gamut. When I set an ICC profile for my monitor in GNOME, and go to a page that should be in an sRGB color gamut in Chrome in X, it displays it as it should look. In Wayland, it displays it in my monitor's native (wider than sRGB) gamut. Similarly, if I go to this page: https://cameratico.com/tools/web-browser-color-management-test/ https://cameratico.com/tools/web-browser-color-management-te... in X, the ProPhoto and sRGB strips look different. In Wayland, they look exactly the same (in the monitor's native color gamut). X is definitely more capable than Wayland is, at least with Chrome.
        mikae1 3y ago
        There's a lot of talk about HDR and Chrome here. I'm interested in neither but me and other professionals (in photography and graphic design) that do color critical work need to be able to create color profiles with spectrophotometer hardware and https://displaycal.net/ https://displaycal.net/ and use those profiles. It's a well known fact that this is currently impossible with Wayland but possible in X. Developers of darktable, Rawtherapee, Krita and other open source applications hang out out on pixls.us. Here's a thread: https://discuss.pixls.us/t/wayland-color-management/10804 https://discuss.pixls.us/t/wayland-color-management/10804
- mananaysiempre 3y ago
  Well, for some people that’s apparently fine—an image asset format (QOI) that’s been received fairly well by this forum had its author strongly opposed for the longest time to even specifying a colorspace, let alone allowing more than one. Those people are not me and I’ve cursed them out a few times, but they are not rare. In any case, track the spec progress here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
  - duskwuff 3y ago
    I feel the bones of a "Falsehoods Programmers Believe About Color" forming in my head.
    - mananaysiempre 3y ago
      The {Gamma,Color}FAQ pair[1] are the traditional entries in that category, although my own experience implementing colorspace transformations is that they may be making the subject appear more complicated than it needs to be. At the same time, I’m not sure if the “falsehoods” path is the simplest here, or if an explanatory “what is” approach would be better. There’s no end to mistaken things people get confused into believing, but the fundamentals of emissive colour are just not that hard—a (mostly) linear system can only be so complicated. In that respect I think I found the introductory part of the Matplotlib colormap talk[2] to be the most helpful source on the basics. (There are difficult things about color, of course. But perceptual similarity does not in my opinion count as part of the fundamentals. And while the science of paint and light-matter interaction in general is basically endless, unless you’re doing print design or photorealistic rendering it’s probably not an immediate concern for you.) [1] https://poynton.ca/notes/colour_and_gamma/ https://poynton.ca/notes/colour_and_gamma/ [2] https://bids.github.io/colormap/ https://bids.github.io/colormap/
- TheCycoONE 3y ago
  Not neglected - complicated. This blog is nearly 3 years old now but still gives a good summary https://www.collabora.com/news-and-blog/blog/2020/11/19/developing-wayland-color-management-and-high-dynamic-range/ https://www.collabora.com/news-and-blog/blog/2020/11/19/deve... And here is the relevant ongoing proposal https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
jvolkman 3y ago
Are you certain that you're running Chrome under Wayland, and not XWayland? I couldn't figure out for the longest time why I couldn't drag a file from the Gnome file manager to Google Drive in Chrome. Turns out it's because Chrome wants to run under XWayland by default - at least on my machines. I switched "Preferred Ozone platform" to Wayland under chrome://flags and now drag+drop works. Not sure about color management, though.

orbital-decay 3y ago

Every time I want to try it I see complaints about color management, and it raises all red flags I have with me. Is it really true? How can something so basic and vital be neglected?

nsajko 3y ago
Yeah, it's crazy how Wayland is being pushed as a replacement for X.
- andrewaylett 3y ago
  The people who wrote and worked on X for many years decided to write and work on Wayland instead. No-one's forcing you to switch, but conversely no-one's forcing the folk who used to work on X development to keep doing that. I did see one of the long-standing developers wondering whether it would have been better-received if they'd called it X12 :P.
- djbusby 3y ago
  Well, X is definitely showing its age and some week-spots. I think we need something. And given how huge X is - in both features and users - it's gonna be really hard. And, it seems only Wayland is making any progress - even if slow. The other options are slower or non-existent.
  - nsajko 3y ago
    X is suboptimal, but Wayland is way worse.
- Jasper_ 3y ago
  X is not color-managed either.
  - mkozlows 3y ago
    I promise you that color management works in X, at least with Chrome.
    - Jasper_ 3y ago
      X is color-managed to the same degree that it is in Wayland. That is, all buffers are sRGB, and the application needs to convert output buffers in sRGB format. Chrome certainly takes great care to do color management of the content displayed in the window, but again, it is limited to sRGB output. This is the same in Wayland and X. Color management needs improvement across the kernel & drivers, the compositors, and the applications. For more details on implementing color management, see Henry Wentland's 2022 XDC talk about implementing HDR (a feature that requires robust color management up and down the stack). You might notice that it primarily focuses on Wayland. [0] https://www.youtube.com/watch?v=nDnbWaIMJJA https://www.youtube.com/watch?v=nDnbWaIMJJA
      - mkozlows 3y ago
        Okay, my situation is that I have a monitor that displays a larger than RGB color gamut. When I set an ICC profile for my monitor in GNOME, and go to a page that should be in an sRGB color gamut in Chrome in X, it displays it as it should look. In Wayland, it displays it in my monitor's native (wider than sRGB) gamut. Similarly, if I go to this page: https://cameratico.com/tools/web-browser-color-management-test/ https://cameratico.com/tools/web-browser-color-management-te... in X, the ProPhoto and sRGB strips look different. In Wayland, they look exactly the same (in the monitor's native color gamut). X is definitely more capable than Wayland is, at least with Chrome.
      - mikae1 3y ago
        There's a lot of talk about HDR and Chrome here. I'm interested in neither but me and other professionals (in photography and graphic design) that do color critical work need to be able to create color profiles with spectrophotometer hardware and https://displaycal.net/ https://displaycal.net/ and use those profiles. It's a well known fact that this is currently impossible with Wayland but possible in X. Developers of darktable, Rawtherapee, Krita and other open source applications hang out out on pixls.us. Here's a thread: https://discuss.pixls.us/t/wayland-color-management/10804 https://discuss.pixls.us/t/wayland-color-management/10804
mananaysiempre 3y ago
Well, for some people that’s apparently fine—an image asset format (QOI) that’s been received fairly well by this forum had its author strongly opposed for the longest time to even specifying a colorspace, let alone allowing more than one. Those people are not me and I’ve cursed them out a few times, but they are not rare. In any case, track the spec progress here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
- duskwuff 3y ago
  I feel the bones of a "Falsehoods Programmers Believe About Color" forming in my head.
  - mananaysiempre 3y ago
    The {Gamma,Color}FAQ pair[1] are the traditional entries in that category, although my own experience implementing colorspace transformations is that they may be making the subject appear more complicated than it needs to be. At the same time, I’m not sure if the “falsehoods” path is the simplest here, or if an explanatory “what is” approach would be better. There’s no end to mistaken things people get confused into believing, but the fundamentals of emissive colour are just not that hard—a (mostly) linear system can only be so complicated. In that respect I think I found the introductory part of the Matplotlib colormap talk[2] to be the most helpful source on the basics. (There are difficult things about color, of course. But perceptual similarity does not in my opinion count as part of the fundamentals. And while the science of paint and light-matter interaction in general is basically endless, unless you’re doing print design or photorealistic rendering it’s probably not an immediate concern for you.) [1] https://poynton.ca/notes/colour_and_gamma/ https://poynton.ca/notes/colour_and_gamma/ [2] https://bids.github.io/colormap/ https://bids.github.io/colormap/
TheCycoONE 3y ago
Not neglected - complicated. This blog is nearly 3 years old now but still gives a good summary https://www.collabora.com/news-and-blog/blog/2020/11/19/developing-wayland-color-management-and-high-dynamic-range/ https://www.collabora.com/news-and-blog/blog/2020/11/19/deve... And here is the relevant ongoing proposal https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...

jvolkman 3y ago

Are you certain that you're running Chrome under Wayland, and not XWayland? I couldn't figure out for the longest time why I couldn't drag a file from the Gnome file manager to Google Drive in Chrome. Turns out it's because Chrome wants to run under XWayland by default - at least on my machines. I switched "Preferred Ozone platform" to Wayland under chrome://flags and now drag+drop works. Not sure about color management, though.