Yes, of course 
My understanding of the proposal that is being discussed is that it will be fixed, eventually.
I am using Wayland every day in Debian/testing (when I donāt need to work in Darktable). It works fine.
If they fixed color management, I would find it nearly perfect. YMMV.
Iām even more curious when DT plans to support Wayland even without CM. 
I also have a feeling that we are on the crossroads of protocols, so the road is currently bumpy with lots of deep potholes, like unsupported and crashy apps, drivers, half-baked Wayland.
But once polished and established with all major programs supporting Wayland, weāll be off to a good and stable start.
Your view might be biased because you look at many of those monitor that will give you a wide gamut. most people out there do not care about this. even if their monitor has HDR support. they just take what their monitor/OS gives them when they switch on HDR for a movie or gaming.
but there are still a ton of monitors sold that are not even covering 100% sRGB. the price bracket for monitors that do more than 100% sRGB is not what many people would spend on a monitor.
Apparently they do have some profile support, but how far it goes, I have no idea.
Maybe Iām just being naive, but Iāll take the chanceā¦ Is the Wayland server applying some colour transform under the hood? If not, āmanualā colour management (meaning the user selects explicitly a colour profile and the application applies the transform) should just work, or am I missing something? I understand the issues with profiling a given screen and automatically selecting the right profile, but the manual way should be usable in the meantime, or not?
I am testing Wayland in my workflow and beside color management concerns i experienced heavy mouse cursor stuttering in Blender under GPU loads using Wayland or Xwayland ( already reported in Blender but apparently it is a Wayland/Xwayland problem with AMDGPU and the compositor ).
The āpixel perfect framesā paradigm is very cool but if the mouse pointer is not working during heavy GPU loads, the experience is very frustrating.
So pushing Wayland could be useful to increase bug reports and hopefully fix the most important problems ( with different compositors ) or reach a feature parity with X1.
I hope we can use X11 as long as possible but apparently most used DE are pushing towards Wayland ( and Xwayland is not working in my experience ).
I plan to test different Desktop Environment, compositors and also new hardware but for my personal experience and my workflow Wayland is not ready.
yea, just tested it, same as plasma 6, colors outside of srgb are wrong
Apparently they want it to work like MacOS, i.e. color management is done by the system, not the application, so desktop icons and everything that has no embedded profile are not oversaturated on wide gamut. but it does not work properly. as I described before: a profile can be chosen and set in the desktop environment, and on wide gamut screens it actually does adjust (reduce) saturation to some extent, but the trouble is that colors outside of srgb are apparently displayed as a the closest color inside srgb. so photos in e.g. adobergb that actually contain colors outside srgb are not displayed correctly.
I canāt code, I donāt understand the technical details but itās really strange and I canāt imagine how this is actually possibleā¦
Btw I think I tested what you just suggested, i.e. no system(wayland)-wide profile, just set the profile with dispwin, and then use whatever x11 photo app thatās color managed and can pick up the profile from x-atom, or select the profile inside the app. I think that does not work either but I will test again.
This is not what I was suggesting. I was suggesting trying with an app that supports setting an explicit icc profile
I just tested again. x11 apps that work via xwayland are actually color managed if they can get the right profile. But for this to work properly, you have to switch off wayland color managment, and then apps such as gwenview display oversaturated colors because they are wayland native and there is no way to set the profile inside gwenview. So you constantly have to switch on and off system wide color management if you are using both x11 and wayland native apps.
Tearing support is being added(or has already been, havenāt been following that very much) so users will also have the option to tear if they prefer
Has anybody tested if color management under can be configured outside of gnome or kde plasma? I mean something like sway or hyprland?
I donāt think wlroots(swayās compositor) has implemented it, so only after that will hyprland implement it since their composer is based on wlroots and still takes many things from it.
But the wheels are turningā¦ somewhat: Color Management Ā· Issue #4377 Ā· hyprwm/Hyprland Ā· GitHub
One more reason to start with the color mgmt API now and start testing it:
if you find any issues they might be fixed before the spec is 100% finalized
would you know an entry point (api docs/example code/something)? iām interested in trying itā¦ iām going to claim that vkdt works just fine by doing all the colour management by itselfā¦ but so far this depends on dispwin for the vtcg (and also i can only run wayland using the onboard intel gpu in my laptop, the nvidia will not allow me to show images on screen, only in x11). iād be interested to understand the approach taken here (do i tag surfaces with a colour space? can i get one that is straight monitor rgb with linearised vtcg?).
Yes, thatās the gist of my question above as wellā¦
Just to make sure I understand it right, up to now X and Windows have just managed the availability of device profiles, it was up to the application to grab them, convert to them, and display the converted image on the supposedly raw screenā¦ ??
If so, is Wayland just going to perpetuate that, or is it going to require applications deliver their display renditions pre-converted to a working space, or a deliver a color profile along with the rendition for them to convert?
The availability of API/data access for calibration apps to use is yet another concern, one of which I know far lessā¦
As a developer Iāve followed a bit the development in the protocol merge request, just from an intellectual point of view, interested in how this evolves from scratch. I donāt code for Wayland or related stuff , so, please ignore my answer if off topic.
There is a separate repository with documentation and some implementation advices here (maybe too much) that is useful to understand the design: https://gitlab.freedesktop.org/pq/color-and-hdr
In the protocol PR, I find the description of each interface and parameter quite well written and it makes it quite easy to understand https://gitlab.freedesktop.org/swick/wayland-protocols/-/blob/color/staging/color-management/color-management-v1.xml (you just have to ignore the XML tags)
From my understanding of that protocol, the way it work is by attaching a wp_color_management_surface_v1 object to your wayland surface with the required color informations. There are 2 ways to create such infos: from an ICC file or from scratch setting all params.
Once a surface is properly described, itās up to the compositor to do the display transformation (or not if the surface if already in the same profile as the display)
I hope this answers your questions in some way.