Some time ago we reached out to Wesley Gardner because, a bit belatedly, we saw he has published a great book on Krita, titled Draw and Paint Better with Krita.

For krita.org, Wesley wrote an introduction to his book!

Teaching art has been a passion of mine for a long time, and seeing students find their “inner voice” and push through barriers they thought insurmountable is one of the coolest things in the world. In 2021, I was approached to write a “how to digital paint” book, geared towards beginners to digital art, but with the goal of also having enough weight to give intermediate and advanced digital artists some fun exercises as well. Without second thought, I agreed, and knew that Krita would be the focal point of the book. Thus, in 2022, ‘Draw and Paint Better with Krita’ was published worldwide, and has become a sort of “guardian angel” guide for artists around the world, which I’m super humbled by and grateful for.

:

Krita’s everything that I believe digital art is about: Open access, customizable to fit your needs, easy to get started, and impossible to master. There’s always something new to learn in art, and likewise, there’s always something fun to learn in Krita. Whether it’s the various effects you can get with the ever-expanding layer management and adjustments, or the near-infinite pool of incredible custom brushes made by the community, there’s ALWAYS a new way to push yourself to that next level in your journey.

I’ve been a Krita user since Krita 3, and seeing how much it has evolved and expanded in the past few years has been unbelievable! It’s always installed on EVERY machine that I make art on, and is one of my “must-download” softwares the moment I get a new machine. It’s one of those programs that grows with you, and can handle absolutely anything you can throw at it. I’ve produced personal work and art prints, as well as professional client work for the likes of Star Wars, Warhammer 40k, and Riot Games, and the program never breaks a sweat. When I’m stumped on what type of video to make for my YouTube channel, I can always fall back on playing around in Krita, as it’s always a treat to poke around and learn new workflows.

Writing the book on Krita was a no-brainer, as I think learning Krita can help you learn ANY digital painting software, as the workflows are so similar. It’s the perfect entry-point for every artist that wants to work digitally, and it’s the perfect ending point for tenured veterans that need a little bit of “extra spice” to finish off their work and build their brand. If there’s one digital art program every single person needs on their machine, it’s Krita.

For real, what CAN’T Krita do? Go join the forums, be part of the community, and (if you’re financially able to, of course) donate somewhat regularly to the Krita Foundation. They do incredible work, and the fact that Krita’s available on Windows, Mac, AND Linux, for FREE, is still some sort of wizardry I can’t wrap my head around. For the Krita Team: Keep knocking it out of the park, it’s an honor to be a part of the Krita legacy, and for the team, and all artists out there:

Go make cool art.

Life:

Last week we were enjoying springtime, this week winter has made a comeback! Good news on the broken arm front, the infection is gone, so they can finally deal with the broken issue again. I will have a less invasive surgery April 25th to pull the bones back together so they can properly knit back together! If you can spare any change please consider a donation to my continued healing and recovery, or just support my work

• GoFundMe
• Patreon
• Github
• Donorbox

Kubuntu:

While testing Beta I came across some crashy apps ( Namely PIM ) due to apparmor. I have uploaded fixed profiles for kmail, akregator, akonadiconsole, konqueror, tellico

KDE Snaps:

Added sctp support in Qt https://invent.kde.org/neon/snap-packaging/kde-qt6-core-sdk/-/commit/bbcb1dc39044b930ab718c8ffabfa20ccd2b0f75

This will allow me to finish a pyside6 snap and fix FreeCAD build.

Changed build type to Release in the kf6-core24-sdk which will reduce the size of kf6-core24 significantly.

Fixed a few startup errors in kf5-core24 and kf6-core24 snapcraft-desktop-integration.

Soumyadeep fixed wayland icons in https://invent.kde.org/neon/snap-packaging/kf6-core-sdk/-/merge_requests/3

KDE Applications 25.03.90 RC released to –candidate ( I know it says 24.12.3, version won’t be updated until 25.04.0 release )

Kasts core24 fixed in –candidate

Kate now core24 with Breeze theme! –candidate

Neochat: Fixed missing QML and 25.04 dependencies in –candidate

Kdenlive now with Galxnimate animations! –candidate

Digikam 8.6.0 now with scanner support in –stable

Kstars 3.7.6 released to –stable for realz, removed store rejected plugs.

Thanks for stopping by!

Work done so far

Move tracker for PvC game

Implemented the code for tracking the move played by player and computer in bohnenspiel TUI game.

It is achieved using getLastMove method initialized and defined in mankalaengine.h and mankalaengine.cpp. This method returns a pair containing the last moved as int played and the player as Player who made it.

During each iteration of the game loop, the above method is called for both player and computer to retrieve their respective last moves.

The above code in TUI file of bohnenspiel game variant is used to display the move played in the terminal.

The player move is tracked using user.getLastMove() and the computer move is tracked using opponent.getLastMove(). The game loop alternates between the player and the computer, updating the board and tracking moves after each turn. The last moves are printed after each turn. The computer’s move are adjusted by adding 6 to align it’s side of board(move 6-11).

How it works?

1. Player’s Turn:
   • The player select the hole to play.
   • The move is played, and the board is updated.
   • The move is tracked using user.getLastMove().
2. Computer’s Turn:
   • The computer select the hole to play.
   • The move is played, and the board is updated.
   • The move is tracked using opponent.getLastMove().

After each turn the last moves played are displayed.

What’s next

The next goal moving forward is to create a PvP game mode for two different users.

Model/View Drag and Drop in Qt - Part 3

Step 1

Step 2

Step 3

Step 4

class EmailsModel : public QAbstractTableModel
{
    ~~~
    Qt::ItemFlags flags(const QModelIndex &index) const override
    {
        if (!index.isValid())
            return {};
        return Qt::ItemIsEnabled | Qt::ItemIsSelectable | Qt::ItemIsDragEnabled;
    }

    // the default is "copy only", change it
    Qt::DropActions supportedDragActions() const override { return Qt::MoveAction | Qt::CopyAction; }

    QMimeData *mimeData(const QModelIndexList &indexes) const override;

    bool removeRows(int position, int rows, const QModelIndex &parent) override;

bool EmailsModel::removeRows(int position, int rows, const QModelIndex &parent)
{
    beginRemoveRows(parent, position, position + rows - 1);
    for (int row = 0; row < rows; ++row) {
        m_emailFolder->emails.removeAt(position);
    }
    endRemoveRows();
    return true;
}

class FoldersModel : public QAbstractTableModel
{
    ~~~    
    Qt::ItemFlags flags(const QModelIndex &index) const override
    {
        CHECK_flags(index);
        if (!index.isValid())
            return {}; // do not allow dropping between items
        if (index.column() > 0)
            return Qt::ItemIsEnabled | Qt::ItemIsSelectable; // don't drop on other columns
        return Qt::ItemIsEnabled | Qt::ItemIsSelectable | Qt::ItemIsDropEnabled;
    }

    // the default is "copy only", change it
    Qt::DropActions supportedDropActions() const override { return Qt::MoveAction | Qt::CopyAction; }
  
    QStringList mimeTypes() const override { return {QString::fromLatin1(s_emailsMimeType)}; }
  
    bool dropMimeData(const QMimeData *mimeData, Qt::DropAction action, int row, int column, const QModelIndex &parent) override;
};

bool FoldersModel::dropMimeData(const QMimeData *mimeData, Qt::DropAction action, int row, int column, const QModelIndex &parent)
{
    ~~~  // safety checks, see full example code

    EmailFolder *destFolder = folderForIndex(parent);

    const QByteArray encodedData = mimeData->data(s_emailsMimeType);
    QDataStream stream(encodedData);
    ~~~ // code to detect and reject dropping onto the folder currently holding those emails

    while (!stream.atEnd()) {
        QString email;
        stream >> email;
        destFolder->emails.append(email);
    }
    emit dataChanged(parent, parent); // update count

    return true; // let the view handle deletion on the source side by calling removeRows there
}

The post Model/View Drag and Drop in Qt - Part 3 appeared first on KDAB.

In Konsole Layout Automation (part 1), I wrote about how to automate opening Konsole with different tabs that ran different commands. In this post, I'll talk about doing this for layouts.

Inspiration

In the past, I needed to open two connections to the same host over ssh , and change to two different directories. I opened Konsole with a layout that had two panes. Then, Quick Commands allowed me to run a command in each pane to ssh and change to the right directory. This post will outline how to achieve that and more!

Goal: Launch a Konsole window with one tab that has multiple panes which run commands

💡 Note For more detailed instructions on using Konsole, please see the output of konsole --help and take a look at the Command-line Options section of the Konsole Handbook

A layout can save and load a set of panes. Unfortuately, it can't do anything else. We can, however, use profiles and the Quick Commands plugin to make the panes more useful.

Use case: See the output of different commands in the same window. For instance, you could be running htop in one pane and open your favorite editor in another.

Here's an overview of the steps:

• Set up a layout
• Use QuickCommands to run things in the panes

Set up a layout

Unfortunately, the online documentation for Konsole command line options doesn't say much about how to create a layout, or the format of its JSON file. It only mentions the command line flag --layout. Also make a note of -e which allows you to execute a command.

Fortunately, creating the layout is pretty easy. Note that a layout is limited to one tab. It will only save the window splits, nothing else. No profiles, directories, etc.

1. Set up a tab in Konsole with the splits you want it to have
2. Use View -> Save Tab Layout to save it to a .json file. (I personally recommend keeping these in a specific directory so they're easy to find later, and for scripting. I use ~/konsole-layouts).
3. You can then use konsole --layout ~/layout-name.json to load konsole with a tab that has the splits you saved.

Use Quick Commands to do useful things in your layout

As mentioned above, you can only save splits. you can't associate a profile, or run a command directly like you can with the tilix or kitty terminals. This has been requested. In the meantime, an easy thing you can do is load a layout and then load a profile manually in each pane. This is where Quick Commands come in. These are under Plugins - Quick Commands. (If you don't see this, contact your distro / the place you installed Konsole from).

You can use Quick Commands to run a command in each pane. You can also launch a profile (with different colors etc) that runs a command (part 1 showed how these might be used). Note, however, that running konsole itself from here will launch a new Konsole window.

End each command with || return so that you get to a prompt if the command fails.

Examples

htop || return

So, after you've launched Konsole with your layout as described above, you can do this: Go to Plugins -> Show Quick Commands Add commands you'd like to run in this session. Now, focus the pane and run a command.

Using these steps, I can run htop in one pane and nvtop in the other.

After you've gotten familiar with tabs and layouts, you can make a decently powerful Konsole session. Combine these with a shell function, and you can invoke that session very easily.

This is still too manual!

You're right. This post is about automating Konsole and having to click on things is not exactly that. You can use dbus commands in a script to load your tab layout and then run commands in each pane without using Quick Commands.

As we saw in the last post, you can use profiles to customize color schemes and launch commands. We can call those from a script in a layout. The demo scripts used below use dbus, take a look at the docs on scripting Konsole for details.

I'm using the layout file ~/konsole_layouts/monitoring.json for this example. This layout file represents two panes with one vertical split (horizontal orientation describes the panes being horizontally placed):

{
 "Orientation": "Horizontal",
 "Widgets": [
 {
 "SessionRestoreId": 0
 },
 {
 "SessionRestoreId": 0
 }
 ]
}

Here's an example of a simple script using that layout, which will launch fastfetch in one pane and btm in the other:

#!/usr/bin/env bash

# Define the commands to run
cmd1="fastfetch"
cmd2="btm"

# Opens a konsole tab with a saved layout
# Change the path to point to the layout file on your system
# KPID is used for renaming tabs

konsole --hold --layout $HOME/konsole_layouts/monitoring.json & KPID=$!

# Short sleep to let the tab creation complete
sleep 0.5

# Runs commands in Konsole panes
service="$(qdbus | grep -B1 konsole | grep -v -- -- | sort -t"." -k2 -n | tail -n 1)"

qdbus $service /Sessions/1 org.kde.konsole.Session.runCommand "${cmd1}"
qdbus $service /Sessions/2 org.kde.konsole.Session.runCommand "${cmd2}"

# Renames the tabs - optional
qdbus org.kde.konsole-$KPID /Sessions/1 setTitle 1 'System Info'
qdbus org.kde.konsole-$KPID /Sessions/2 setTitle 1 'System Monitor'

What it does:

• Loads a layout with 2 panes, horizontally arranged
• Runs clear and then fastfetch in the left pane; runs btm in the right pane

Wrap-up

That's how you can accomplish opening a number of panes in konsole which run different commands. Using this kind of shortcut at the start of every work / programming session saved a little time every day which adds up over time. The marketing peeps would call it "maximizing efficiencies" or something. I hope some folks find this useful, and come up with many creative ways of making konsole work harder for them.

Known issues and tips

• Running konsole from a Quick Command will open a new window, even if you want to just open a new tab.
• You may see this warning when using runCommand in your scripts. You can ignore it. I wasn't able to find documentation on what the concern is, exactly.

The D-Bus methods sendText/runCommand were just used. There are security concerns about allowing these methods to be public. If desired, these methods can be changed to internal use only by re-compiling Konsole. This warning will only show once for this Konsole instance.

Credits to inspirational sources

• Thanks to the Cool-Konsole-setup repo, where I found an example script for using commands in a layout via qdbus. Note: The scripts in that repo did not work as-is.
• This answer on Ask Ubuntu for improvements on the example scripts.

Hey everyone!!

Welcome to my blog post. I am Roopa Dharshini, a mentee in Season of KDE 2025 for the KEcoLab project. In this blog, I will explain my work in the SoK mentorship program.

Getting Started With SoK

For my proposal I crafted a detailed timeline for each week. With this detailed plan and with the help of my wonderful fellow contributors and mentors, I was able to complete all the work before the end of the mentorship program.

CC-BY-SA-4.0 license.)" src="https://eco.kde.org/blog/images/2025-03-31-roopa-sok25-proposal.png" style="max-width: 100%; height: auto" />

I started by first week working to understanding the project's codebase, studying KECoLab's handbook and existing documentation, setting up a GitLab wiki in the forked repository, and discussing the GitLab wiki's Merge Request (MR) feature. I explored and discussed various technical documentation tools with the mentors. Initially, we had planned to continue with GitLab, but later due to the flexibility of KDE's community wiki, we proceeded with that as our preferred documentation tool.

CC-BY-SA-4.0 license.)" src="https://eco.kde.org/blog/images/2025-03-31-roopa-sok25-usage-scenario.png" style="max-width: 100%; height: auto" />

I got to work creating an outline for the entire technical documentation. Usage scenarios scripts are essential for executing the automation pipeline in KEcolab. So, my fellow mentees and I started our documentation process with usage scenario scripting: we drafted a short page describing it's importance, provided some scripts, and detailed their structure. This documentation is structured in a way that even non-technical contributors are able to follow the guidelines and create their own scripts.

CC-BY-SA-4.0 license.)" src="https://eco.kde.org/blog/images/2025-03-31-roopa-sok25-ci-cd.png" style="max-width: 100%; height: auto" />

After this, I wrote various texts for the technical documentation (CI/CD pipeline, Home Page) of the KEcoLab project. There was a change in the audience for our documentation: initially we focused on the users of KEcoLab, but later we decided to write documentation for both the people who wish to contribute and provide new changes to KEcoLab as well as those who use KEcoLab for their software measurements. This change had us writing in-depth technical documentation for developers who wish to change the code for better efficiency. The CI/CD pipeline is essential for the energy measurement automation in KEcoLab. Writing detailed CI/CD pipeline documentation that explains its use, structure, and job execution was challenging, yet rewarding.

Final Documentation Links

1. User Guide documentation for KEcoLab Users
2. Usage Scenario Script documentation
3. Accessing result documentation for users
4. CI/CD pipeline documentation for contributors
5. Contribution guidelines

How did I apply to Season of KDE?

CC-BY-SA-4.0 license.)" src="https://eco.kde.org/blog/images/2025-03-24-roopa-sok25-proposal.png" style="max-width: 100%; height: auto" />

Season of KDE is a mentorship program that happens every year between January and March. It is a three-month mentorship where mentees will be guided through a project they propose. You start by writing a proposal and timeline to work on from the projects listed on the KDE Ideas page. You tag the mentors in the issue, and they will review your proposal and check whether you are suitable or not. You can checkout my proposal for the KEcoLab project. After review, mentors will hopefully mark your proposal as accepted. And that’s how I got into it!

Challenges I faced

Applying to SoK was not easy for me. I ran into my first challenge when I tried to create a new KDE Invent account. I thought there were some technical issues with the website, so I tried every day to create an account (you are limited to one account creation chance per 24-hour period). After a long wait, I reached out to SoK admin Johnny for help, and he assisted me in creating an account. I was really scared to submit my proposal because there was only one week before the submission deadline, but I trusted my skills and submitted it. So, keep in mind that “it is never too late to apply."

The second challenge was team collaboration. Similar to me, there were 2 other contributors selected for this project. I was brand new to KDE. At first it was hard to communicate with my other contributors, but later on we started to work really well together. Those are the main challenges I faced during my contributions to SoK. Challenges are never an end point; they are a stepping stone to move further.

Thank You Note!

Challenges make the journey worthwhile. Without any challenges, I wouldn’t have known the perks of contributing to KDE in SoK. I take a moment here to thank my wonderful mentors Kieryn, Aakarsh, Karanjot, and Joseph for guiding me throughout this journey. Also, I want to thank my fellow contributors to the project Shubhanshu and Utkarsh for collaborating with me to achieve what we proposed successfully. Finally, I am thankful to the KDE e.V. and the KDE community for supporting us new contributors to the amazing KDE project.

KEcoLab is hosted on Invent. Are you interested in contributing? You can join the Matrix channels Measurement Lab Development and KDE Eco and introduce yourself.

Thank you!

Introduction -

Over the last 10 weeks, I had the opportunity to contribute to MankalaEngine by exploring and integrating new algorithms for gameplay, as well as working on adding the Pallanguli variant to the engine. My journey involved researching about various algorithms like Monte Carlo Tree Search (MCTS), implementing Q-learning, an ML-based approach, and evaluating their performance against the existing algorithms of MankalaEngine. Also assisted in reviewing the implementation of the Pallanguli variant.

Implementing and Testing MCTS

I first explored Monte Carlo Tree Search (MCTS) and implemented it in MankalaEngine. To assess its effectiveness, I tested it against the existing algorithms, such as Minimax and MTDF, which operate at depth 7 before each move.

MCTS Performance Results -

The results was not good enough. This was expected because existing Minimax and MTDF algorithms are strong and operate at depth 7 before each move.

Moving to Machine Learning: Implementing Q-Learning.

Given MCTS's poor performance against strong agents, I explored Machine Learning (ML) techniques, specifically Q-Learning, a reinforcement learning algorithm. After learning its mechanics, I implemented and trained a Q-learning agent in MankalaEngine, testing it against existing algorithms.

Q-Learning Performance Results -

Q-learning showed significant improvement, defeating existing algorithms in most cases. However, it still had weaknesses.

Techniques Explored to Improve Q-Learning Results:

To improve performance, I experimented with the following techniques:

• Using Epsilon decay to balance exploration (random moves) and exploitation (using learned strategies).

• Increased rewards for wins to reinforce successful strategies.

• Training Q-learning against Minimax and MTDF rather than only against itself.

Despite these improvements, Q-learning still could not consistently outperform all existing algorithms.

After these experiments and research, I believe more advanced algorithms like DQN or Double DQN are needed to outperform all existing algorithms. This would also an exciting project for this summer.

Work related to Integration of Pallanguli Variant

Apart from exploring ML algorithms, I also worked on integrating the Pallanguli variant of the Mancala game into MankalaEngine. My contributions included:

• Reviewing Srisharan’s code, suggesting fixes and discussions.

• Creating Merge Request (MR) that allows users to input custom initial counters for Pallanguli.

Conclusion -

This journey has been an incredible learning experience, and I am grateful for the guidance of my mentors, Benson Muite and João Gouveia, who were always there to help.

I look forward to continuing my contributions to the KDE Community, as I truly love the work being done here.

Thank you to the KDE Community for this amazing opportunity!

Many people are, understandably, confused about brightness levels in content creation and consumption - both for SDR and for HDR content. Even people that do content creation as their job sometimes get it really wrong.

Why is there so much bad information about it out there?

Before jumping into the actual topic, I want to emphasize that most people that have gaps in their knowledge about HDR and SDR are not to blame for it. The standards that define colorspaces are usually confusingly written, many don’t paint the full picture, finding the one you actually need can be difficult, some you need to pay for to even read, and generally there is not a lot of well organized and free information about this out there.

When you have basically no information, you just go with what you do know - you see how Microsoft Windows does HDR for example, maybe you take a look at a draft for the sRGB specification or simply the Wikipedia pages, and do the best with what you have. The result is often less than ideal.

Having worked on this stuff for a while now, and having read lots about it from people that actually know what they’re doing, I think I know the topic well enough to clear up some misconceptions, but do keep in mind that my knowledge is limited too, and I may still make mistakes. If you’re sure I got anything wrong, tell me about it!

If you want an entry point for way more information than this blog post provides, check out color-and-hdr.

How brightness works with sRGB

sRGB is the colorspace most content uses today. Despite that, very annoyingly, its specification is not openly available… but there’s a draft version that you can download freely here, which is good enough for this topic.

The (draft) specification defines two things that are important when it comes to brightness:

• a set of reference display conditions
• a set of reference viewing conditions (I’ll call that “viewing environment” from here on)

The reference display conditions are seemingly quite straight forward. The display luminance is 80cd/m², we have a whitepoint of D65, and a transfer function. Transfer functions describe how to calculate the output luminance from the encoded values of an image, and with sRGB that’s

Y = X ^ 2.2

where Y is the relative luminance on the display, and X is the relative luminance on the input.

The viewing environment has a few more parameters, but it’s conceptually not difficult to understand: It describes how bright your environment is, what color temperature the lights in your room have, and how much your display reflects the environment at you.

How to create sRGB content “correctly”?

The assumption that many people take from the specification is that you should calibrate your display to 80cd/m². On its own, that information is completely wrong!

It’s obvious when you think about how end users actually view content: They set the brightness level of the display to what they’re comfortable with in the current environment. You make the display really bright when you’re outside, less bright when in a normally lit room, and even darker than that when the lights are off.

The part that’s missing with just calibrating the display to some luminance level is that you must take the viewing environment into account. Either you set up the sRGB reference viewing environment (with measurements!)… or you just don’t. When you create content, in most cases you should do exactly the same thing as the person that will consume the content does: Just set the brightness to what’s comfortable in the environment you’re in. It still helps to keep your viewing environment mostly fixed of course, lots of brightness changes mean you’re constantly readjusting and that’s not good.

There’s another big thing to take into account for sRGB, which is its confusing transfer function.

The sRGB transfer function

The sRGB specification doesn’t just define a transfer function for the display, but it also defines a second transfer function. This sRGB piece-wise transfer function is

if X < 0.04045: Y = X / 12.92
else: Y = ((X + 0.055) / 1.055)^2.4

and it’s slightly different from gamma 2.2 in that it has that linear bit for the very dark area.

The purpose of this transfer function is to optimize encoding of dark parts of the image - with 8 bits per color, gamma 2.2 becomes really small in the lowest few values. 1/255 for example results in roughly 0.0000051 with gamma 2.2, and 0.0003035 with the sRGB piece-wise transfer function.

This difference might sound insignificant, but it is noticeable. The most well known place of where the wrong transfer function is used is Microsoft Windows: When you enable HDR in Windows, it uses the piece-wise transfer function for sRGB content, instead of the gamma 2.2 transfer function that which your display uses in SDR mode. The result is that dark areas of SDR games and videos are brighter than they should be, and look “washed out”.

So when should you use the sRGB piece-wise transfer function? So far, I don’t know of any case where you should, outside of working around that Windows problem in your application… I’m also only concerned with displaying images though, and not editing or creating them, so take that with a grain of salt.

How brightness works with HDR

Most HDR content uses the SMPTE ST 2084 transfer function. The specification for this is freely available here.

SMPTE ST 2084 is a bit different from the sRGB spec, in that it only defines a transfer function but no complete colorspace or viewing environment. That transfer function is the Perceptual Quantizer (PQ): It tries to compress luminance levels in a way that matches how sensitive human eyes are in specific luminance ranges, and it’s defined in absolute luminance - a PQ value of 0.0 means <= 0.005cd/m², and 1.0 maps to 10000 cd/m².

The missing parts are defined by different specifications, rec.2100 and BT.2408. More specifically, rec.2100 uses the BT.2020 primaries with the PQ transfer function (or the HLG transfer function, but we’ll ignore that here) and a recommended viewing environment for such HDR content:

BT.2408 expands on that with an HDR reference white and graphics white, at 203cd/m². This is mostly meant for the context of broadcasts, referring with “graphics” to logos or subtitles in the video stream.

Despite the transfer function being “absolute”, just like with sRGB, the luminance numbers don’t mean anything in isolation. When displaying HDR content, just like with SDR, we need to take the viewing environment into account, and adjust luminance levels accordingly.

How is this handled in Wayland?

Every transfer function in the color management protocol has reference display conditions and a viewing environment attached to it, defined by a few parameters. Most relevant for this topic are

• a reference luminance, also known as HDR reference white, graphics white or SDR white
• minimum and maximum mastering luminances, basically how dark and bright the display the content was made for can go

When content is displayed on the screen, the compositor translates between the viewing environment of the content, and the viewing environment of the user. While we don’t usually have full knowledge of what exactly that viewing environment is like, the brightness slider in KDE Plasma provides a very good approximation by configuring the reference luminance to be used for content on the display. The calculation for this brightness adjustment is rather simple, in linear space you just do

output = input * output_reference / input_reference

You can configure the maximum reference luminance (brightness slider at 100%) with the “Maximum SDR Brightness” in the display settings of Plasma 6.3. The minimum and maximum luminance your display can achieve can only be configured with the kscreen-doctor command line tool right now, but an easy to use calibration utility for this is nearly finished (and the default values are usually fine too).

In general, this system is working really well… with one rather big exception.

HDR in Windows games

As mentioned before, Windows in HDR mode does sRGB wrong, but the story with HDR content is kind of worse.

When you use Windows 11 on a desktop monitor and enable HDR, you get an “SDR content brightness” slider in the settings - treating HDR content as something completely separate that’s somehow independent of the viewing environment, and that you cannot adjust the brightness of. With laptop displays however, you get a normal brightness slider, which applies to both SDR and HDR content.

The vast majority of Windows games expect the desktop monitor case: Static, never changing luminance levels, which are displayed on the screen without any adjustments whatsoever. Windows also didn’t have a built-in HDR calibration tool until Windows 11, so nearly every Windows game ships with its own HDR calibration settings and completely ignores system settings. This doesn’t just cause issues for Windows 11 laptops of course, but also for playing these same games with HDR on Linux.

Until Plasma 6.2, we worked around that, also mostly not doing brightness adjustments, and the result was that those HDR calibration settings in games worked basically like on Windows. However, these workarounds broke Linux native applications that want to mix HDR and SDR in their own windows, made tone mapping worse, and blocked features like HDR on “SDR” laptop displays, so in Plasma 6.3 we had to drop them.

This doesn’t mean you can’t play Windows games with HDR in 6.3 anymore, you just have to adjust their configuration to match the changed brightness levels. In most cases, this means you set the HDR paper white in games to 203cd/m², and then set the maximum luminance with the game’s configuration screen, like this one from Baldur’s Gate 3:

How to implement good HDR

After ranting about how Windows games do it wrong, I should end this blog post by also explaining how to do it right. I will skip most of the implementation details, but on a high level if you’re implementing HDR in a Wayland native application or toolkit, you should

• use the Wayland color management protocol
• get the capabilities of the compositor and/or graphics driver, specifically the transfer functions they support
• get the preferred image description from the compositor, and the luminances you’re supposed to target from that. When using these luminance values, keep in mind that reference luminance adjustment the compositor will do!
• every time the preferred image description changes, get the new one and adjust your application to it
• now render for these parameters, and set the image description you actually ended up targeting on the surface, either through Vulkan or with the Wayland protocol (not both at the same time!)
• SDR things, like user interfaces in games, should use the reference luminance too
• if your application has some need to differentiate between “SDR” and “HDR” displays (to change the buffer format for example), you can do so by checking if the maximum mastering luminance is greater than the reference luminance
• now you can, and really should drop all HDR settings from your application. If HDR has a performance penalty in your application, a toggle to limit the app to SDR could still be useful, but everything else should be completely automatic and the user should not be bothered with calibration screens or similar annoyances