The reason is stated in the commit message -
We don’t support the wayland platform plugin until it has tablet
support and color management support.
Tablet support is there and one that remains is colour management. You can get more information about this on the krita side here - 429079 – platform=wayland requires xwayland
In addition to this I have heardkrita uses some X utilities like xcb for some keyboard shortcuts to work. I might be wrong in this
Implementing pen pressure curve settings seems easy enough to do. It could even be done by someone with no prior experience with KWin/Wayland development.
If there’s someone interested in doing it I’m happy to guide then through the process.
If Fedora hadn’t decide to completely drop X11, none of this discussions would have happened and things would still be somewhat in the air.
This is a major shift in Linux Desktop. It will be a bumpy ride. But I am sure it will be worth it.
I think it’s also worth asking what those of us who are visually impaired also need.
For me, it’s the lack of gamma control in Wayland. I can use xrandr to handle that in x11 on an AMD card, but for Wayland, there isn’t anything that’s currently accessible and clearly documented. I literally have a scripted line to execute gamma on login, it’s not a great experience, but it works.
I love that Fedora’s choosing to become the bleeding edge of a new protocol, and good luck to them. Some of us need to be able to see what we’re doing, in ways most people can’t quite understand. Grateful there are a myriad of distros out there that are slightly more conservative. (yay for EndeavourOS 
).
This is explicitly something that Kwin has to expose. It absolutely could, and in fact it does this internally for other features (like Night Light). Please file a bug report asking for this explicitly.
It is already filed in 2018 - 389110 – Being able to change gamma and again a duplicate in 2021 435587 – can't use kgamma in wayland
And here is the Open Merge request - WIP: Add option to set gamma values (!1335) · Merge requests · Plasma / KWin · GitLab
Here is a mockup by Tyson tan showing that - Port colord-kcm to Qml (!11) · Merge requests · Graphics / colord-kde · GitLab
If we can please drop the negativity and work together to improve the situation, that would be great.
It should be noted though that kded currently kills colord upon login when running a wayland session along with the colord-kde setting not actually working when using plasma wayland. (both issues reported some time ago)
In order to actually load ICC profiles under a Plasma wayland session at login i had to tell kded to go kick sand by making a separate unit file to keep colord alive after login. Since the colord-kde settings dont work in wayland you have to use colomgr from the terminal to manually assign profiles to your displays.
There is also the issue that currently Kwin (under wayland) doesnt seem to make colord aware of what colorspace the display is using as the colormgr get-devices ouputs Colorspace: unknown. This doesnt appear to be an issue on Gnome/mutter in wayland which might just assume RGB and tell colord that but im not sure. Is the profile REALLY doing anything? How can applications even display colors remotely correctly if they have no idea of the colorspace?
Im really not sure it can be said Plasma on wayland currently has even basic color profile support as unless youre willing to workaround some rather annoying issues and willing to trust that the colorspace being unknown isnt an issue the current state of Plasma Wayland + Color Profiles is more that just a bit of a mess.
I dont think people should be forced to deal with this unless these issues are resolved by the time X11 is dropped. If these things arent resolved by that point i feel telling people to just “stick with Fedora 39” is kind of hand waving the issues and hoping those who might fuss will just accept their fate.
People are frustrated understandably, and the thought of being forced to drop the distro theyre use to due to something they feel is completely outside their control will obviously breed resentment, especially when you feel its something that heavily effects you and you didnt get clued in till the vote was cast.
I dont think anyone here doesnt want to work towards improving this but a statement like this doesnt help the situation IMO.
Wayland has actually had color management in some form in the works for at least a decade (ive seen commits towards it as far back as 2013) but the problem is getting people knowledgeable in implementing that in a way that isnt hacky at best like with X11 or Windows and is done more properly.
Currently X11 CM “works” in that it just lets applications do it themselves and any application can do it at any time and step on each others toes with nothing stopping that happening. Wayland needs to be better at this and its a difficult situation.
Im not sure digimend should be a target for being “Required”. My experience has mostly been with Huion but all of my devices have worked as long as they get a description in libwacom they just work ootb on wayland with the kernel driver. Id be curious if you actually require digimend as i know a number of XP Pen devices have libwacom definitions and you may just need one made for your device.
I’m just asking to drop the negative words like ignorance and negligence, that’s all. People are entirely entitled to their frustration but when it comes to insulting work people do often for free, it is not welcome.
I have deleted my replies as per the gag order. I will not critique or talk about the distribution anywhere here. I did not mean to disrespect or hurt you or anyone personally. I will not be engaging with anyone from fedora anymore.
Thanks
I’m not a designer, but suppose your preferred distribution where you invested a lot of time and money to learn, install and configure different development environments and tools suddenly dropped the ability to debug your code?
It’s the same feeling for digital artists because color management is a core feature for them.
At least KDE is not yet dropping X11, so the ability to use them both on other distros is still possible.
No color management or support for changing Gamma: 439135 – Color management on Wayland, 439135 – Color management on Wayland, Color management on Wayland (#11) · Issues · Plasma / KWin · GitLab; requires https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 and adoption in KWin
Yes, do please describe what you need - but the actual goal, not just the tools that you’re currently using to achieve it. Xorg-style gamma ramp messing is intentionally not supported in the Wayland session, it’s a broken misfeature that’s causing lots of issues, but if we know what you’re actually trying to achieve then we have a chance of implementing it the right way.
Modern monitors are generally well-calibrated across their frequency range.
There are, however, some manufacturers who “forget” to calibrate anything beyond the 60Hz range, leaving the end-user to make these changes manually themselves in software. For those with low-vision, gamma is essential to getting the right degree of contrast (hence the whole point of high-contrast themes).
The “end goal” is that black needs to be black, and not a washed out shade of grey. The ability to read text and differentiate between UI elements is directly impacted by contrast, or the lack of it.
This is currently implemented in xorg via both CLI and UI
CLI commands example:
nVidia:
nvidia-settings -a 0/RedGamma[DP-0]=0.644000 -a 0/BlueGamma[DP-0]=0.644000 -a 0/GreenGamma[DP-0]=0.644000
AMD:
xrandr --output DisplayPort-2 --gamma 0.744:0.744:0.744
UI:
It’s important that we maintain functionality in Wayland to allow for adjustments at a fine level, to contrast. Colour gamut is handled well already within device-specific display profiles. The lack of contrast for poorly calibrated displays is exposed more as frequency ranges increase.
This petty passive aggressive behavior is disappointing. You can do better. Justin was trying to steer the conversation back to being actionable and productive so that the things you’re not unreasonably complaining about can be fixed.
It’s a bit more complicated. Messages in this thread were edited and painted the replies of anon88800485 badly out of context. Removing himself from the forum/thread was a way to protect himself from the tension of this thread. (source: had a chat with him to check if he was ok)
I don’t see any edits in any of Justin’s posts. And certainly there was no “gag order” of any kind, that’s just insulting.
I understand being agitated by the possibility of something you rely on becoming broken, but I’ve been following this thread from the beginning and what I see is KDE and Fedora developers being exceptionally helpful.
