Jakob Petsovits on KDE Blogs

Gestures in Graz, and beyond

Jakob Petsovits — Sun, 03 May 2026 09:55:00 +0000

KDE's Mega Sprint 2026 in Graz brought a group of about 20 KDE contributors together in early April, to discuss technical challenges, make decisions, and get stuff done. With travel support from KDE e.V. (thanks to your donations), I was able to join the group there.

Other blogs have reported on their experiences of what happened in Graz: Kieryn Darkwater, Albert Astals Cid, Kristen McWilliam, Volker Krause, and Raresh Rus. A large variety of topics were on the agenda, people were wearing multiple hats to help each other out.

I, on the other hand, went to Graz with one sole purpose: figure out the best way to merge gesture customization.

Dude, what's taking you so long

Quick recap. Since NLnet approved a grant last year, we've published requirements, designed settings UIs, proposed config file formats, ported my earlier mouse gesture prototype to KWin, and presented at Akademy 2025. Then I got injured for a while, hit a slump through the fall and winter, and didn't make much progress until more recently.

Meanwhile, as an actual Plasma user, you have benefited from exactly none of this prep work. For example, a representative sentiment from the comment section of Brodie Robertson's recent Plasma 6.7 upcoming features video:

Yet again it looks like configurable touchpad gestures have slipped....

To be fair, we haven't actually promised any particular Plasma release for this to land in. But I get it. It's been weighing on me probably harder than it's been weighing on you. So I finally emerged from the slump with a set of experimental patches that allowed real-time ("one to one") gestures like Overview to be reassigned to a different gesture via config file options.

Quick architectural primer

There are several KDE components that work together to handle keyboard shortcuts:

KGlobalAccel: This KDE Framework is used by an app or desktop component to register actions and their preferred global shortcuts. KGlobalAccel doesn't actually do much by itself, it just sends requests to a background service (via D-Bus) and tells the app what shortcut actually got assigned for each action. Then it just waits for a signal from the background service that the shortcut was pressed and the action should be performed.

KGlobalAccelD: This is the background service! Part of any Plasma desktop. It listens for global shortcut requests from apps, looks for additional shortcuts in *.desktop files, and reads from and writes to ~/.config/kglobalshortcutsrc to manage shortcut assignments. It can check if a given key combination will trigger a registered action. If it does, it tells the corresponding app to perform the action. On Wayland, KGlobalAccelD is embedded into KWin, giving KWin access to functionality that isn't available over D-Bus.

KWin: Plasma's compositor which we all know and love. It manages windows and puts their contents on screen, but it also has exclusive access to libinput on Wayland. So any key presses, mouse clicks, touch taps, and pointer movement will go through KWin. Most of these just get relayed to the current app. But some of them are intercepted. For global shortcuts, KWin asks its KGlobalAccelD service to check if it should eat up the shortcut and fire a global shortcut instead of sending it to the currently focused app.

System Settings / "Shortcuts" page: An independent app that asks the KGlobalAccelD service for all components with registered shortcut actions. If the user changes a shortcut assignment, it tells the KGlobalAccelD service about it. As a result, KGlobalAccelD notifies the app that its shortcut has changed.

XDG Desktop Portal KDE: Only tangentially involved. It implements the Global Shortcuts portal, so that any app can register global shortcuts, even if they aren't using KDE Frameworks. All it does is to translate an app's portal requests to requests for KGlobalAccelD.

The consensus is that gestures are much like keyboard shortcuts, so gesture configuration should be implemented in similar ways, using the same components. There are important differences of course. How to deal with those isn't quite trivial. That's where sprint discussions come in.

Back to Graz

Having a functional prototype is a good start, but it's still a couple of steps removed from getting it merged into Plasma. I arrived with a number of technical questions to hash out the exact plan and get agreement. All the minutious details can be found in the sprint notes wiki page, but the short version is that the implementation plans became very clear. There were three breakthroughs in particular:

We don't need to expose gesture details through KGlobalAccel: System Settings can link against KGlobalAccelD directly, so we can put the new trigger class in there without worrying about backwards compatiblility for apps.
Natalie, Nate, Kristen and I sat down for a long UX design session, improving on our previous UX proposal together.
Nicolas Fella provided wise advice on config syntax, leading to a better trade-off between readability, clean code, and migration concerns.

Xaver Hugl deserves a special mention, he was generous with all the other technical questions that I kept pestering him about.

Of course I also got involved in a few other discussions, as well as daily dinner outings. It's a good group. But you've read about this on other blogs already, so I won't bore you except with a few more pictures.

Proof I was there

I bought an amigurumi Konqi

One of many food outings

Walking to a rustic restaurant on a hill

Snackies

Konqi at Linuxtage Graz

I spent the remainder of April improving my previous patches. The result is a series of MRs that are finally ready for code review by KWin and KF6 maintainers (1, 2, 3, 4, 5). This will allow assigning touchpad and touchscreen gestures for global actions by editing the kglobalshortcutsrc config file. Schedules were tight, so this didn't make the cut for Plasma 6.7 anymore. Let's see if we can get it into 6.8 though.

Based on this work, my work-in-progress changes to support ~~mouse gestures~~ ~~stroke gestures~~ line shape gestures have been improved as well (1, 2). Autotests and more code polish are needed before this can go into code review, but it's now quite functional: path simplification, shape recognition, action configuration, and a neat little visualization effect are all in place.

Other recent input highlights

Plasma Keyboard was also heavily discussed in Graz, spearheaded by Kristen who put some serious polishing work into it. Kristen introduced a long-press diacritic selection pop-up for Plasma 6.7, a killer feature in my opinion. Meanwhile, on a different continent, Devin Lin has been hard at work to prepare an architectural overhaul of Plasma Keyboard, which would facilitate much-requested improvements to the on-screen keyboard experience (this won't make it into 6.7 though).

Quinten Kock's changes to make touchpad pinch zoom gestures work in Okular are now available with the recent KDE Gear 26.04 release. This bug was pointed out in the discussion on our Input Goal proposal, all the way back in 2024, so it's great to see it fixed. If you're a developer, have a look at the commit and use QNativeGesture events to support touchpad pinch. Shout-out also to Taufeeque Sifat, who's been improving Okular's text selection behavior including triple-click line selection.

Kai Uwe Broulik modernized the code for mouse and touchpad settings pages. This is not a user-visible change, but future changes to these settings become easier thanks to Kai Uwe's work. I'm excited because it paves the way to a unified Mouse & Touchpad settings page in future releases. Alexander Wilms tweaked System Settings to hide Mouse, Touchpad, and Game Controller settings pages when no such devices are connected. Also notable is work on a custom pointer acceleration curve editor, which is not ready to ship yet but hopefully can get there eventually.

Joshua Goins added an option for the stylus cursor to stay in sync with the mouse pointer. David Redondo fixed the stylus button assignment lines looking weird in the Drawing Tablet page in System Settings.

Vlad Zahorodnii added support for libinput plugins to KWin, allowing technical users to work around otherwise unfixable input hardware quirks. Xuetian Weng and Nicolas Fella improved the behavior of key repeats for input methods and screen readers. David Edmundson fixed an issue with pointer positions for mirrored touchscreen displays.

Thanks to everyone who has worked on KDE's Input Goal in the past! At this year's Akademy in Graz, we should see a new set of goals elected, so we're in the final stretch for this one.

Onward to Germany

I wrote this blog post while riding a long-distance train, on the way to another gesture customization mini-sprint with Natalie. The plan is to focus on implementing the new settings pages that will let regular users reassign (or unassign) gestures. Thanks again to KDE e.V. for travel support for another week of in-person collaboration. Let's see how much stuff we can get squared away - it's not just settings forms, but more infrastructure on the KWin and KGlobalAccelD side is also still needed to make everything fit together.

There will be another blog post to follow up on this later. Until then!

I didn't think I'd be at Akademy 2025

Jakob Petsovits — Mon, 08 Dec 2025 00:30:00 +0000

The attentive reader will note that yes, Akademy happened in September already. Not the most prolific blogger. Not the most prolific contributor either. But I had already drafted much of this post two months ago, so let's get it out the door. I'll cut all the paragraphs about fun social outings and focus on recapping stuff related to our Input Goal.

A special thank-you to Farid, of Kdenlive and KDE Goals coordination fame, who convinced me to take the trek when I thought perhaps I shouldn't cross the Atlantic twice in a year. I'm glad I went, tons of great sessions and conversations. Powered by your donations, KDE e.V. supported my travel costs and made it possible for me to coordinate with many KDE people in person. Thank you. Yes, you! Anyway.

Talking input

I met my fellow Input Goal co-initiator Gernot (Duha on Matrix) in person for the first time. Together, and alongside reports on the other KDE goals, we delivered our presentation summarizing one year of input improvements. The KDE community made some excellent progress since the goal was chosen, thanks to everyone who contributed towards it! At the same time, there is more work to do and we'd love to see further contributions. Watch the talk for more details.

Our third Input Goal champion, Joshua Goins, had so much to report on improvements for drawing tablet users that he held an entire presentation on that particular topic.

One particular highlight for me was running into Dorota. She has been pushing for improvements to Wayland's input method protocols and had joined our input handling community on Matrix over the past year. Listening to Dorota's cross-desktop experience and plans was super interesting, and I was happy to see her coordinate with KWin maintainers over the course of Akademy. In the time since, some of Dorota's work was included in the latest upstream release of Wayland Protocols as experimental addition. Hopefully this will be further refined and standardized over time.

Andy Betts sat down with me to discuss the UI designs for touchpad gesture customization, following earlier back-and-forth with Natalie and Nate over the summer. Xaver Hugl provided some great feedback at Akademy about my ongoing patch series to implement stroke gesture support in KWin. He also proposed a change that will help with integrating config file support for gesture customization into KWin. This is all still in the works - full disclosure, I've been having somewhat of a hard time recently for unrelated reasons. It now has path simplification (for performance reasons) plus a nice stroke drawing visualization, but still lacking tests and such. Christmas time seems as good a time as any to pick up some slack and push this forward.

In more exciting news, KDE's new on-screen keyboard has seen a significant amount of work in the last few months. Aleix Pol's initial prototype for Plasma Keyboard was supercharged by Devin Lin, who also made it to Akademy but had to take off early. We decided to release Plasma Keyboard independently first, then integrating it into regular Plasma releases in 2026. This 0.1 preview release is now available, you can check if your distribution already ships it, or you can grab the nightly Plasma Keyboard Flatpak to test its latest state. Yes, even input methods will run just fine as Flatpaks.

Meanwhile, somewhere far away across the ocean, a remote partipant was going full steam ahead on another important piece in the input handling puzzle.

GSoC project: Game controller support in KWin

For this year's Google Summer of Code, Yelsin Sepulveda was accepted to improve game controller support in KWin with mentorship by Xaver Hugl and myself. After a strong start, Yelsin was forced to delay the second part of his project due to personal circumstance and Google did not agree to a deadline extension. However! With an excellent work ethic, Yelsin still continued to work on the project and brought it to completion regardless of Google's official approval. The result is an opt-in KWin plugin that's close to getting merged, and will:

Make KWin aware of game controllers in the first place,
Prevent system sleep on controller activity,
Emulate mouse and keyboard input when no other game (or app) uses the controller,
Deal with the Steam Controller's idiosyncratic "Lizard Mode".
Provide the foundation for future game controller customization in Plasma.

From the KDE side, we consider this GSoC project a resounding success. If you missed Yelsin's own posts on Planet KDE, his blog posts from mid September and early October cover a lot more detail.

Other exciting developments

Some presentations and conversations that I found particularly compelling, not focused on input.

Thanks to Bhushan Shah, Plasma now knows what made your system wake up from system sleep. Building on this, power management primarily for Plasma Mobile but also Plasma Desktop can improve even further, including the potential for scheduled background tasks and going right back to sleep.

Linux distros have been kind to KDE this year. Neal Gompa presented the Fedora KDE SIG's long-term efforts to ship a premium Plasma experience. Terrific work from these folks, this is now my current favorite distro suggestion for friends & family. Furthermore, Harald Sitter presented the Alpha release of KDE Linux, now happily chugging along on its way to becoming a Beta. This is what I hope to install on my parents' laptops one day. I took a banana from Harald in return for promising that I'll test it out myself. Didn't say when; nonetheless, the promise stands.

I was not expecting to find myself talking to GNOME contributors at Akademy, but Lorenz Wildberg from the GNOME Foundation's Board of Directors was a super interesting conversation partner. Long story short, both GNOME and KDE know about their respective shortcomings and are trying to learn from each other's experiences. Sometimes by adopting things that work, sometimes by taking a different route, sometimes just by focusing on our existing strengths and building on those. Either way, listening and reflecting will beat low-effort snark anytime. SDK evolution, contributor onboarding, governance, fun times.

Looking back and ahead

Yes, I lost a few weeks from getting a back injury soon after Akademy. The good news is that it's pretty much all healed at this point. But my contribution habits have remained out of whack since. I'm hoping to get this back on track asap, because I also really want to help KDE to reach the inflection point. Gamers, governments and many more people have something to gain if the Linux desktop breaks out of its niche into the mainstream. The tech industry has been disappointing to me on so many fronts. This here, though, is something I'm excited to see happening.

Gesture customization mini-sprint

Jakob Petsovits — Thu, 12 Jun 2025 16:30:00 +0000

To briefly recap, Natalie Clarius and I applied for an NLnet grant to improve gesture support in Plasma, and they accepted our project proposal. We thought it would be a good idea to meet in person and workshop this topic from morning to evening for three days in a row. Props to Natalie taking the trip from far away in Germany to my parents' place, where we were kindly hosted and deliciously fed.

Our project plan starts with me adding stroke gesture support to KWin in the first place, while Natalie works on making multi-touch gestures customizable. Divvying up the work along these lines allows us to make progress independently without being blocked on each other's work too often. But of course there is quite a bit of overlap, which is why we applied to NLnet together as a single project.

The common thread is that both kinds of gestures can result in similar actions being triggered, for example:

Showing Plasma's Window Overview
Starting an app / running a custom command
Invoking an action inside a running app

So if we want to avoid duplicating lots of code, we'll want a common way to assign actions to a gesture. We need to know what to store in a config file, how Plasma code will make use of it, and how System Settings can provide a user interface that makes sense to most people. These are the topics we focused on. Time always runs out faster than you'd like, ya gotta make it count.

Three days in a nutshell

Getting to results is an iterative process. You start with some ideas for a good user experience (UX) and make your way to the required config data, or you start with config data and make your way to actual code, or you hit a wall and start from the other end going from code to UX until you hit another wall again. Rinse and repeat until you like it well enough to ship it.

On day 1, we:

Explored some code together, primarily in:
- KWin, which recognizes gestures;
- KGlobalAccelD, which manages global shortcut configurations;
- the KGlobalAccel framework, which asks KGlobalAccelD to to register a global shortcut,
- and the Shortcuts page in System Settings, a.k.a. kcm_keys.
Figured out why Natalie's KWin session wouldn't produce systemd logs.
- (Answer: a leftover config entry.)
Collected a comprehensive list of gestures (and gesture variants) to support.

On day 2, we:

Collected a broad list of actions (and action types) to invoke when a gesture is triggered.
Sketched out UI concepts for configuring gestures.
Weren't quite satisfied, came up with a different design which we like better.
Discussed how we can automatically use one-to-one gesture tracking when an assigned action supports it.
Drafted a config file format to associate (gesture) triggers with actions.

On day 3, we:

Drafted a competing config file format which adds the same data to the existing kglobalshortcutsrc file instead.
Reviewed existing gesture assignments and proposals.
Created a table with proposed default gesture assignments (to be used once gestures are configurable).
Collected remaining questions that we didn't get to.

What I just wrote is a lie, of course. I needed to break up the long bullet point list into smaller sections. In reality we jumped back and forth across all of these topics in order to reach some sort of conclusion at the end. Fortunately, we make for a pretty good team and managed to answer a good amount of questions together. We even managed to make time for ice cream and owl spottings along the way.

Since you asked for it, here's a picture of Natalie and I drawing multi-touch gestures in the air.

Next up in gestures

So there are some good ideas, we need to make them real. Since the sprint, I've been trying my hand on more detailed mockups for our rough design sketches. This always raises a few more issues, which we want to tackle before asking for opinions from KWin maintainers and Plasma's design community. There isn't much to share with the community yet, but we'll involve other contributors before too long.

Likewise, my first KWin MR for stroke gesture infrastructure is not quite there yet, but it's getting closer. The first milestone will be to make it possible for someone to provide stroke gesture actions. The second milestone will be for Plasma/KWin to provide stroke gesture actions by itself and offer a nice user interface for it.

Baby steps. Keep chiseling away at it and trust that you'll create something decent eventually. This is not even among the largest efforts in KDE, and yet there are numerous pieces to fit and tasks to tackle. Sometimes I'm frankly in awe of communities like KDE that manage to maintain a massive codebase together, with very little overhead, through sheer dedication and skill. Those donations don't go to waste.

At this point I would also like to apologize to anyone who was looking for reviews or other support from me elsewhere in Plasma (notably, PowerDevil) which I haven't helped with. I get stressed when having to divide my time and focus between different tasks, so I tend to avoid it, in the knowledge that someone or something will be left wanting. I greatly admire people who wear lots of different hats simultaneously, and it would surely be so nice to have the aptitude for that, but it kills me so I have to pick one battle at a time.

Right now, that's gestures. Soon, a little bit of travel. Then gestures again. Once that's done, we'll see what needs work most urgently or importantly.

Take care & till next time!

Input handling in spring 2025

Jakob Petsovits — Wed, 14 May 2025 12:25:00 +0000

Since Akademy 2024, input handling improvements have been one of three KDE Goals with myself as a co-instigator. You may be wondering why you didn't see a series of dedicated blog posts on this topic, which I had hoped to write. Instead of taking accountability for a longer absence from Planet KDE, here's a quick recap of what's noteworthy and exciting right now.

Input improvements in KDE Plasma 6.4

Plasma 6.4 is scheduled to be released on June 17, 2025. The "soft feature freeze" is now in effect, which means we pretty much know which major changes will be included, only polish and bug-fixing work remains. On the input front, you can look forward to some quality of life improvements:

Nicolas Fella added an option to use a graphics drawing tablet in "Mouse" mode, also known as "relative mode". This allows you to use the stylus on your drawing tablet like you would use a finger on a laptop's touchpad.

Joshua Goins keeps updating his Art on Wayland website to keep track of current and past drawing tablet improvements. For this release, the Drawing Tablet settings page will now ask for confirmation after re-calibrating your device. He also added a visualization of pen buttons to the settings page, to make it clear which button you're configuring:

Xaver Hugl added a 3-finger pinch gesture for the desktop zoom accessibility feature, which is in addition to Ctrl+Meta+scroll or Meta-"+" / Meta-"-".

Nicolas Fella also implemented the accessibility feature called MouseKeys on Wayland. This lets you move the mouse pointer using numpad keys, and can be enabled in the Accessibility settings page.

Sebastian Parborg added an option to set "move file" as the default drag & drop behavior. This applies across all KDE software. By default, dropping a file in a different folder will continue to ask if it should be moved, copied or linked.

Christoph Wolk in particular just keeps fixing tons of bugs, including many input handling improvements. He's been tackling keyboard navigation issues, scrolling bugs, mouse hover, pasting, in all kinds of widgets and settings and apps. The list just goes on, here are some links from just the last two or so months: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. (There's more but you get the gist.)

Of course others are also actively fixing issues, like Akseli Lahtinen for custom tiling keyboard shortcuts and Dolphin file renaming. I'm frankly not able to keep up with everyone's contributions, but keep following This Week in Plasma to learn about the most notable ones.

I myself don't have much to show for Plasma 6.4. All my hopes for personally making an impact are staked on future work. I did, however, ask some very nice people if they're open to mentor projects within GSoC 2025. It appears this might pay off.

Funding for input handling improvements

Nate Graham keeps pointing out that we need more paid developers working on KDE software. Here are some popular ways to make this happen:

Donate to KDE e.V. to help with important infrastructure and engineering work
Get paid by companies like Valve, or governments, that want to use & improve KDE tech
Pay yourself with your hard-earned retirement income, then work on what you think is most important
Apply for grants from public benefit foundations and corporate initiatives

On that last bullet point, we recently received some nice funding commitments.

Google is perhaps best known for its repeated abuse of market power, getting convicted for huge fines only to do it again in a slightly different form. They also run a program called Google Summer of Code (GSoC), which is more positive. Every year, numerous students receive a stipend to write Free & Open Source code over the summer, to the benefit of organizations like KDE, mentored by existing developers from the community. On May 8, Google announced the accepted projects for this year. KDE was assigned 15 student projects across a variety of apps and infrastructure efforts. One of these is particularly relevant to our Input Goal.

Starting in June, Yelsin 'yorisoft' Sepulveda will work on improving game controller support in KWin. Yelsin jumped right into the community by asking great questions on Matrix, learned about KDE development by getting several changes merged into Angelfish (KDE's mobile-friendly web browser), and already published an introductory blog post with more details about the project. We're excited to mentor Yelsin and get one of the oldest open Plasma bugs fixed in the process.

NLnet Foundation is an organization that supports open software, open hardware, open data and open standards. At Akademy 2024, Jos van den Oever of NLnet held a talk and encouraged KDE contributors to apply for funding there and elsewhere. Unlike many other granting organizations, NLnet allows individuals to apply for comparatively small grants with very limited bureaucracy, between 5,000 and 50,000 EUR for first-time applicants. Last year, they already supported various improvements in accessibility and drawing tablet support in Plasma.

Natalie Clarius and I applied to NLnet following Akademy 2024. Our project would make multi-touch gestures configurable through System Settings, as well as implement stroke gestures (a.k.a. mouse gestures) for Plasma on Wayland. In April this year, NLnet approved this project together with many other open source initiatives. We've seen a lot of user requests for this functionality, so I'm happy to work on upstreaming this functionality going forward. We're currently ramping up our efforts - stay tuned for actual merge requests and UI designs.

What's also great is InputActions by taj-ny, which is a third-party plugin for KWin that provides customization for multi-touch gestures via text file. Its next release should include stroke gesture support as well. I'm glad that my prototype from last year was useful as a starting point for this. Getting code into upstream KWin and System Settings requires a different approach though, so it still makes sense for the NLnet project to go ahead.

NLnet approved a second KDE-related grant in the same batch, for Accessible KDE File Management by diligent Dolphin maintainer Felix Ernst. In addition to targeted improvements for Dolphin, this project will also benefit the KDE-wide Open/Save dialog, as well as settings for editing shortcuts. Felix with prior experience in accessibility and (obviously) Dolphin is ideally suited for this work.

You may be able to get NLnet funding too. Primary requirements:

Expertise in a given area of the KDE codebase that you want to improve.
Patience to sit down and write a detailed project plan.
Flexibility to wait for up to half a year for confirmation.

Note: Like all such foundations, NLnet has some favorite topics including mobile, accessibility, or federated internet infrastructure. If you're interested in this kind of funding for KDE work, feel free to ask me about more details.

Input at the Plasma Sprint

In late April I dropped by at the recent Plasma Sprint 2025 in Graz, which you may have seen in other posts on Planet KDE already. Among many other topics, we briefly discussed the direction of further input-related developments.

Previously, Xuetian Weng (a.k.a. csslayer, the long-term maintainer of the fcitx5 input method framework) proposed a unified way to manage keyboard layout, input methods, and other input related tools. The gist of the proposal is that each input method (IM) would be associated to a keyboard layout in System Settings. In the linked issue, he argues that this is a better fit for Plasma than the approaches of other platforms for configuring language, layout and input methods. I briefly presented Xuetian's proposal at the Sprint and there was a general consensus that this is a sensible way forward.

There was a question about how to deal with devices that don't have a keyboard connected to begin with. We considered some options and compared our thoughts with the actual keyboard hot-plugging behavior of a sprint attendees' Android phone. Same conclusion either way: each connected keyboard should correspond to a separate layout/IM selection, and the absence of a keyboard will likewise correspond to its own input method. Multiple input devices can be supported by switching configurations upon key-press or (dis)connect events. If we can implement this, it should turn out more versatile and still simpler than Plasma's current settings.

We also discussed the virtual keyboard prototype plasma-keyboard and its most important blockers for getting included in Plasma Desktop / Plasma Mobile. It looks like the major concerns have been captured in the issue queue already, so what's needed now is a developer to buckle down and fix them one by one. Also, testing in more languages.

KDE Needs You!

Lots of movement overall. That said, not all of these plans have someone actively working on it. We really do need more hands on deck if we want the Input Goal proposal to be a smashing success. If you are interested to work with the community on input handling, stipend or not, we can help you to help KDE. Drop by in #kde-input:kde.org on Matrix if you need mentorship to guide your contributions, MR reviews to get your patches landed, or any other kind of support.

Here's a small selection of efforts that would really benefit from your development chops:

Test and improve plasma-keyboard so we can ship it with Plasma.
Make Xuetian's proposal for unified keyboard layout and input method settings a reality. This can be split into smaller tasks:
- Settings page changes
- Quick-switching between input methods
- Adapting fcitx5
Pave the way for speech-to-text, emoji input, and other small input helpers.
Confirm and/or fix any bug from this long list.
Anything input-related that excites you!

Let's get these gaps filled. Until next time. And don't forget to drop by at Akademy 2025 in Berlin for more Input Goal discussions!

Power, input & people at Akademy 2024

Jakob Petsovits — Wed, 18 Sep 2024 00:00:00 +0000

Contrary to popular belief, Akademy 2024 was not my first Akademy. KDE seems to keep tagged faces from Akademy group photos around, so I stumbled over some vintage pictures of me in 2006 (Glasgow) and 2007 (Dublin). At the time, I was an utter greenhorn with big dreams, vague plans, and a fair bit of social anxiety.

And then I disappeared for 15 years, but now it's time for a new shot. This time around, I'm a little less green (rather starting to grey a little) and had a surprising amount of stuff to discuss with various KDE collaborators. Boy, is there no end of interesting people and discussion topics to be had at Akademy.

"Oh, you're the PowerDevil guy"

You're not wrong, I've been contributing to that for the past year. As such, one highlight for me was to meet KDE's hardware integration contractor Natalie Clarius in person and sync up on all things power-related.

Natalie presented a short talk and hosted a BoF session ("Birds of a Feather", a.k.a. workshop) about power management topics. We had a good crowd of developers in attendance, clearing up the direction of several outstanding items.

Power management in Plasma desktops is in decent shape overall. One of the bigger remaining topics is (re)storing battery charge limits across reboots, for laptops whose firmware doesn't remember those settings. There is a way forward that involves making use of the cross-desktop UPower service and its new charge limit extensions. This will give us the restoring feature for free, but we have to add some extra functionality to make sure that charge threshold customization remains possible for Plasma users after switching over.

We also looked at ways to put systems back to sleep that weren't supposed to wake up yet. Unintended wake-ups can happen e.g. when the laptop in your backpack catches a key press from the screen when it's squeezed against the keyboard. Or when one of those (conceptually neat) "Modern Standby" implementations on recent laptops are buggy. This will need a little more investigation, but we've got some ideas.

I talked to Bhushan Shah about power saving optimizations in Plasma Mobile. He is investigating a Linux kernel feature designed for mobile devices that saves power more aggressively, but needs support from KDE's power management infrastructure to make sure the phone will indeed wake up when it's meant to. If this can be integrated with KDE's power management service, we could improve battery runtimes for mobile devices and perhaps even for some laptops.

The friendly people from Slimbook dropped by to show off their range of Linux laptops, and unveiled their new Slimbook VI with KDE neon right there at the conference. Compared to some of their older laptops, build quality is improved leaps and bounds. Natalie and I grilled their BIOS engineer on topics such as power profiles, power consumption, and how to get each of their function keys show the corresponding OSD popup.

"I'm excited that your input goal was chosen"

Every two years, the KDE community picks three "Goals" to rally around until the next vote happens. This time, contributors were asked to form teams of "goal champions" so that the work of educating and rallying people does not fall on the shoulders of a single poor soul per goal.

So now we have eight poor souls who pledge to advance a total of three focus areas over the next two years. Supported by KDE e.V.'s new Goals Coordinator, Farid. There's a common thread around attracting developers, with Nicolas Fella and Nate Graham pushing for a "Streamlined Application Development Experience" and the KDE Promo team with a systematic recruitment initiative titled "KDE Needs You". And then there's this other thing, with a strict end user focus, briefly introduced on stage by guess who?

Turns out a lot of people in KDE are passionate about support for input devices, virtual keyboards and input methods. Gernot Schiller (a.k.a. duha) realized this and assembled a team consisting of himself, Joshua Goins (a.k.a. redstrate) as well as Yours Truly to apply as champions. The goal proposed that "We care about your Input" and the community's response is Yes, Yes We Do.

As soon as the new goals were announced, Akademy 2024 turned into an Input Goal Akademy for me. In addition to presenting the new goal on stage briefly, we also gathered in a BoF session to discuss the current state, future plans and enthusiastic volunteering assignments related to all things input. I also sat down with a number of input experts to learn more about everything. There is still much more I need to learn.

It's a sprawling topic with numerous tasks that we want to get done, ranging from multi-month projects to fixing lots of low-hanging fruit. This calls for a series of dedicated blog posts, so I'll go into more detail later.

Join us at #kde-input:kde.org on Matrix or watch this space (and Planet KDE in general) for further posts on what's going on with input handling in KDE.

Look at the brightness side

KWin hacker extraordinaire Xaver Hugl (a.k.a. zamundaaa) demoed some of his color magic on a standard SDR laptop display. Future KWin can play bright HDR videos in front of regular SDR desktop content. Accurate color transformations for both parts without special HDR hardware, that's pretty impressive. I thought that HDR needs dedicated hardware support, turns out I'm wrong, although better contrast and more brightness can still improve the experience.

I also got to talk to Xaver about touchpad gestures, learned about stalled attempts to support DDC/CI in the Linux kernel directly, and pestered him for a review to improve Plasma's D-Bus API for the new per-monitor brightness features. Also the XDC conference in Montreal, is happening in less than a month, featuring more of Xaver as well as loads of low-level graphics topics. Perhaps even input-related stuff. It's only a train ride from Toronto, maybe I'll drop by. Maybe not. Here's a medieval German town selfie.

Thanks to the entire KWin gang for letting me crash their late-night hacking session and only throwing the last of us out at 2 AM after my D-Bus change got merged. Just in time for the Plasma 6.2 beta. I was dead tired on Thursday, totally worth it though.

Atomic KDE for users & developers

Plasma undoubtedly has some challenges ahead in order to bring all of its power and flexibility to an image-based, atomic OS with sandboxed apps (i.e. Flatpak/Snap). David Edmundson's talk emphasized that traditional plugins are not compatible with this new reality. We'll need to look into other ways of extending apps.

The good news is that lots of work is indeed happening to prepare KDE for this future. Baloo making use of thumbnailer binaries in addition to thumbnailer plugins. KRunner allowing D-Bus plugins in addition to shared libraries. Arjen Hiemstra's work-in-progress Union style being customizable through configuration rather than code. Heck, we even learned about a project called KDE Neon Core trying to make a Snap out of each and every piece of KDE software.

Going forward, it seems that there will be a more distinct line between Plasma as a desktop platform and KDE apps, communicating with each other through standardized extension points.

All of this infrastructure will come in handy if Harald Sitter's experimental atomic OS, KDE Linux (working title), is to become a success. Personally, I've long been hoping for a KDE-based system that I can recommend to my less technical family members. KDE Linux could eventually be that. Yes, Fedora Kinoite is also great.

What took me by surprise about Harald's presentation was that it could be great even as a development platform for contributing to the Plasma desktop itself.

As a desktop developer, I simply can't run my Plasma development build in a container. Many functions interact with actual hardware so it needs to run right on the metal. On my current Arch system, I use a secondary user account with Plasma installed into that user's home directory. That way the system packages aren't getting modified - one does not want to mess with system packages.

But KDE Linux images contain the same system-wide build that I would make for myself. I can build an exact replacement with standard KDE tooling, perhaps a slight bit newer, and temporarily use it as system-wide replacement using systemd-sysext. I can revert whenever. KDE Linux includes all the development header files too, making it possible to build and replace just a single system component without building all the rest of KDE.

Different editions make it suitable for users anywhere between tested/stable (for family members) and bleeding edge (for myself as Plasma developer). Heck, perhaps we'll even be able to switch back and forth between different editions with little effort.

Needless to say, I'm really excited about the potential of KDE Linux. Even without considering how much work it can save for distro maintainers that won't have to combine outdated Ubuntu LTS packages with the latest KDE desktop.

Conclusion

There's so much else I've barely even touched on, like NLnet funding opportunities, quizzing Neal Gompa about KDE for Enterprise, Rust and Python binding efforts, Nicolas Fella being literally everywhere, Qt Contributor Summit, finding myself in a hostel room together with fellow KDE devs Carl & Kåre. But this blog post is already long enough. Read some of the other KDE blogs for more Akademy reports.

Getting home took all day and jet lag isn't fun, but I've reasonably recovered to give another shot at bringing KDE software to the masses. You can too! Get involved, donate to KDE, or simply enjoy the ride and discuss this post on KDE Discuss.

Or don't. It's all good :)

Brightness controls for all your displays

Jakob Petsovits — Wed, 04 Sep 2024 00:00:00 +0000

Whoops, it's already been months since I last blogged. I've been actively involved with Plasma and especially its power management service PowerDevil for over a year now. I'm still learning about how everything fits together.

Turns out though that a little bit of involvement imbues you with just enough knowledge and confidence to review other people's changes as well, so that they can get merged into the next release without sitting in limbo forever. Your favorite weekly blogger for example, Nate Graham, is a force of nature when it comes to responding to proposed changes and finding a way to get them accepted in one form or another. But it doesn't have to take many years of KDE development experience to provide helpful feedback.

Otfen we simply need another pair of eyes trying to understand the inner workings of a proposed feature or fix. If two people think hard about an issue and agree on a solution, chances are good that things are indeed changing for the better. Three or more, even better. I do take pride in my own code, but just as much in pushing excellent improvements like these past the finish line:

Fabian Arndt's support for Lenovo laptops' battery conservation mode (Plasma 6.1)
Natalie Clarius's feature to block apps from inhibiting sleep and screen locking (6.2)
Christoph Wolk's improvements to usability for the Power Management settings page (6.2, one among many of the sort)
Nate's changes to show the current power profile in addition to the battery charge (6.2)
Xaver Hugl's push to allow software brightness adjustments not just for HDR displays (6.1), but indeed for any display without hardware brightness controls (6.2)

In turn, responsible developers will review your own changes so we can merge them with confidence. Xaver, Natalie and Nate invested time into getting my big feature merged for Plasma 6.2, which you've already read about:

Per-display Brightness Controls

This was really just a follow-up project to the display support developments mentioned in the last blog post. I felt it had to be done, and it lined up nicely with what KWin's been up to recently.

So how hard could it be to add another slider to your applet? Turns out there are indeed a few challenges.

In KDE, we like to include new features early on and tweak them over time. As opposed to, say, the GNOME community, which tends to discuss them for a loooong time in an attempt to merge the perfect solution on the first try. Both approaches have advantages and drawbacks. Our main drawback is harder to change imperfect code, because it's easy to break functionality for users that already rely on them.

Every piece of code has a set of assumptions embedded into it. When those assumptions don't make sense for the next, improved, hopefully perfect solution (definitely perfect this time around!) then we have to find ways to change our thinking. The code is updated to reflect a more useful set of assumptions, ideally without breaking anyone's apps and desktop. This process is called "refactoring" in software development.

But let's be specific: What assumptions am I actually talking about?

There is one brightness slider for your only display

This one's obvious. You can use more than just one display at a time. However, our previous code only used to let you read one brightness value, and set one brightness value. For which screen? Well... how about the code just picks something arbitrarily. If you have a laptop with an internal screen, we use that one. If you have no internal screen, but your external monitor supports DDC/CI for brightness controls, we use that one instead.

What's that, you have multiple external monitors that all support DDC/CI? We'll set the same value for all of them! Even if the first one counts from 0 to 100 and the second one from 0 to 10.000! Surely that will work.

No it won't. We only got lucky that most monitors count from 0 to 100.

The solution here is to require all software to treat each display differently. We'll start watching for monitors being connected and disconnected. We tell all the related software about it. Instead of a single set-brightness and a single get-brightness operation, we have one of these per display. When the lower layers require this extra information, software higher up in the stack (for example, a brightness applet) is forced to make better choices about the user experience in each particular case. For example, presenting multiple brightness sliders in the UI.

So this raises new questions. With only one display, we can indicate any brightness change by showing you the new brightness on a percentage bar:

Now you press the "Increase Brightness" key on your keyboard, and multiple monitors are connected. This OSD popup shows up on... your active screen? But did the brightness only change for your active screen, or for all of them? Which monitor is this one popup representing?

Ideally, we'd show a different popup on each screen, with the name of the respective monitor:

That's a good idea! But Plasma's OSD component doesn't have a notion of different popups being shown at the same time on different monitors. It may even take further changes to ask KWin, Plasma's compositor component, about that. What we did for Plasma 6.2 was to provide Plasma's OSD component with all the information it needs to do this eventually. But we haven't implemented our favorite UI yet, instead we hit the 6.2 deadline and pack multiple percentages into a single popup:

That's good enough for now, not the prettiest but always clear. If you only use or adjust one screen, you'll get the original fancy percentage bar you know and love.

The applet can do its own brightness adjustment calculations

You can increase or decrease brightness by scrolling on the icon of the "Brightness and Color" applet with your mouse wheel or touchpad. Sounds easy to implement: read the brightness for each display, add or subtract a certain percentage, set the brightness again for the same display.

Nope, not that easy.

For starters, we handle brightness key presses in the background service. You'd expect the "Increase Brightness" key to behave the same as scrolling up with your mouse wheel, right? So let's not implement the same thing in two different places. The applet has to say goodbye to its own calculations, and instead we add an interface to background service that the applet can use.

Then again, the background service never had to deal with high-resolution touchpad scrolling. It's so high-resolution that each individual scroll event might be smaller than the number of brightness steps on your screen. The applet contained code to add up all of these tiny changes so that many scroll events taken together will at least make your screen change by one step.

Now the service provides this functionality instead, but it adds up the tiny changes for each screen separately. Not only that, it allows you to keep scrolling even if one of your displays has already hit maximum brightness. When you scroll back afterwards, both displays don't just count down from 100% equally, but the original brightness difference between both screens is preserved. Scroll up and down to your heart's content without messing up your preferred setup.

Dimming will turn down the brightness, then restore the original value later

Simple! Yes? No. As you may guess, we now need to store the original brightness for each display separately so we can restore it later.

But that's not enough: What if you unplug your external screen while it's dimmed? And then you move your mouse pointer again, so the dimming goes away. Your monitor, however, was not there for getting its brightness restored to the original value. Next time you plug it in, it starts out with the dimmed lower brightness as a new baseline, Plasma will gladly dim even further next time.

Full disclosure, this was already an issue in past releases of Plasma and is still an issue. Supporting multiple monitors just makes it more visible. More work is needed to make this scenario bullet-proof as well. We'll have to see if a small and safe enough fix can still be made for Plasma 6.2, or if we'll have to wait until later to address this more comprehensively.

Anyway, these kind of assumptions are what eat up a good amount of development time, as opposed to just adding new functionality. Hopefully users will find the new brightness controls worthwhile.

So let's get to the good news

Your donations allowed KDE e.V. to approve a travel cost subsidy in order to meet other KDE contributors in person and scheme the next steps toward world domination. You know what's coming, I'm going to:

Akademy is starting in just about two days from now! Thank you all for allowing events like this to happen, I'll try to make it count. And while not everyone can get to Germany in person, keep in mind that it's a hybrid conference and especially the weekend talks are always worth watching online. You can still sign up and join the live chat, or take a last-minute weekend trip to Würzburg if you're in the area, or just watch the videos shortly afterwards (I assume they'll go up on the PeerTube Akademy channel).

I'm particularly curious about the outcome of the KDE Goals vote for the upcoming two years, given that I co-drafted a goal proposal this time around. Whether or not it got elected, I haven't forgotten about my promise of working on mouse gesture support on Plasma/Wayland. Somewhat late due to the aforementioned display work taking longer. Other interesting things are starting to happen as well on my end. I'll have to be mindful not to stretch myself too thinly.

Thanks everyone for being kind. I'll be keeping an eye out for your bug reports when the Plasma 6.2 Beta gets released to adventurous testers in just over a week from today.

Discuss this post on KDE Discuss.

PowerDevil in Plasma 6.0 and beyond

Jakob Petsovits — Tue, 23 Apr 2024 00:00:00 +0000

Hi, I'm Jakob and this is my new KDE blog. Let's see how this goes as I haven't blogged for literally decades.

I started working on Plasma code sometime last year and hope to play a tiny part in ~~setting the stage for world domination~~ improving user experiences like so many other awesome and dedicated contributors do every week. My Plasma contributions started out with a few rounds of build improvements and bug fixes initially. Before long though, I decided to realize my lifelong dream of a friendly and usable Energy Saving settings page. Thus started a journey into the code of Plasma's power management service, internally known as PowerDevil.

Quick recap: As a service, PowerDevil is mainly responsible for two rough areas.

It will suspend Plasma sessions when the time is right, and also,
It adjusts backlight brightness levels of your display and monitors, including the ability to turn them off altogether.

In terms of user interfaces, the Energy Saving module in System Settings allows you to set different suspend/shutdown behaviors and brightness adjustments for different power states: on AC power, on battery, and on low battery. Ad-hoc adjustments to the same settings can also be made with two applets in your system tray: Power and Battery, as well as Brightness and Color.

Let's have a look at some of the work that went into Plasma 6.0 in this area. I'm about two months late for a 6.0 news blog, but Fedora 40 KDE Spin is just out as the first major Linux distro on a semi-annual release cycle to feature Plasma 6. So maybe not terrible timing. We'll also have a look at some of what's been brewing for 6.1 so far. You may have seen some of this across a number of different "This Week in KDE" blog posts, but then again maybe you haven't!

System Settings & Config Data

I'm quite happy with the way the new settings worked out. It also took a while to get there.

A year earlier, I posted an outlandish proposal to radically change the Energy Saving page. It's too long and boring and unworkable to cover here. However, it made me think long and hard about all the different ways that the settings page could look like, what its controls must be able to represent. It also made me aware that another UI rework had already been in the works previously, which didn't get merged.

Nothing is ever as easy as one hopes it to be. A substantial redesign of the settings page would require rewriting the UI with modern Qt Quick / QML code, as opposed to the rather unwieldy Qt Widgets that the old UI was using at the time. As I learned, a settings module based on Qt Quick also wants more knowledge about its underlying configuration data. Things such as: "what's the default value for this setting", or "if you click this checkbox a second time can we disable the Reset button again".

PowerDevil had lots of config data and was using old infrastructure in non-standard ways to access it. The service would generate a new config file on first run, with all of its default values written to ~/.config/powermanagementprofilesrc. After creating this config file, it had no clue which of the values were defaults and which were your own customized settings. In Plasma 5.x, pressing the "Defaults" button would open a dialog to warn you that all of your changes will be thrown away immediately and can't be recovered if you proceed. Compare that to other modules, which let you press "Defaults" and "Reset" as much as you want until you decide finally "Apply".

Before even attempting to improve the UI itself, a series of changes was necessary in the code that reads and interprets config files. I got there by extracting and improving one small bite after another from the extensive but ultimately unmerged earlier attempt. A steady stream of small, easy-to-review patches will win the race eventually.

The result is this. Power management settings are now only written if you change away from the default values. If you checked the "Highlight Changed Settings" option, System Settings will be able to show which of your Energy Saving settings have been modified compared to the defaults. You can transfer your SSD from a laptop to a PC and the suspend/shutdown defaults will now reflect the new system's capabilities. Extra config files for the various power states and activities have been migrated to ~/.config/powerdevilrc.

Building on these changes, the UI rework got merged just in time for Plasma 6.0. I think it's significantly cleaner than it used to be, while at the same time there are still things I'd like to change about it. Eventually I'd like to configure my "laptop lid closed" action only once, instead of applying the same change across all three power states. The "custom script" controls make more sense for laptops with different power states than for desktop PCs, where the current design can be a little confusing. Screen and keyboard brightness should ideally move to the Display Configuration and Keyboard settings modules. We'll get there eventually.

Special thanks to Nicolas Fella and Nate Graham for their repeated, kind & thoughtful code reviews. Throughout this project and really everywhere else in KDE. Getting (or giving!) that kind of feedback makes a huge difference.

Moved & Removed Functionality

The UI rework would have been harder if Nicolas hadn't also simplified PowerDevil in other areas. One is that WiFi, WWAN and Bluetooth are gone from Energy Saving, they were more confusing there than they were helpful. Switching wireless devices on or off can still be done through the system tray applets, or the WiFi/Bluetooth modules in System Settings.

Plasma 5.27 and earlier allowed you to set a full power management settings profile if a given Activity is currently active. It's still possible in Plasma 6.0 to block automatic sleep or screen turn-off. Those settings have moved to the Activities settings module, where they can be configured as part of each individual Activity. Entire pages of power management settings cannot be controlled through Activities anymore in 6.0 though. If these capabilities ever end up returning, it will be with a different code architecture and a different UI.

Natalie Clarius has invested lots of time into system tray applets. Instead of a single "Battery and Brightness" applet and a separate "Night Light" applet, the brightness settings in Plasma 6.0 are now colocated with Night Light as "Brightness and Color" applet. This leaves the "Power and Battery" applet by itself, which displays battery status (including peripheral battery, if your mouse or keyboard supports this) and can configure power profiles on the fly (if power-profile-daemon is installed).

New & Improved Functionality

In Plasma 5.x, you were able to configure how long the system should be idle before the display gets turned off. For Plasma 6.0, Jonathan Haney added a setting to configure a shorter turn-off duration on the lock screen. You won't be reading long web pages and PDFs on the lock screen so you might as well avoid distractions and save some power. This setting can be reduced all the way to zero seconds so that the screen turns off immediately when locking the session. I spent some time to make this work reliably on both Wayland and X11.

We still need to streamline the settings UI a bit, in line with the "simple by default, powerful when needed" mantra.

Brightness can be increased or decreased in 5% steps by pressing brightness up/down keys, which are usually found on laptop keyboards. In Plasma 6.0, brightness steps can also be controlled in 1% steps by pressing Shift in addition to the brightness key.

We merged a number of bug fixes to improve reliability of automatic brightness adjustments. Restoring keyboard backlights works better now after waking up from system sleep, dimming after a period of inactivity is less fragile, fading to black before the screen is turned off won't flicker when a mouse move interrupts the fade at the wrong time. If (lib)ddcutil or PowerDevil's use of it makes trouble with controlling external monitor brightness via DDC/CI, it can be disabled by setting a POWERDEVIL_NO_DDCUTIL=1 environment variable for the PowerDevil service on startup.

There is now an OSD switcher for power profiles (i.e. Power Save, Balanced, Performance) that will pop up when the battery function key on some laptop keyboards is pressed, or Meta+B.

In Plasma 5.27, you could configure a custom script to run when entering or exiting a power state (AC, battery, low battery) or after a period of inactivity in this current power state. In Plasma 6.0, you can configure a custom script for each of these "run conditions" in each power state. So you can run a script to activate something when you plug in the laptop, and disable it again when removing the power plug.

Auto-suspend after inactivity, laptop lid closure and power button presses now each allow you to select "Sleep" vs. "Hibernate" as their respective suspend actions. The "Hybrid sleep" option and the confusingly placed "Sleep, then hibernate after a period of inactivity" checkbox are now part of a separate drop-down that lets you choose alternative sleep modes. Less confusing than before, although there's more work needed now to make this updated categorization consistent across the entire desktop, like on the logout screen.

Functionality that just keeps working!

For years, the UPower daemon had marked its laptop lid detection functionality as deprecated, to be removed in a future release. Plasma's power management service relies on UPower, and Plasma would have soon lost the ability to react to lid closure events. UPower had already removed this code from their unreleased development codebase, it was only a matter of time until the next official version would be released to break lid handling everywhere. So I started working on a replacement, but getting full coverage across different platforms (X11 vs. Wayland, systemd vs. not-systemd) is quite a bit of effort and there were lots more kinks to figure out.

So I am very happy that UPower has indeed released a new version, one that puts the lid detection code back in for the benefit of upstream users such as Plasma, GNOME and various window managers that have also relied on their lid detection functionality. Better yet, it's meant to stay this time around. Things will just keep working as they do now! It's great to have this kind of system-level functionality available in common infrastructure such as UPower so we don't each have to implement substandard knock-offs individually.

On the monitor brightness front, recent versions of libddcutil have introduced a feature that prevents two independent programs from talking to the same monitor simultaneously. Due to the way that our background service has traditionally been using libddcutil, Plasma 6.0 sessions have been hogging libddcutil's monitor handles. Users who like to perform other operations with DDC/CI, for example through the ddcutil command-line program, would find it non-functional. Starting with Plasma 6.0.4, our DDC/CI code was restructured so that a monitor is only hogged for the short time it takes to change the brightness. ddcutil works again as intended in a Plasma session.

Beyond 6.0

The System Settings module will be renamed from "Energy Saving" to "Power Management". This used to be the name of the entire category containing the "Energy Saving", "Advanced Power Settings" and "Activity Power Settings" modules. After the redesign, there is only one module left and it can be called by the arguably more appropriate name.

After the Plasma 6.0 feature freeze went into effect, Bogdan Onofriichuk significantly improved the code for external monitor brightness handling via DDC/CI (using libddcutil).

Starting with 6.1, the power management service will recognize at runtime when monitors are connected or disconnected. Previously, only a single monitor detection was done on startup and if you changed your monitor configuration afterwards, brightness controls in Plasma would have no effect on newly plugged-in monitors.

Brightness via DDC/CI will not be animated anymore in order to minimize the risk of shortened monitor lifespans. The chance of this happening is hard to verify for someone not in the monitor industry, but we'll follow the example of monitor manufacturers' own helper applets and apply newly adjusted monitor brightness values only after a half-second delay.

Brightness animations of internal laptop backlights, on the other hand, are going to get more responsive when dragging the brightness slider in the applet or holding down the brightness key.

We've done more work on cleaning up the display code, with the goal of allowing per-monitor brightness controls as opposed to the single brightness slider of current Plasma releases. After raising the minimum brightness value to "the lowest value that's higher than 0%" to stop screens from inadvertently turning off, we'll lower it back down to an exact 0 where it's safe to do so. We also want to move the core of screen brightness control into KWin, which will be able to do more awesome things such as adjust brightness on OLED screens that don't even have a backlight to control. No guarantees when any of this will be ready to ship, but it's a lot closer now than just a few months ago.

How You Can Help

There are a lot of edge cases and system configurations that could still be handled in a better way.

Device interactions can be hairy, they will often differ from one system to another. What might work well on my system can break on someone else's. You can use the power of having a different setup to do things that a number of KDE developers cannot. If you're running into issues with suspend, brightness and other things that PowerDevil may have a hand in, check out the new README file.

Consider helping with bug triage! PowerDevil on KDE's bug tracker has a service component with lots of reported bugs, as well as a component for the System Settings module with fewer bugs and quite a few wishlist items. The service component includes some very old bug reports which may or may not fully apply to Plasma 6.0 anymore. Read this if you're interested in helping us determine the amount of developer love still required for different bug reports. Also if you rock at figuring out how to reproduce issues reliably, when the original reporter wasn't able to find a conclusive pattern by themselves.

And of course, if you're a developer, feel free to fix a problem and submit a merge request. Some issues aren't straightforward to resolve. We'll work through them eventually. Probably. I'm a volunteer just like most of you, so no promises whatsoever.

You can also donate to KDE so they can continue to do helpful things like paying Natalie to work on hardware integration, or (if the approval gods are kind) hopefully subsizing my travel costs to Akademy 2024.