KWin GameController Plugin: Weeks 5-6

It's been another few weeks of progress on the KWin GameController Plugin and I've got a lot to share! After spending the previous weeks setting up the foundation, I've progressed things forward by improving the logic a bit more, creating a few integration tests, integrating it into System Settings, and making sure it runs well on real hardware like the steamdeck.

The primary change was splitting up GameController into two classes. The new one being GenericInputDevice which lives in emulatedInputDevice.{cpp/h}. This allowed me to separate the GameController logic responsible for emulating keyboard and mouse into it's own separate class. Now GameController wrapper class is just responsible for monitoring controller input, resetting idle timer on user activity, and logging.

GenericInputDevice

GenericInputDevice is a class that inherits from InputDevice and is used to emulated Keyboard/Mouse in order to send those inputs through KWins input pipeline. The input_events come from GameController and get processed exactly like they were previously. Each GameController has access to an instance of GenericInputDevice to make its own calls. In the near future I plan on creating a static instance of this class for all GameController to access.

// Inside Gamecontroller construct
 m_inputdevice = std::make_unique<EmulatedInputDevice>();
 KWin::input()->addInputDevice(m_inputdevice.get());

..

// GameController Event Handling Function
void GameController::handleEvdevEvent()
{
 input_event ev;
 for (;;) {
 const int rc = libevdev_next_event(m_evdev.get(), LIBEVDEV_READ_FLAG_NORMAL, &ev);
 if (rc == 0) {
 logEvent(&ev);

 input()->simulateUserActivity();

 if (m_usageCount == 0 || isTestEnvironment)
 m_inputdevice->emulateInputDevice(ev);

.. 

// EmulatedInputDevice
void EmulatedInputDevice::emulateInputDevice(const input_event &ev)
{
 m_ev = ev;
 if (ev.type == EV_KEY) {
 qCDebug(KWIN_GAMECONTROLLER) << "Face button pressed: Simulating User Activity";
 evkeyMapping();
 } else if (m_ev.type == EV_ABS) {
 qCDebug(KWIN_GAMECONTROLLER) << "Analog buttons pressed: Simulating User Activity";
 evabsMapping();
 }
}

void EmulatedInputDevice::evkeyMapping()
{
 bool state = m_ev.value ? true : false;
 std::chrono::microseconds time = std::chrono::seconds(m_ev.time.tv_sec) + std::chrono::microseconds(m_ev.time.tv_usec);

 switch (m_ev.code) {
 case BTN_SOUTH: // A button → Enter
 sendKeySequence(QKeySequence(Qt::Key_Return), state, time);
 break;
 case BTN_EAST: // B button → Escape
 sendKeySequence(QKeySequence(Qt::Key_Escape), state, time);
 break;
 case BTN_NORTH: // X button → Virtual Keyboard
 // TO-DO toggle Virtual Keyboard not working on my distro ( Kubuntu )
 EmulatedInputDevice::toggleVirtualKeyboard(QStringLiteral("forceActivate"));
 case BTN_WEST: // Y button → Space
 sendKeySequence(QKeySequence(Qt::Key_Space), state, time);
 break;
 case BTN_TL: // L button → Ctrl
 sendKeySequence(QKeySequence(Qt::Key_Control), state, time);
 break;
 case BTN_TR: // R button → Alt
 sendKeySequence(QKeySequence(Qt::Key_Alt), state, time);
 break;
 case BTN_START: // START button → Meta
 sendKeySequence(QKeySequence(Qt::Key_Meta), state, time);
 break;
 case BTN_SELECT: // SELECT
 break;
 // Add more button mappings here as needed
 default:
 break;
 }
}

..

Integration Test: Qt Test

Part of the requirements for proposing significant contributions to KWin is creating integration test. This provides some assurance that things, like core functionality of the plugin, won't break so easily in the future as new code gets added. For testing KWin, uses the Qt Test Framework. Learning how to use the framework to create my own tests has been fairly simple and straightforward. Still, what exactly to test, and how to test it, was not so straightforward.

I learned along the way that I'd be creating integration tests, instead of unit tests. The tests don't reference the plugins directly; instead, they test the effect of the plugins on the system overall. That meant that things which required an instance of the plugin to test were not possible in this case. That included testing hotplug capability, or the number of applications that the plugin thinks have opened an input device. Thankfully there were few very important functionalities that could be tested!

Those include:

// Test system idle time reset. Prevents suspend
void testResetIdleTime();

// Test Controller To Keyboard Input Emulation
void testKeyboardMapping();

// Test Controller To Pointer/Mouse Input Emulation
void testPointerMapping();

I took a lot of inspiration from the buttonrebind_test.cpp.

System Settings KCM

It was agreed upon early on that this plugin would be opt-in, giving the user to enable and disable it when they choose. For that I created a KDE Control Module or KCM. Or better put, I built on the existing Game Controller KCM :) I added a new UI element, a toggle, for users to enable and disable the plugin. On the backend, I added a Q_PROPERTY, pluginEnabled, which is responsible for checking the kwinrc Plugin configs, and writing to them, in order to manage the state of this plugin. This is what it currently looks like (subject to change):

Handling Lizard Mode

This was probably one of the most daunting parts of the project for me when I first started. I knew that steamOS had its own way of handling input coming from the Steam Deck controller which has nothing to do with KDE or Steam app. This is what allows the controller to work for navigating the device in game and desktop mode. It's what is refered to as "Lizard Mode". The controller -> keyboard/pointer rebinds that I implemented was based off of the rebinds of this Lizard mode. Ideally using a controller to navigate desktop feels/works the same across all devices on KDE.

It's important that this new plugin not disrupt the current input system for the steamdeck. Originally I was warned that opening the fd for this device would cause Lizard mode to be disabled, which would mean I would have to either:

A: Find a way to disable Lizard mode and implement it from scratch...

B: Figure out what disabled Lizard mode on FD open and how to prevent / enable it as needed.

or C: Just change the flag for opening the controller fd and everything works just fine :)

Yup. After some testing and the smallest change I've had to make all project the Steam Deck controller was able to be detected by the plugin as well as its input detected! Even better than that, and not sure why I did not put this together before, Steam Deck already maps its input to keyboard/mouse. Duh. So this gamepad plugin doesn't need to worry about mapping and of Steam Deck input to just use it prevent system sleep when activity from that controller is detected.

During my testing, I discovered that Steam Deck shows up on the system as 5 different controllers. Each having their own purpose, one to handle analog input (triggers, trackpads, sticks) another to handle face buttons & D-pad, another for keyboard, etc.. These are used by the system depending on the users needs. Again, this made life a lot easier. This are logs from evtest and gamecontroller plugin:

At the start of this project I had adopted a child. Some of you reading this post might have met my child. It's named

As some put it:

Wow this is an ELEVEN (!) year old bug.

This issue is so old it can go to middle school.

and my favorite

Is there any hope that this bug will be fixed before the heat death of the universe?

By the time I met Bug328987, it had been around for ≈12 years. But still! In the eyes of KDE, it was a young, bright eyed, workflow-breaking bug, like all the bugs out there, and it had potential to be fixed! After months of back and forth with mentors, living in KDE matrix server like it were my personal Discord server, and learning how to not do things in the code base - I'm proud to say gamecontroller plugin properly addresses Bug328987. Bringing to an end its more than a decade long journey. They grow up so fast.

What’s next from here

• Integration into Kwin Proper: "Draft" label has been removed from MR and is ready for review.
• Final Fixes and Touch-up: Get Virtual Keyboard working, KCM toggle hot-plug, improve analog -> pointer emulation.

Reference documentation

• buttonrebind_test: https://invent.kde.org/plasma/kwin/-/blob/master/autotests/integration/buttonrebind_test.cpp
• GameController KCM: https://invent.kde.org/plasma/plasma-desktop/-/tree/master/kcms/gamecontroller
• Qt Test: https://doc.qt.io/qt-6/qtest-overview.html
• Steam Controller Input: https://www.reddit.com/r/SteamController/wiki/index/

Other useful links

KWin Gamepad Plugin: https://invent.kde.org/yorisoft/kwin/-/tree/work/yorisoft/gamepad-plugin/src/plugins/gamepad

Design Systems is a relatively new concept that aims to organize the way design happens in structured systems such as applications, websites, organizations, etc.

Historically, working with graphics for the digital age has been unorganized, lives in personal computers, is not collaborative and leads to uncoordinated design.

When the world of graphic design meets development, designers were often confused about why mockups are not followed, why colors are not the same, not the same shapes, etc. All the while, developers ask designers why they can’t provide something that more closely resembles the system they aim to change. It’s uncoordinated work entering a highly-systemized world.

Often, both sides are confused and system changes become much more difficult to achieve.

Meet UI-design applications. The first wave of these started with Sketch (for Mac). Sketch is a fast and powerful vector graphics application that introduced a number of advantages over traditional SVG editors meant for artistic work. For example:

• Infinite canvas
• Area bounding
• CSS-based design
• CSS-based organization
• Easy exports into various sizes
• Asset library management
• Collaborative design

Through their efforts, a sleuth of similar applications appeared in the scene, one building upon what the previous one lacked. Until we arrived at Figma, yes, Figma.

Figma did a few things right at the start of their development. They provided stronger asset library management, easier online collaboration, web-based editor with near-native speeds (If not faster now with the use of Web Assembly and other technologies), and variable and token management.

Through these enhancements Figma became the de-facto application to use for UI-oriented graphic development.

But what do they all do?

Put simply, these applications develop color, typography, spacings, shadows, icons, etc sets of organized assets. The assets have properties borrowed from development, such as, components, variables and tokens.

Designers can set up entire color libraries in a graphical way and then apply those colors to SVG graphics. Upon export, these graphics contain enough information for developers to more easily implement the design.

All the while, designers only have to spend time at the beginning of a project to set up all the assets required for designing. Additionally, Figma and other applications have been keenly focused on building graphical ways to deal with code-oriented complexities.

For example, Figma and PenPot detect variants creation and can express their values in dropdown menus that get created on the fly by the designers. If you create a button and your variants are size oriented, you can have a dropdown in the application’s UI that shows SM, MD, LG, XL, etc. These are huge time savers. Traditionally, designers would have to do a lot of copy/paste in their designs. With integrations like these, designers simply switch the variant for another and the design updates itself.

A similar idea happens with graphical components in these applications. Users are able to create a master version of an asset, let’s say a button, set up all of their locked and open parameters, colors, typography, margins, gutters, etc. When you make copies of this component, any changes made at the component level will be updated anywhere copies were placed. For very large design documents containing a company’s brand strategy, for example, these types of changes save countless hours of tedious copy/paste work.

Tokens

In recent times, and through various changes in the app-making industry, UI design applications have created the concept of tokens. Tokens are essentially named attributes for graphical components. They are often used as correlated language between design applications and systems.

For example, for Ocean Design, the team created tokens named thus:

pd.ref.color.primary50

• PD: Plasma Design
• REF: Reference color (Raw color value as opposed to applied color, which is called “sys”)
• PRIMARY50: Color role and its named color value in a line from light to dark values of the same color family.

This value can be replicated in Plasma. Through the storing of a master list of token values, Plasma can stay coordinated with graphic primary50, the system would have to do the same and just change the raw color value of that token without having to create new tokens, break coordination with the design system, or have to interpret information coming from designers.

Tokens are becoming more common use and reflect the desire of developers and designers to have even tighter integration between design and development.

Independence

Design Systems also allow for great independence between design and development. Having laid the groundwork to create coordinated design, applications like Figma and PenPot allow users to download asset libraries, reuse, and create UI. All without redefining the source library. It democratizes graphic design while keeping designers coordinated in their designs.

Developers looking to execute an application idea can much more easily create coordinate UI that supports their efforts. Developers would have much less design-oriented work to do and dedicate more into the features they want to deliver.

Ocean Design

Ocean Design aims not only to become a new UI design for Plasma but also plug in these powerful design applications into our development ecosystem and deliver UI to users faster, more coordinated, and more often.

If you’re interested in learning more about this effort, connect with our teams here:

• Plasma Visual Design Team (General chat about all things designs for the Plasma Desktop)
• Ocean Design Team (Focused discussion on Ocean Design)

Haruna version 1.5.0 is released.

The highlight of this release is the playlist, which got a lot of features:

• multiple playlists through tabs (Muhammet Sadık Uğursoy)
• drag and drop reordering (Muhammet Sadık Uğursoy)
• add files and folders through drag and drop (Muhammet Sadık Uğursoy)
• filtering (Muhammet Sadık Uğursoy)
• option to control playback behavior when a file ends: repeat playlist, repeat file, stop after last file in playlist, stop after current fille and play a random item

Another big change is to the Mouse settings, now you can use a mouse button + modifier key combo (ctrl + left click, shift + scroll up/down etc.).

Windows version:

• haruna-1.5.0-windows-gcc-x86_64.exe
• haruna-1.5.0-windows-gcc-x86_64.7z

Availability of other package formats depends on your distro and the people who package Haruna.

If you like Haruna then support its development: GitHub Sponsors | Liberapay | PayPal

Feature requests and bugs should be posted on bugs.kde.org, ignoring the bug report template can result in your report being ignored.

Changelog

1.5.0

Known issues

On Windows the Shortcuts and Custom Commands settings pages don't work.

Features

Settings

• General
  • added single instance setting to play new file when appending to the playlist
  • removed the "File dialog location setting"
• Playlist: added settings to control playback behavior
• Mouse
  • changed to allow modifier keys
  • added support for Mouse Forward and Back buttons
• Subtitles: if a relative folder name in the Load subtitle from list starts with an * (asterisk) then subtitles will be searched in all folders contaning the folder name. Example: If the Load subtitle from list contains an entry *sub and you have the following folders next to the video file subs, more subs and subtitles all of these folders will be searched.
• the settings window now has a minimum width and height

PlayList

• added support for multiple playlists
• items can be reordered manually through drag and dropdown
• items can be selected, ctrl+click to select multiple items, shift+click to select a range
• items can be filtered
• added setings to control playback behavior when a file ends
• when saving the playlist the file extension is set to m3u
• can add files and folders through drag and drop
• multiple files can be added through the option in the header
• hide playlist when mouse leaves window while maximized, prevents opening the playlist when moving mouse to another monitor

Playback

• if a file can't be played now an error is shown and playback stops instead of trying to play the next file (prevents a potential infinite loop when no file in the playlist can be played)
• can play files starting with a dot (hidden files)
• an error is shown when failing to get youtube playlist

Other

• mpris: add support for Shuffle and LoopStatus
• changed the action selection popup to use Kirigami.SearchDialog
• replaced the spinning icon with a progress bar and label
• the drop area of the video is split in 2 parts now
  • top part always appends to the default playlist
  • bottom part clears the default playlist and adds the dropped files and folders, when only one file is dropped it behaves as the open file action (clears the playlist and loads sibling files if enabled in settings)
• recent files are now stored in a sqlite database
• time positions used to restore videos are also stored in the database
• sleep is blocked on Windows too
• all strings should be translatable now

Bugfixes

• fixed the loop action, osd was not showing and progress bar was not highlighting the loop range
• before loading check that the file exists
• fixed loading wrong subtitles when using recursive subs
• fixed the progress bar getting taller when the chapters menu becomes visible
• fixed a bug where the video would pause after clicking the progress/seek bar

Beginning of 2025 I was searching through the version history of Qt OPC UA - trying to find out when a certain issue got introduced. At some point I was curious: How long does this thing go back?! Turns out that the first git commit is dated 25th of September 2015. Which means we have been doing this for over 10 years now!

Continue reading 10 Years of Qt OPC UA at basysKom GmbH.

Calamares is a Linux system installer used by a wide range of distro’s. It is in “community maintenance” mode, which means it depends on downstream code submissions and careful bug reports. Sometimes I have time to work on it, outside of any particular distro. It would be correct to say it is “slow going”. But that doesn’t mean there are no changes! Just this week a new language was requested, Luganda, bringing the total to 79. Not all of the languages have enough coverage to be included in the language drop-down, but all of them have translators working on bringing the installer to their locale. Welcome!

Whether you missed it the first time or simply want to relive the excitement, the entire Akademy 2025 experience is now available to rewatch online! From insightful keynotes and engaging panel discussions to technical talks, every moment of the event has been recorded and uploaded for the community to enjoy.

This year Akademy was packed with ideas, innovation, and collaboration that will shape the future of KDE and open source.

Watch now on your favorite platform:

• Watch on PeerTube
• Watch on YouTube

Enjoy!

At Akademy 2025 this year, I had the privilege of giving a talk about a big picture topic close to my heart, and you can watch it here:

For those who prefer reading over watching and listening, I’ll give a quick summary:

I believe that the challenges facing the world today present an opportunity for KDE to grow in importance and reach due to a variety of favorable trends embedded in the chaos and conflict, including:

• Increasing skepticism of traditional proprietary American big tech
• Increasing EU public funding opportunities
• Windows 11 sucking and losing its edge for gaming
• *Postscript: MacOS Tahoe stumbling and being publicly mocked as well

But this is a window of opportunity that I think will close. So I encouraged everyone to think about how we can make KDE software ready for adoption from the following perspectives:

• Being known about in the first place
• Looking good enough to be taken seriously
• Being easy to download or otherwise acquire
• Working properly and having enough features
• Having enough support resources and an articulable “lower total cost of ownership” story

Because if we’ve got all five, our offerings will start to look irresistible, and I think we’ll gain market share very quickly!

Kirigami Addons is a collection of supplementary components for Kirigami applications. Version 1.10.0 is a relatively minor release, introducing KirigamiApp and some improvements on Android regarding the new edge-to-edge support introduced in Android 15.

New Features

Aleix Pol Gonzalez added a KirigamiApp component which removes quite a bit of boilerplate to setup a Kirigami applications.

It now looks like this and will setup theming, crash reporting and more automatically in one place:

int main(int argc, char *argv[])
{
 KirigamiApp::App app(argc, argv);
 KirigamiApp kapp;

 // Set up KAboutData

 // QCommandLineParser creation and processing

 if (!kapp.start("org.kde.myapp", u"Main", new QQmlApplicationEngine)) {
 return -1;
 }
 return app.exec();
}

Bug fixes

Volker Krause added edge-to-edge support to the BottomDrawer and the MaximizedComponents.

Packager Section

You can find the package on download.kde.org and it has been signed with my GPG key.

KDE’s Android builds as well as CI/CD and development containers and VM images have finally been switched to Android SDK 35 a few weeks ago. That was about time, with Google requiring this at least for Play Store updates starting from September 1st. Here’s why this took so long.

SDK 35 and Qt 6.9

Starting with SDK 35 applications are drawing the entire screen, with the system status and navigation bars transparently overlaying the app content. This was possible in older SDKs already but generally wasn’t used by us. Now it’s the default and cannot be disabled anymore.

Not taking that into account would lead to parts of the application toolbar being inaccessible as the Android status bar handles input events there, as well as parts of the app UI being overdrawn by system controls, or ending up behind round screen corners, rounded screen edges or cameras placed in holes in the display.

To address that, Qt 6.9 introduced a new SafeArea API to tell the application which parts of the screen are safe to use for its content (see Qt’s blog post).

So as a first step just adding appropriate margins to an application window solves the worst problems, even if it might not look pretty. There were a few challenges with just that already though:

• While the SafeArea API was added in Qt 6.9.0 it didn’t actually work there yet on Android. This was initially fixed by CR 635234 for 6.9.1 but reverted again before 6.9.1 was even released, CR 655735 reapplied the fix 6.9.2, which then was released on August 26th.
• The module needing most changes for this is Kirigami, which as part of KDE Frameworks still has to support Qt 6.7. And since this is QML, version-based compile-time conditionals are not an option. So we ended up adding a polyfill QML module that adds a SafeArea API stub for older Qt versions. That’s good enough as on all platforms where we actually need it to report correct values we fortunately also have full control over the Qt version.
• While that works and allows us to gradually implement support for safe areas across libraries, the Breeze style and in applications as needed, it requires at least Kirigami 6.15. That’s generally not a problem, however due to unrelated events partly outside of our control the KDE Flatpak SDK was stuck at KF 6.13, and thus any use of the SafeArea polyfill API would have broken Flatpak builds. This was eventually resolved on September 12th with an updated Flatpak runtime being published.

Qt 6.9.2

Besides a working SafeArea API, Qt 6.9.2 also sets sensible window margins by default on Android, so most of our apps will no longer totally break when built against SDK 35 fortunately. Nevertheless there’s a steadily growing list of changes to handle this properly. Examples:

• Kirigami navigation bar (MR 1800)
• Kirigami global and context drawers (MR 1792, MR 1801)
• Kirigami headers (MR 1794, MR 1907)
• Kirigami page paddings (MR 1909)
• Kirigami Addons bottom drawer (MR 389, MR 390)
• Breeze style comboboxes (MR 137)
• KWeather dynamic page spacing (MR 148)
• Itinerary floating buttons (commit 4fe45ec155)
• Tokodon sidebar (MR770)
• Kongress sidebar (MR 83) - review pending
• Kirigami Addons full screen image component (MR 396)

There’s a bunch more similar changes needed before we get to a point when we can remove the default safe margins on application windows. That then gives us prettier results, in particular for apps that don’t just have gray toolbar at the top and bottom, such as KWeather.

If you still spot content being drawn behind the status or navigation bars or screen cutouts somewhere, get in touch in the #kde-android Matrix channel!

Plasma Mobile

Rounded screen corners and screen cutouts aren’t just a thing on Android, we’ll need to deal with all of that on Linux as well eventually. This was a topic during the Plasma Sprint in Graz earlier this year. Most of the work is on the compositor and Wayland protocol side of this, from an application perspective this will eventually look the same as on Android, with the Qt platform integration plugin filling the the SafeArea margins accordingly. So all the work on this for Android will also benefit Plasma Mobile.

Outlook

Google gives us no time to rest unfortunately, by November 1st support for 16kB page sizes becomes mandatory. That “only” affects native code, which is just what practically all our apps and our entire dependency chain consists of…