Kde wayland for artists: Difference between revisions

From KDE UserBase Wiki
m (copy-editing)
 
(11 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Construction}}
== Introduction ==
 
This page documents support for artist workflows under the Plasma 6 Wayland session, in order to to help artists ascertain what is currently possible and what is in the works.


== Introduction ==
== Support for Graphics Tablets ==
This page is to document information regarding various artists workflows under KDE Wayland. It goal is to help artists ascertain what is currently possible and what is in the works.


== Graphic Tablet support under wayland ==
Support for graphics tablets is provided by the Linux kernel. [https://wayland.freedesktop.org/libinput/doc/latest/what-is-libinput.html Libinput] serves as a driver and support library, allowing you to configure and use input devices on Plasma 6.


The graphic tablets support is provided by the Linux kernel and [https://wayland.freedesktop.org/libinput/doc/latest/what-is-libinput.html libinput] is the library which primarily helps desktop environments as a medium to configure and use input devices on them. There is not need to install xf86-input-wacom like you do on xorg or any other package, most probably your distribution will ship libinput and it will recognize your tablet. If your tablet is not supported by libinput then you might have luck trying out third party user space utilities like [https://opentabletdriver.net/ Open Tablet Driver].
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.


That said most of the tablets from Wacom and Huion have good support on Linux.
If your tablet is not supported by libinput, you might have luck trying out third party user space utilities like [https://opentabletdriver.net/ Open Tablet Driver]. Most tablets from Wacom and Huion have good support on Linux.


If you are satisfied with the default configuration like pressure curves, shortcut mapping for pen buttons then you do not have to do anything but use the tablet.
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.


If you need any configuration then KDE plasma has a new KCM for tablet. It provides a page in the systemsettings application on for configuring your graphic tablet. It is now a part of plasma desktop package [https://invent.kde.org/plasma/plasma-desktop here].
[[File:Graphic_tablet_KCM_as_of_30_November_2023.png|thumb|The Drawing Tablet settings module as of November 2023]]


This new KCM has half of the configuration options and others are still not implemented. Below is a screenshot of how it look as of 30 November 2023 under plasma wayland
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.


[[File:Graphic_tablet_KCM_as_of_30_November_2023.png|550px|center]]
=== Supported features of graphics tablets ===


=== What Works for Graphic tablets ===
* Setting orientation of the tablet
* Setting orientation of the tablet
* Mapping portion or whole of the screen(monitor) to tablet
* Mapping a portion or the whole screen to the tablet surface
* Setting keyboard shortcuts combination (no single modifiers or mouse buttons presses) to the tablet and pen buttons
* 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 mode and Right handed mode
* Switching between left handed and right handed modes
* Setting a target Display
* Setting a target display
* Stylus calibration support (in [https://community.kde.org/Schedules/Plasma_6 Plasma 6.2])
 
=== Currently unsupported features and known issues ===
 
* Mapping only a portion of the tablet area to the screen is [https://bugs.kde.org/show_bug.cgi?id=457703 currently unsupported]. The UI for display mapping and button configuration is [https://bugs.kde.org/show_bug.cgi?id=477750 inferior to the equivalent interface under X11].
 
* There is currently no way to create multiple tablet configuration profiles and switch between them to enable [https://bugs.kde.org/show_bug.cgi?id=477671 multiple workflows].
 
* The KCM [https://bugs.kde.org/show_bug.cgi?id=457705 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, [https://bugs.kde.org/show_bug.cgi?id=477752 there is no way to assign shortcuts to touch rings]. Changing touch ring "mode" - including switching from one set of shortcuts to another - [https://bugs.kde.org/show_bug.cgi?id=477787 is unsupported as well].
 
* Toggling between absolute and relative pixel scaling, called "mouse mode" by Wacom, [https://bugs.kde.org/show_bug.cgi?id=477898 remains unsupported in Wayland].
 
* Tablet pointers use an incorrect cursor when [https://bugs.kde.org/show_bug.cgi?id=477570 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 [https://github.com/eoyilmaz/displaycal-py3 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. 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. Programs that knew how to request the screen profile from colord would do this automatically, and for other programs you would manually import the display profile.
 
[[File:Display_configuration.png|thumb|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'' and named KWin is now responsible for managing your system’s colors.
 
Software that isn’t color managed (including the Plasma desktop itself) will be treated as sRGB, and rendered with that assumption by the compositor on each of your displays.
 
Color managed applications need to tag themselves with color profiles, in order to have KWin perform the appropriate conversion on their behalf. A new protocol is [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 currently under development] to allow applications to communicate this information to the compositor. KWin supports a draft version of this protocol, but in order for color management to work in the programs you use, they must adopt it as well. Once an application has adopted the protocol, there is nothing else 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), switching to Plasma 6 with Wayland is easy.
 
* 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 instead. If you must select a profile for these applications, you can provide them an sRGB profile, as this will mirror the behavior of the KWin compositor.
 
If you rely on applications that use color management '''and''' you work in wide color gamut (WCGs), then you will not currently be able to use the Plasma 6 Wayland session. For example, if you have a screen that targets the [https://en.wikipedia.org/wiki/DCI-P3 Display P3] gamut, and you use edit photos with a target color space of AdobeRGB or view HEIC images taken on your iPhone, you're using wide color gamut.
 
* Popular applications for professional graphic design and photography such as Krita, Inkscape, the GNU Image Manipulation Program, and others do net yet support the Wayland color management protocol.
 
* 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 [https://pointieststick.com/2024/08/16/this-week-in-kde-system-settings-modernization-and-wayland-color-management/ 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.


=== What is yet to be implemented ===
* 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.
* No way to map a portion of the tablet are to the screen - Some people have large tablet and sometime they want to map a portion of the tablet to the monitor - bug report - https://bugs.kde.org/show_bug.cgi?id=457703. Moreover the UI for mapping tablet area and its buttons is slightly inferior to the UI of the same functionality in X11 KCM. - Bug report - https://bugs.kde.org/show_bug.cgi?id=477750


* No way to create multiple profile of the tablet configuration, so that artist can choose different configuration like shortcuts , pen pressure etc for different workflow like inking a comic or doing vector art - Bug report - https://bugs.kde.org/show_bug.cgi?id=477671
* 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.


* No way to fine tune pressure curve of the tablet, various people draw with varying pressure some people draw with heavy hand some use light touch, configuring pressure curve helps artist to get nice lines. - bug report - https://bugs.kde.org/show_bug.cgi?id=457705
* 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.


* Often graphic tablets have a touch strip or ring but on plasma wayland there is no way to assign shortcut to touch rings - bug report - https://bugs.kde.org/show_bug.cgi?id=477752
=== Support for calibration and profiling software ===


* Related to the above some tablets allow users to switch the modes of the touch ring for example you can click a button and change the mode from one set of shortcuts like scrolling to another set of shortcut like changing hue or zooming in and out. but this is not available in plasma wayland - https://bugs.kde.org/show_bug.cgi?id=477787
Since KWin doesn't provide built-in profiling and calibrating software, users must rely on third party software like [https://github.com/eoyilmaz/displaycal-py3 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.


* Creative applications often have use of single modifier shortcuts, artists map this to their pen buttons for example holding ctrl to colour pick while painting but this is not possible on plasma wayland - https://bugs.kde.org/show_bug.cgi?id=461259
When using displayCAL under Wayland, several qualifications are important to keep in mind.


* There is no way to calibrate a display tablet so that there is no wierd offset - https://bugs.kde.org/show_bug.cgi?id=476982 this is in the works and there is an open MR by an awesome KDE contributor but it will probably be in 6.1
<blockquote>
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.


* There is no way to switch between absolute and relative mode of the graphic tablet - bug report - https://bugs.kde.org/show_bug.cgi?id=477898
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%.


* There is no way to assign mouse click presses to pen button as shortcuts, For example you want to change the default and assign a different button on a pen to do middle mouse click to pan the canvas in krita it won't accept middle mouse click as a shortcut- https://bugs.kde.org/show_bug.cgi?id=457636
— Calvin Walton, [https://github.com/eoyilmaz/displaycal-py3/issues/133#issuecomment-1739798592 comment on Github]
</blockquote>


* The pointer for the graphic tablet is a cross in plasma wayland, it doesn't even change to resize handle cursor or any other things depending on the context. So if you want to resize a window with your pen it will be troublesome to use this pointer. - https://bugs.kde.org/show_bug.cgi?id=477570.
With this in mind, several cautions are in order:


== Colour management Support ==
* 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.


On wayland system wide Colour management is handled by the compositor so on KDE it will be handled by kwin. Application might need to interact with kwin to get colour management information about the monitor. Although wayland is fairly ready for everyone it lacks the colour management protocol. This protocol is being discussed and developed right now. And kwin implements some of the draft version of the protocol.The kwin developers are pushing for finalising the protocol however it is not yet finalised and might take some times.
* 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.
You can follow the discussion about this protocol here -https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14


The kwin project has its own issue for tracking colour management and you can follow it here - https://invent.kde.org/plasma/kwin/-/issues/11
* 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 [https://github.com/eoyilmaz/displaycal-py3/issues/130 this issue] for one known problem under Wayland.


=== What works at system level ===
== Color Management for Other Devices ==
* Assigning user generated ICC colour profiles to monitors, although due to application not being ready this may be limited to sRGB. Wide gamut colour profile is technically possible but probably not tested.


=== Application level colour management support ===
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.


Since colour management is fairly new or in its nascent stage application do not yet support the Wayland way of doing colour management. Moreover many if not all creative application (with the exception of one or two) as of today run under Xwayland like krita. Even the application that run natively like under wayland like Inkscape have no way of knowing the monitor profile to utilise that profile in managing on canvas color. It is expected that this should be done through a portal or some other mechanism which is not yet implemented or finalised.  
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.


So one can say that at application level colour management is very limited. If the application is not doing anything then kwin assumes that it is sRGB and the colour is managed according to this assumption.
== High Dynamic Range (HDR) Display Support ==


It might take a while for the application side to catch up to the Wayland way of doing things. There is also not that good communication between the application developers and the people working on Wayland protocol and compositor. At-least from the interaction on the public interaction on the issue tracker and forums it seems like there is a communication gap. We can only hope this gets sorted out soon.
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.


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


There is no colour profiling and calibrating software under KDE. Follow this bug report - https://bugs.kde.org/show_bug.cgi?id=433068 
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 [https://pub.smpte.org/latest/st2084/st2084-2014.pdf 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.


Since Kwin doesn't yet provide a built in profiling and calibrating software instead we have to use third party software like [https://github.com/eoyilmaz/displaycal-py3 display cal], which theoretically works but the support for Wayland is recent so one cannot guarantee the accuracy. There is also issue like no permission to display colour patches on the right monitor for the calibration software like argyll cms or display cal and this is by design on wayland. Display cal is using some [https://github.com/eoyilmaz/displaycal-py3/commit/434d5e88a3f20dc8ecdf2d002a8da876379c448a workaround] in this situation, you can track that issue [ https://github.com/eoyilmaz/displaycal-py3/issues/130 here]
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.


== High Dynamic Range Display (HDR) Support ==
As a replacement, KDE developer [https://zamundaaa.github.io/wayland/2023/12/18/update-on-hdr-and-colormanagement-in-plasma.html 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 [https://github.com/Zamundaaa/VK_hdr_layer VK_hdr_layer] project on Github.

Latest revision as of 06:55, 18 August 2024

Introduction

This page documents support for artist workflows under the Plasma 6 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

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

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. 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. Programs that knew how to request the screen profile from colord would do this automatically, and for other programs you would manually import the display 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 and named KWin is now responsible for managing your system’s colors.

Software that isn’t color managed (including the Plasma desktop itself) will be treated as sRGB, and rendered with that assumption by the compositor on each of your displays.

Color managed applications need to tag themselves with color profiles, in order to have KWin perform the appropriate conversion on their behalf. A new protocol is currently under development to allow applications to communicate this information to the compositor. KWin supports a draft version of this protocol, but in order for color management to work in the programs you use, they must adopt it as well. Once an application has adopted the protocol, there is nothing else 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), switching to Plasma 6 with Wayland is easy.

  • 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 instead. If you must select a profile for these applications, you can provide them an sRGB profile, as this will mirror the behavior of the KWin compositor.

If you rely on applications that use color management and you work in wide color gamut (WCGs), then you will not currently be able to use the Plasma 6 Wayland session. For example, if you have a screen that targets the Display P3 gamut, and you use edit photos with a target color space of AdobeRGB or view HEIC images taken on your iPhone, you're using wide color gamut.

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

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 provide built-in profiling and calibrating software, 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.