Wayland color management

[darix]

@prokoudine

1. wayland native desktop does not mean no xwayland. every distro will keep xwayland
2. bitwig is java and probably running directly with xwayland. hence all plugins work
3. i am sure if you launch ardour with xwayland all the plugins work out of the box as well.
4. many plugins use juce. so fixing that would fix a lot of plugin. also all plugins directly using Qt/GTK would probably work out of the box. for plugins that use less widely used gui frame works that can be more tricky.
5. FreeCAD 1.0.0 works here on gnome 48 wayland session.

[prokoudine (Aleksandr Prokudin)]

@darix

i am sure if you launch ardour with xwayland all the plugins work out of the box as well.

This is not an “if”, because Ardour is among the few apps using GTK2 (they vendored it).

@darix

also all plugins directly using Qt/GTK would probably work out of the box.

All 10 of them? (30, if you still use Calf and suffer through it)

[darix]

@prokoudine

This is not an “if”, because Ardour is among the few apps using GTK2 (they vendored it).

to me it looks our package at least additionally links the distro gtk copy.

[   20s] Ardour Configuration
[   20s]  * Will build against private GTK dependency stack   : no

I would bet you fedora does the same. but not sure how many people are working on improving gtk2 itself though.

@prokoudine

All 10 of them? (30, if you still use Calf and suffer through it)

I mean in some way … everything sitting on top of JUCE might actually be good if someone works on fixing wayland support for many plugins.

[Tim (Tim Cuthbertson)]

@prokoudine

… if you still use Calf and suffer through it

Hmmm. I use Calf and it causes me no trouble at all. It has much more capability than for the few things I use of it.

[prokoudine (Aleksandr Prokudin)]

@darix

I would bet you fedora does the same. but not sure how many people are working on improving gtk2 itself though.

I use official binary builds made with vendored GTK. Users of distro-provided builds miss out on fixes and features (think multi-touch support).

[darix]

are those fixes not in the official tarballs?

[prokoudine (Aleksandr Prokudin)]

@Tim

I use Calf and it causes me no trouble at all.

Sure, if you don’t mind DSP issues

[prokoudine (Aleksandr Prokudin)]

@darix

are those fixes not in the official tarballs?

Official tarballs of unsupported GTK version? No, I don’t think so

[danny]

@darix

people are working on those things yes.

I don’t see even recent reply on the gitlab issue.
Could you please share your sources?

[Zamundaaa (Xaver Hugl)]

Ugh, gmail decided to put all notification emails from this forum into spam, so I missed a lot of messages… I’m gonna try to answer the (to me) most relevant bits from the backlog.

@betazoid

Or maybe there is a possibility to exclude apps such as darktable, krita etc. (that can do color management on their own) from kde plasma/wayland system wide color management?

I looked into implementing such workarounds before, but communicating the desired colorspace to apps turned out to be rather difficult, because behavior between apps is so unpredictable. Some use the X11 atom for the first screen, some support the atom for other screens, others only support colord, and the remainder only supports manual configuration. More problematic, some may use profiles from colord when running Wayland native too, making setting the profile with colord potentially an even worse idea…

Implementing a complete “pass through” of sorts for X11 apps would’ve been the other option (at least for SDR displays), but is challenging with arbitrary ICC profiles because of limitations in KWin’s renderer architecture. I’ve been trying to make it more flexible for this, but it might take some more time to get that done.

For applications that use the X11 atoms as well as those with manual configuration, where you can be relatively sure how they’ll behave, we could somewhat easily add a compatibility system where the compositor exports a simplified ICC profile that we assume all X11 applications to target. When I last looked into that particular approach, it seemed questionable how many applications would actually benefit from this… but if people here confirm that it would be useful for them, I’d be happy to make it a thing in Plasma 6.5.

@Till80

Is it correct, that if I set the output profile in DT to sRGB colour management works within the limitations of the colour space?

Yes.

@mikae1

Is it still not the case that we can’t profile our monitors under Wayland?

You can. What Pekka was talking about was not really correct, it has been possible to profile displays on Wayland forever - just like X11 has no API for you to show rgb values unmodified in some way, Wayland doesn’t require one either. You just have to manually unset the current ICC profile before profiling.

What doesn’t exist is a protocol to make profiling more convenient / automated and allow applying calibration steps (“VCGT”) on the compositor side instead of the application for improved accuracy. There’s also currently no (released, more on that later) Wayland-native profiling application in general, which makes adding such a protocol more challenging.

These are real and annoying problems, but very different ones from “can’t profile monitors under Wayland”.

@raghukamath

I reiterate my opinion again, HDR was all that mattered for the devs from the beginning. Who knows how long it will take to get color profiling and verification

That couldn’t be more wrong. HDR doesn’t require even half the features of the color management protocol. Most of it is all about SDR color management.

For reference, src/wayland/protocols/frog-color-management-v1.xml · master · Plasma / KWin · GitLab was used for HDR until the upstream protocol was merged (note how the upstream protocol is 5x longer).

@paperdigits

But people are not working on profiling

As a general statement, that sounds about right. Everyone complains, but pretty much noone actually steps up to do the work. That includes profiling on X11!

DisplayCal isn’t exactly packaged everywhere, building it is a mess and the Flatpak on Flathub is 5 years old and broken. The one on Flathub beta is using the Python 3 version at least, but profiling in it broke for me a few months ago too…

Since then I’ve been working on the side on a new profiling app that’ll be packaged and regularly released with KDE Plasma sooner than later. It’s not quite finished yet, but basic profiling for shaper+matrix profiles works, and it nicely integrates with Plasma’s display settings already. (With that integration btw it also gets some additional features like being able to measure the display response at more than just one singular backlight level)

So, no, “people” are working on profiling. Things might not be going as fast as you’d like them to, but if you want to change that, you need to step up and do something about it instead of just complaining about it on a forum. The Wayland transition isn’t some evil corporation like Microsoft or Apple pushing changes on you, where bad PR is the only chance at getting them to fix the problems you face, it’s volunteers (paid or not) moving the ecosystem forward. All it takes for a lot of these issues to be resolved is for one or two people to step up and actually do the work.

[hanatos (jo)]

thanks for all your work on this! i’m really looking forward to dropping some x11 mechanisms and do colour management on wayland the wayland way. i’m currently going through the vulkan extension VK_EXT_swapchain_colorspace and am glad to see how things become really easy on the application side once the compositor implements the color_management_v4 protocol (i tested on hyprland with your vulkan hdr layer hack and on plasma). for now i also keep the legacy codepath that assumes that the compositor does no transformation at all, so i’ll apply matrix+shaper. this kinda expects passthrough behaviour, though i haven’t been successful setting stuff as VK_COLOR_SPACE_PASS_THROUGH_EXT or using AMD’s display native extension, it just works implicitly

how are you talking to the display? some qt interface? can it work outside kde? would you already be able to share a link to a public repository for the profiling code?

[Zamundaaa (Xaver Hugl)]

@hanatos

VK_COLOR_SPACE_PASS_THROUGH_EXT

That doesn’t do what you seem to think it does - it just tells the driver not to do any color management for you (at least on Wayland; I don’t know exactly what it does on Windows).
It is useful (and necessary) if you want to use the color management protocol directly instead of having the driver do it for you, but it’s not particularly useful for profiling.

@hanatos

how are you talking to the display? some qt interface?

Same way any other application is talking to the display, I just show rgb colors in a window. There isn’t (yet at least) any special Wayland protocol involved.

@hanatos

can it work outside kde?

Yes. The settings integration is then missing, but if you manually remove any color profiles you have set, you can do the normal profiling on any compositor or window system.

@hanatos

would you already be able to share a link to a public repository for the profiling code?

I wanted to link it, but apparently this forum doesn’t allow links to kde’s gitlab instance… Search for “DisplayProfiler” (still looking for a better name) on invent dot kde dot org to find it.

Do keep in mind the current incompleteness though - no verification mode, and no autotests yet. I wouldn’t rely on it for professional use cases just yet, at least not before the first release

[hanatos (jo)]

Xaver Hugl / DisplayProfiler · GitLab

let me see if i am allowed to do this.

(edit: i can. seems the system found you are a recent/new user that posts links to the same spam domain… i took the liberty to unflag this)

[raghukamath (Raghavendra Kamath)]

@Zamundaaa

The Wayland transition isn’t some evil corporation like Microsoft or Apple pushing changes on you, where bad PR is the only chance at getting them to fix the problems you face, it’s volunteers (paid or not) moving the ecosystem forward. All it takes for a lot of these issues to be resolved is for one or two people to step up and actually do the work.

Yes , and I have tried to do my part by reporting bugs, testing and also trying to give information and other stuff where I was asked to do. I am sorry for not being a programmer to step up and learn C or C++ to write code to make art professionally on linux. So yes other than complaining on forums (which I think I have stopped mostly and I will stop completely from now on and move on) , and reporting bugs and may be doing little funding when possible I can’t do anything and I am at the mercy of people who know to code.

But with all the distro people like fedora pronouncing that wayland is on par with x11 for art and also people hyping up and celebrating the death of X11 when in reality it is not 100% ready yet seems exactly like windows pushing updates on users. I had to ditch fedora and switch debian after fedora 40, that was in 2023.

And yes I am also extremely grateful that you are working on the part that matters to artists.

[epeeist (Colin Walls)]

Red Hat is dropping Gnome X11 support for Fedora 43, and moving to Wayland.

If you are a Fedora user, will you move to another distribution, switch to another desktop (Cinnamon and Mate are mentioned) or try to run GTK/X11 apps within Gnome?

[hatsnp (Nuno Paulino)]

I wonder if other distros will also start dropping the Gnome X11 session for the same reasons:

Neal Gompa, the change proposal owner, highlighted that the GNOME X11 session has received minimal testing and very limited development efforts upstream, leading to many unresolved bugs.

[epeeist (Colin Walls)]

@hatsnp

I wonder if other distros will also start dropping the Gnome X11 session for the same reasons:

I would guess so.

[Higgins]

@epeeist

If you are a Fedora user, will you move to another distribution, switch to another desktop (Cinnamon and Mate are mentioned) or try to run GTK/X11 apps within Gnome?

Fedora 43 isn’t due out until November, and by then (if all goes well) there should be native Wayland profiling by then. (What Zamundaaa mentioned.) I’m currently working on a library to allow independent access to colorimeters/spectrometers. Already has support for popular colorimeters, and I even have a couple new ones like the Display 123 and Spyder Pro to work with.

Cinnamon is already on a push to get on Wayland ASAP, and GNOME 50 is completely dropping X11 support.

The problem then becomes getting apps to run well under Wayland and not use XWayland.

[tankist02]

I regularly switch between Gnome and XFCE when on Fedora.

[paperdigits (Mica)]

@Higgins

I’m currently working on a library to allow independent access to colorimeters/spectrometers. Already has support for popular colorimeters, and I even have a couple new ones like the Display 123 and Spyder Pro to work with.

That is very exciting! Glad to hear it. If we can do any testing, please do reach out to the community and say so!