This is not strictly related to krita but since there are two or three posts here on the forum about krita, linux colour management and wayland. I thought I should share this wiki that I maintaining on kde userbase. I ask artists using KDE linux and wayland to chime in and update the wiki so that people who need to know what we want know it better.
I have filed bugs for graphic tablet support side of things. I will test multi monitor setup next and file bug reports.
If someone else has other bug reports or information please fill it up or put it here so that I can update this wiki.
Thanks for a detailed list of the issues on KDE Wayland. I use both GNOME and KDE on different devices, but I don’t use Krita much and am a novice at…everything. I was wondering if there was a similar page for GNOME.
If not, I gathered up some basic information:
Graphics Tablets
Here’s a screenshot of what the “Wacom Tablet” settings look like in GNOME 46:
I thought that might be helpful. The GNOME 46 release noteshttps://release.gnome.org/46/#massive-polish-effort mentioned this:
additional fine-grained control when setting Wacom stylus pressure
I don’t think the settings themselves have changed at all for years, and as far as I can tell from a glance, has parity with their X11 session in features. KDE has always had more options in their settings panel for graphics tablets.
Color Management
Like KDE, GNOME is dependent on the color management wayland protocol being merged. Some relevant links (within my maximum of 2 for a new user):
I personally found [2] confusing, likely because of a misunderstanding on my part. It’s a thread about color management in GIMP, and how even when color management is sorted out in GNOME’s Wayland compositor, it probably won’t work because GIMP is a GTK3 program instead of GTK4? From my understanding, a big selling point of leaving color management up to the compositor is:
Some wild speculation here, but given that Weston, the reference Wayland compositor, merged support for the majority of the current color management protocol last month, it seems…close to being finalised?
Given that GNOME intends to drop support for X11 with GNOME 48 in March 2025 (not set in stone), I hope so. They didn’t end up hiding the X session with GNOME 46 after all, so they might have pushed back their plans a few releases while they get the accessibility infrastructure in place.
The Collabora article on color management and HDR for Wayland from 2020, while interesting, is not reassuring on that count
There is also no set schedule, so don’t hold your breath. This work is likely to take months still before there is a complete tentative protocol, and probably years until these features are available in your favourite Wayland desktop environments.
From what I understand compository being responsible for all the colour management has pros as well as cons.
I am not an expert from but I have seen comments from more experienced dev from krita side disagreeing with this since krita needs more information and control to show sift proofing gamut warning etc. The compositor taking control may be good for apps which do not do serious color work like image viewer etc but for specialised and advanced app it is a bit of a drawback since the compositor will be responsible for colour accuracy.
Also I am not at all optimistic about the workflow being ready even if wayland compositors start implementing colour management now. Because even when the compositor has ability to use icc profiles it is the apps that we use need to use the compositor’s way of handling color and this becomes troublesome because each compositor may behave differently and these apps are not yet ready.
There is also an issue of lack of support for calibration and profiling apps like displaycal. I saw that displaycal had some updates on github regarding this but how accurate is that we do not know, and without these how are you supposed to generate the icc profile so may be in next 3-4 years wayland will be okay to use.
So I did a little more research, and I think the color management protocol is something that applications need to explicitly support based on (sorry for the low-quality link but it’s hard to find good information ):
Author of the linked toot here. Yes, GIMP will need to do some work if they want to take advantage of this. To make a very big oversimplification, the Wayland protocol extension allows an application to tag the (sub)surfaces it renders to with a color space (as well as given the app the preferred output color space). That in turn will allow the compositor to blend the given surface correctly with the rest of the desktop.
But related to GTK3 (this comment was made many months prior to the discussion between Jehan and GNOME contributors I originally linked):
Doing this in GTK3 will not be easy, and waiting for the protocol (and its implementations!) to land could potentially delay a 3.0 release way too much, especially as we’re inching closer to having an actual release candidate this year
That does at least sound like something Krita would be able to take proper advantage of in theory. Both GIMP and Blender seemed to think the protocol was good and provided what they needed based on the Mastodon post. I have not read a substantial amount of the 7,000+ word spec for color management, however
3-4 years sounds about right. Hopefully v1 of the CM protocol gets merged this year!
There is a lot of technical discussion I don’t have time to sift through, but in summary, the CM protocol does not encompass calibration. That needs to be done separately, as part of an XDG Portal. Not sure if an issue for that has been created yet, or even makes sense until after the color management protocol has been merged.
I would not take that quote on mastodon seriously. I had seen it and even I was really happy. But after seeing the discussion on the wayland trackers by the devs like jehan and dmitry from krita I am not so hopeful. this discussion was after the said quote. So clearly not everything was discussed. I do not know what they talked with the gimp and blender devs but it seems there are still many things to consider and it is not so great. The mastodon post create a false hope and hype in my opinion.
Sorry I am sounding so negative and dejected but from the reaction I read on the issue tracker and also the pace of development I am not at all hopeful.
You can see that most of the colour management discussion is hijacked by the HDR thing which is important for gaming related use case and all the funding and momentum is due to valve and redhat taking interest in the gaming and multimedia side of HDR. Not one discussion is about how to calibrate how to colour manage for graphic workflow etc. So I am really not that excited about it.
I think your position is completely fair. The more I look into it, the more I agree with you. Especially seeing the conversations between Jehan and others. I’m still a little optimistic that Google paying for Pekka Paalanen to work on the protocol means they have an interest in making ChromeOS competitive with Windows/macOS for creative applications…say the web versions of Photoshop and Lightroom.
But only time will tell.
It’s a little concerning they didn’t have this conversation until Jehan brought it up many years into the spec, yeah.
Yes I have seen this discussion on mastodon. It is really a welcome progress. These are not exactly xsetwacom as in distro agnostic tools but these surely help people. Any progress is welcome. There are more things to come in plasma too may be in 6.2 you will see more settings in the graphic tablet section.
I would like to know if anyone has faced issues where the cursor tend to jump off-screen if you’re using a tablet with display on Wayland as I’ve seen this happening not just with Krita, MyPaint is also affected.
I have no idea how to reproduce it, what I know is that when the issue occurs when you’re drawing a line the cursor sometimes thinks it’s somewhere on the other monitor and jumps there instead. Then your tablet loses focus of the window and you need to do something like an Alt-Tab back and forth into Krita before you can correct and redo your strokes.
I want to know if this happens on X as well.
For reference, I’m running on KDE Plasma 6 on OpenSUSE Tumbleweed. My tablet is an XP Pen though.
Hopefully that means we get some native Wayland support for Krita soon, I’ve been itching to switch to Wayland for years and the only thing left holding me back is Krita.
I can’t remember, was that support reliant on the switch to QT6?
I may be wrong, but if I remember this right, then it has to be ported first to Qt6 before they can begin to port it to Wayland, because if they would port it now then they had to do it again, at least in part, after the port to Qt6 is done.
But it is possible that I mix this up with another feature.
I’m not sure if this is the correct topic but here goes:
From the article:
The Plasma version 6.8, “which we expect will be sometime in early 2027,” will completely drop X11 support.
You don’t need to worry just yet. Plasma 6.5 appeared less than a month ago, and it’s currently at version 6.5.3. That means there are the entire 6.6 and 6.7 release sequences to get through, which will probably take most of 2026 and some of 2027.
so may be in next 3-4 years wayland will be okay to use.
):