requirements for Krita on plasma wayland
Open, Needs TriagePublic


As discussed during Akademy 2019, here is my user story about what's needed to be able to use (seriously) Krita on Plasma wayland.

*Graphic tablet support*

To be able to use Krita, of course first we need good graphic tablet support, which brings a number of issues.

-Driver issue:
On X11, the preferred driver for (wacom) Graphics tablets is xf86-input-wacom , from the linuxwacom project. It provides all the necessary features to make the best use of wacom tablets for all kinds of users, through the command xsetwacom. You can find all the available parameters using the command xsetwacom --list parameters .

As this driver is tied to X11, on wayland the only option is to use libinput instead, which is much more limited in terms of options. So, one needed thing ultimately is to extend libinput to reach feature parity with xf86-input-wacom. I know this is not directly part of plasma dev, but this had to be said, and I hope we can get good communication with libinput devs to move forward on that topic.

-Plasma support of tablets:
Currently, on a plasma-wayland session, tablet does absolutely nothing, not even moving cursor (tested on Manjaro, with latest updates).

For comparison, on gnome-wayland, tablet works, showing a second dedicated cursor. When testing Krita on it, the main tablet cursor disappears and only shows the second "Outline shape" cursor on the canvas ; painting does work relatively okay with pressure and tilt support (still I have a feeling while drawing that the input is not exactly as good as when using the wacom driver, but I didn't test long enough to really explain the difference), and clicking on the interface buttons works but you have to blindly press them (as the Outline-shape cursor is only visible above the canvas area). Tested with Krita appimage version 4.1.7; the next 4.2.* versions have a bug that makes it impossible to click on most of the interface buttons, at least with the system stack used currently in Manjaro, both on X11 and wayland.

*Color management*

To be able to rely accurately on the screen colors, unless you have a very-very expensive screen that has perfect color output by default, one needs to be able to calibrate it, and/or use a specific color profile for the screen output.

On X11, the go-to software for this is ArgyllCMS. It provides tools to calibrate the screen and create a .cal file that can be loaded to said screen, and to create an .icc color profile (which is needed if the screen is calibrated to something different than sRGB) and to install said profile to the system.

I wrote a tutorial article in 2011 when I started to use it ( ), though nowadays I know that for my use case I only need to generate a .cal file to calibrate the screen to sRGB (using the dispcal command) and then load that .cal file to the screen (using the dispwin command).
I personally prefer to stick to sRGB as it makes things simpler for multi-screen mirror setup; as I want the same output on both the screen tablet and external monitor; and while it's possible to use different calibration for each, it is not possible to transform that output to different colorspaces, so I stick to sRGB which is somehow compatible with any screen.

This brings us to wayland. We need to have ArgyllCMS (or a new equivalent) to be able to measure colors to create a calibration file, and load this file to the screen output.
For other advanced use cases, we also need to be able to create an .icc profile and transform the screen output to said profile. In this case, for color-managed applications like Krita, they need to be able to fetch the color profile used for the output, and directly send colors adapted for that color profile, bypassing the desktop color transformation.

Note that this topic of color management is very complicated, so I welcome color-experts to complement or correct these explanation which I wrote from my personal user experience.

If you have any question or need more feedback, let me know.

timotheegiet updated the task description. (Show Details)Sep 15 2019, 3:19 PM
ognarb added a subscriber: ognarb.Sep 15 2019, 8:20 PM
meven added a subscriber: meven.Oct 11 2019, 6:45 AM
zanny added a subscriber: zanny.Oct 11 2019, 6:16 PM
zanny added a comment.EditedOct 11 2019, 6:44 PM

I've been slowly plugging away at a KCM to manage libinput tablets over here. Making it work on X first before trying to get KWin tablet support up to get it working there too.

The only real feature anyone might care about that libinput doesn't natively support is button remapping - but that is a more general problem across Wayland, and there is a lot of ground that can be covered on that front in many directions - I can imagine a more general Kirigami Wayland panel that enables mapping input events, actions, combinations thereof, etc to other events, actions, etc generically, where KWin provides a global mapping but programs can use the framework to implement per-app associations like how KStandardAction::KeyBindings was used. Basically just the next evolution of the concept, and fortuitously free of the restrictions of XInput.

That concept though is way beyond the scope of making Krita work on Wayland. In the meantime, I've had a patch up to support high-order buttons in Krita so even with default button assignments you can still use tablets with a lot of buttons. We still want remapping somewhere, somehow, eventually, but getting any buttons besides 1-3 usable is a start, of course thats after you can use the tablet on Wayland at all.

alexde added a subscriber: alexde.Sun, Oct 20, 9:35 AM

So, one needed thing ultimately is to extend libinput to reach feature parity with xf86-input-wacom. I know this is not directly part of plasma dev, but this had to be said, and I hope we can get good communication with libinput devs to move forward on that topic.

I guess the libinput dev(s) will highly appreciate it. :)

apol added a subscriber: apol.Sun, Oct 20, 11:15 PM

Npte that we need both libinput and the wayland protocol to offer Qt/Krita all the information it needs.