Kde wayland for artists

Introduction

This page documents support for artist workflows under Plasma 6's Wayland session, in order to to help artists ascertain what is currently possible and what is in the works.

Support for Graphics Tablets

Support for graphics tablets is provided by the Linux kernel. Libinput serves as a driver and support library, allowing you to configure and use input devices on Plasma 6.

Unlike with X11, there is no need to install xf86-input-wacom. You should already have libinput installed as part of the Plasma 6 configuration provided by your distributions, and in most cases it will recognize your tablet automatically.

If your tablet is not supported by libinput, you might have luck trying out third party user space utilities like Open Tablet Driver. Most tablets from Wacom and Huion have good support on Linux.

If you are satisfied with the default configuration's pressure curves and shortcut mapping for pen buttons, you do not have to do anything to begin using the tablet.

The Drawing Tablet settings module as of November 2023

Should you need to configure your tablet, Plasma 6 has a new System Settings module (called a KCM) for tablets: simply open your System Settings and navigate to "Drawing Tablet". This new KCM still lacks some configuration options, but more are continually being added.

Supported features of graphics tablets

• Setting orientation of the tablet
• Mapping a portion or the whole screen to the tablet surface
• Configuring the tablet and stylus buttons to activate keyboard shortcuts, including single modifier keys like Ctrl as of Plasma 6.1
• Switching between left handed and right handed modes
• Setting a target display
• Stylus calibration support (in Plasma 6.2)

Currently unsupported features and known issues

• Mapping only a portion of the tablet area to the screen is currently unsupported. The UI for display mapping and button configuration is inferior to the equivalent interface under X11.

• There is currently no way to create multiple tablet configuration profiles and switch between them to enable multiple workflows.

• The KCM currently does not support making advanced adjustments to the tablet's pressure curve.

• Often graphic tablets have a touch strip or ring, but in Wayland, there is no way to assign shortcuts to touch rings. Changing touch ring "mode" - including switching from one set of shortcuts to another - is unsupported as well.

• Toggling between absolute and relative pixel scaling, called "mouse mode" by Wacom, remains unsupported in Wayland.

• Tablet pointers use an incorrect cursor when hovering over native Qt6 Wayland windows, which can make it difficult to resize windows with the stylus.

Support for Color Managed Applications and Screens

Under X11, most color management users were accustomed to the colord workflow, but this workflow had many problems and has been entirely replaced in Plasma’s implementation of Wayland.

A color managed workflow on Wayland begins with an appropriate calibration profile (ICC file) for each of your screens. You should create profiles, if you don’t have them already, with a colorimeter device and calibration software like DisplayCAL, which you will most likely find in your distribution’s packages.

Using X11, you would have assigned each profile to its respective screen in colord, and color managed applications were individually responsible for mapping the colors in your images or videos to the gamut of your screen as indicated by your profile. This could happen automatically for programs that knew how to request the screen profile from colord, and for other programs you would manually import the profile.

The Display Configuration settings in Plasma 6

With Plasma 6 and Wayland, you will instead apply profiles to your screens in the Display Configuration module (or KCM) of the System Settings. A piece of software called a compositor is now responsible for managing your system’s colors. Plasma’s compositor is named KWin.

Software that isn’t color managed (which includes the Plasma desktop itself) will be treated as if it were tagged with the sRGB space, and mapped by the compositor into the color gamut of your display.

Color managed applications need to tag themselves with appropriate source color profiles, in order to have KWin perform this conversion on their behalf. A new protocol is currently under development to allow applications to communicate this information to the compositor. KWin has partial support for a draft version of this protocol, but in order for color management to work, the programs you use must adopt it as well. Once an application has adopted the protocol, there is nothing you need to do - color management will simply work as expected.

What this means for users of color management

If you have been using applications that are not color managed, or you exclusively target sRGB formats (common in web publishing), the switch to Plasma 6 with Wayland is good news.

• Your applications with no support for color management will now behave better. Treating them as implicitly working in the sRGB space will usually result in better color rendition than allowing them to draw naively into the native color space of your display.

• You can simply disable any active color management performed by other applications, and rely on the compositor to perform this function. If you must select a profile for these applications, you can simply give them an sRGB profile, as this will match the behavior of the compositor on Wayland.

If you rely on applications that use color management and you work in color spaces wider than sRGB (called wide color gamuts, or WCG), then you will not currently be able to use the Plasma 6 Wayland session.

• Popular applications for professional graphic design such as Krita, Inkscape, the GNU Image Manipulation Program, and others do net yet support the Wayland color management protocol.

• Work on color management in KWin is still under heavy development and some features you may need may not have yet be available to you. For instance, support for rendering intents and black point compensation has not yet been released.

Why is this happening?

KDE developers are replacing the traditional color management process with one managed by the compositor because of several long standing problems with color management on Linux that lacked better solutions:

• Most applications lack any support for color management. Without the system taking responsibility for color support, these programs would continue to be unmanaged. Many applications that did support color management were difficult to use and required manually setting profiles.
• X11 has very poor support for HDR (at best). When applications that do not have native HDR support are used on an HDR screen, it is necessary to choose a diffuse white point for them that is darker than the peak white point of the display. The compositor would inevitably be required to do color management in this scenario.
• Even applications with good support for colord under X11 rarely worked in multi-screen environments. To do so correctly, the application would have to detect when it was moved from one screen to another and immediately change its calibration target, but few (if any) applications ever did this. Under the compositor-driven approach of Wayland, this will happen automatically.
• In the long term, all applications on Linux will benefit from the robust color management and HDR support that comes with this new approach, but this necessitates a transition period until applications with legacy approaches to color management introduce support for Wayland.

Support for calibration and profiling software

Since KWin doesn't yet provide built-in profiling and calibrating software, instead users must rely on third party software like displayCAL. Note that the original displayCAL stopped receiving updates in 2019, and most distributions are shipping a fork adding support for modern features; if you need to download the software directly for some reason, make sure you’re using the correct version.

When using displayCAL under Wayland, several qualifications are important to keep in mind.

This issue about is access to the video card LUT. ... The main issue this causes is that if you currently have a profile loaded, that profile won't be cleared while calibration/profiling is running - so the newly generated profile will be garbage. It's possible that DisplayCAL could work around this by clearing the LUT before running the argyllcms tools. Note that the argyllcms tools still think they can access the LUT when running in XWayland, so they will put the calibration data into the profile.

You might also have issues with the position and/or scaling of the colour swatches, especially if you have multiple monitors and/or have display scaling set to a value other than 100%.

— Calvin Walton, comment on Github

With this in mind, several cautions are in order:

• Under Wayland, make sure that you’ve fully disabled all color management for your screens before profiling them with displayCAL. KWin’s calibration can be disabled using the Display Configuration KCM in your System Settings.

• Don’t try to use displayCAL or argyllcms for anything other than creating a calibration profile (ICC file) under Wayland. These software were originally designed to handle loading profiles into the display themselves (the role also performed by colord), and they may incorrectly behave as if it were still possible for them to do so. As a Plasma 6 user, you should take the created profile and use it with KWin instead.

• For maxmimum reliability, you may want to switch to X11 before performing color calibration. Once an appropriate profile has been generated for your screen, it will be valid under Wayland as well. See this issue for one known problem under Wayland.

Color Management for Other Devices

Under Wayland, color management for other devices (such as printers) are not managed by KWin. You will continue to use colord to manage these devices.

KDE provides a graphical interface (colord-kde) to manage these devices, and the latest version of this software has been updated to support Plasma 6. After installing colord-kde and colord from your Linux distribution, you will find a Color Management KCM in your System Settings.

High Dynamic Range (HDR) Display Support

Under X11, very few applications supported HDR. Some special purpose devices like the Steam Deck have special tricks to get X11 games to output HDR on those devices.

As with color management, under Wayland the compositor is now responsible for driving HDR displays and managing applications in an HDR environment.

Plasma 6’s compositor KWin supports the HDR10 standard out of the box, and includes the ability to tonemap traditional SDR applications on HDR screens. This is an important feature because HDR screens are expected to have white points that have very intense absolute luminances — uncomfortably bright if a significant part of the screen is at its maximum output. In traditional SDR, “white” just means however bright the display happens to be; on an HDR screen we have to figure out how bright to make white (like the background of this webpage for example) so that it is not overwhelming.

If KWin detects that your screen can be driven in HDR mode, it will place an “enable HDR” checkbox in your Display Configuration settings. Upon enabling this, it will begin sending an HDR signal to your screen while continuing to perform color management as described above.

This means that your SDR applications should behave as expected, while applications supporting HDR will be able to utilize the higher peak brightness of your display. To make this possible, applications must be able to communicate color space metadata to the compositor. The Wayland project is developing an HDR protocol alongside its color management protocol to make this possible, but this is incomplete at present.

As a replacement, KDE developer Xaver Hugl has implemented a custom protocol that enables HDR capable games to be run on Wayland, with a little hacking. A few other applications like mpv are also capable of HDR in Plasma 6 with Hugl’s custom Vulkan layer. To install this layer and find instructions for getting these applications working, check the VK_hdr_layer project on Github.