Activities' future is a bit unclear at the moment. It overlaps with functionality provided by other services and the user story for how it fits into the desktop is unclear at best. However we also have to acknowledge that some people use activities to create a workflow that works for them. Rather than taking a sledgehammer to the concept, we're performing a more surgical approach of working out what use-cases people are trying to fix at finding the best solution to deliver that.

With that comes cleaning out some of the parts we don't like and one part decided at the Plasma sprint was dropping the activity based sub-session management.

What's changing

At the moment activities can be started and stopped at runtime.

This start/stop feature (pictured above) is being dropped.

In theory there is is XSMP code performs session management on a per-activity basis. When an activity is stopped, those applications are frozen, closed as running processes and restored when the activity next gets restarted.

It's a neat idea, but in practice this rarely happens, for a range of reasons:

• XSMP is not supported in an increasing amount of apps and toolkits. Subsessions even less so, and even more less so with Wayland.
• It is blocked in almost all Flatpak/Snap applications as there's a fundamental sandbox escape in the protocol.

The vast majority of apps just move to the neighbouring activity.

Even if it did work, there's a fundamental design flaw with the entire concept.

A window/app can be on two activities at once, if it should remain open on the other activity we can't suspend it. The concept of session restoration is at odds with the cardinality of windows to activities.

Many applications don't allow multiple instances; so if you resume an activity with the application already running, it won't do anything and that's unfixable.

The end result is one that's inconsistent and unpredictable which is a state worse than not existing so we're dropping this feature.

Will I see an impact?

Not much. If you do use activities you can still switch between them as before, just with no "stop" and "start" button.

Akademy 2025 was hosted in Berlin, and this was my first time attending Akademy in person.

I was very excited both to see Berlin (and put my very shaky German skills to practice), as well as to attend our big yearly event and meet some more cool folks in person.

The trip out was fairly uneventful, if long (~17 hours of bus, planes, and train). The biggest difference compared to travelling to the Plasma sprint is that this time I had some good noise cancelling over-ear headphones -- what a lifesaver! Especially when you end up on a flight across the ocean sandwiched between 2 screaming, jumping, grabbing toddlers. 10/10 can recommend! The headphones, not the toddlers. 😂

As expected when I arrived at my hotel I crashed and slept for 11 hours straight.

I had a good time at the welcome event. I offered to help and spent the evening handing out food and drink tickets to everyone and chatting to a few people -- including an excellent conversation about the merits of QA & testing, which still surprises me not everyone is on board with!

We had a huge amount of talks and BoFs to attend. (Sidenote: "BoF" stands for "Birds of a Feather", and is apparently a more informal/less structured time for talk/discussion/hacking/etc -- I was lost on what these letters meant for a long time before now.)

I don't think I could hope to cover even a fraction of what went on, and indeed because the schedule is structured in such a way that there are multiple things going on at any given time, I had a lot of trouble choosing what to go to -- what if I want to attend them all?! Well, that is kind of what I am doing as I am catching up on the recordings of what I missed after the fact.

I am very happy that the audio and video quality of the recordings appear to be massively improved over last year's! Paired with the auto-generated captions on YouTube it actually makes for an excellent way to consume the talks, and is valuable even for the talks I attended in person since my auditory processing disorder means that I have trouble understanding what people are saying (massively worsened with low volume/echo/noisy environment/etc). If we can figure out the infrastructure to also record the BoFs for next year that would be another great step up for accessibility and allowing a wider audience to participate & benefit. 💙

We had a BoF about the KDE Out-Of-Box-Experience (OOBE), where Neal Gompa and I went through some of the history of the project (a lot, Neal has been championing it forever!) and its current state (nearly ready for early testing and adoption). There were some good questions, and I am consistently gratified to see the interest and excitement there is for the project.

The schedule for Akademy was a lot for me. On a normal day my available energy is already quite limited, and the venue had a few challenges for me such as the only restrooms and the elevator we were using being on the other side of the building, which meant a whole lot of walking & standing to wait on hard floors so I was feeling more fatigued and in pain than usual.

To top that off my anxiety was sky high, and I have no idea how much I was masking but I think I may have ended up seeming like an unapproachable wallflower.. I promise I am very friendly, just extremely anxious and awkward! Despite that I ended up having a bunch of great conversations during the conference with a bunch of people, and it was amazing to get together with so many other Linux / FOSS / KDE nerds. 🤓

Around the end of Tuesday it was becoming apparent that I had caught a cold or something from one of the many sneezes or coughs I had attempted to dodge during this trip, and I missed out on the social activities on Wednesday and the last day of activities of Thursday. I enjoyed watching the progress on Matrix anyway! I am only now just starting to improve (I always struggle to fight off infections like this).

Several people had said they wanted to talk to me at some point, and we didn't get the chance before this cold knocked me out. Wie Schade! It isn't the same, but feel free to reach out to me on Matrix! @merritt:kde.org

It was really awesome to get together in Berlin, to meet so many new great people and to see familiar faces again, to work on so many interesting things together. I wish I had more energy after a long day to do more social stuff, because I loved getting the chance to interact with everyone in a more relaxed and informal way. Maybe we can figure out some more relaxed / quiet / sensory friendly social & food options next time for those of us who struggle with the loud, crowded, and chaotic environments that are often the default for social events.

Thanks Berlin for having us, even if the city is a bit noisy and has a surprising number of smokers, it was very nice to visit! Tschüss!! 😀 💙

Visiting my parents before going to Akademy I found the manual of my first Linux distribution ever: S.u.S.E. Linux 5.1 from 1997.

Given my first PC was some Pentium 100 with 16 MB of main memory and Windows 95, that was my first dive into open source software.

Seems I went in less than 2 years from starting on Windows to at least trying out Linux.

A few years later I joined the great KDE community and stayed there :)

:) Now I feel old.

Feedback

reddit - Do you still remember your first Linux distribution?

People have been a bit weirded by what happened during this period. People have been interested in this after the post by Jonathan Riddell was written.

Here's what I remember from the situation.

Order of events

1. I get laid off from previous job in 2023-10-10.
2. Nate Graham learns of this and invites me to join Blue Systems.
   • I would be joining the team that works with Valve contracts. Cool!
   • He had no power to really "invite" me but told me that there's a good spot I could fill.
   • I apply and cross my fingers
   • I get into interview and get hired!
3. I work for Blue Systems until ~31.10.2024, renewing the contract yearly.
4. Blue Systems holds a get-together in late 2024.
5. I am really bad with traveling due to anxiety and I was still recovering from the Akademy 2024, I skip this get-together.
6. I get a video call from the get-together, where I'm told news: the team that has the Valve contract is being laid off.
7. However! We also have this chance to start working with our single contract, Valve, in separate company.
   • Essentially, we, the team that works with Valve, are moving to new company and continue this contract under it's name.
8. A lot of chatter in work Telegram about how the new company should be governed.
9. A lot of differences in opinions. Long debates. Talks.
   • Everyone had their own opinions and plans.
10. My wife gets really sick and has to spend chunk of December in hospital.
    • I have zero energy for any of the work governance things.
    • I just wanted to make sure I have job and get my salary.
    • Thus, I did not really care what the plan was going to be.
11. Eventually, we decide Nate's plan for this is the easiest.
    • More info here Personal and professional updates — announcing Techpaladin Software
    • I would have been fine with whatever plan, as long as I get to keep my job and continue my work and getting paid.
    • I do not remember any kind of voting or anything like that. We just went with it. Everyone was very tired of this weird situation.
    • We all just wanted to get back to work.
12. Time goes by and TechPaladin is ready for continuing the work around March.
13. I have some small interview about the situation with Nate, and he asks me if I'm still interested to join.
    • No contract was made yet with anyone. TechPaladin was barely established at this point.
    • I assume everyone in Valve team went through this discussion. I do not know anything else.
    • We had no money to pay for non-Valve related work.
14. I end my contract with Blue Systems around March 2025.
15. I start my contract with TechPaladin around same week.
16. I still work there!

Messy.

Yeah, it's really messy. And I wish it had gone differently. But that's how things go.

I have been laid off before, twice.

First time when I was a very fresh programmer, I was suddenly told in middle of day that my contract will end right before my probation period will end.

Then second time, I went for a leave due to burnout, come back to work, and on same day I'm told I'm getting laid off.

It sucked.

So Jonathan, I can sympathize with your feelings about the situation. I hope you get help for your issues and warmth to your life. Sincerely. I do not have anything bad against you.

My experiences at TechPaladin

• TechPaladin has always paid my salary in time.
• My contract is completely legal where I live.
  • I'm sure I could negotiate it into something more shiny with help of lawyers, money and time.
  • But I trust TechPaladin to not screw me over.
  • And if they would do so, I would leave immediately and cut my losses.
• I've never been "abused" in any way.
  • People care about me there.
  • They notice if I'm burning out (looking at you Dolphin) and help me switch projects.

Sure, I might be naive for trusting a company like this. But I'm just like this. If I like the people who I work with, I trust them. This is not the first company I trust like this. It won't be the last either, probably.

And I just want to fix bugs in KDE software without having to think about the corporate stuff, but still have money for food and rent. TechPaladin lets me do that.

In the end, the contract is my choice and this is the choice I've made. So far so good.

And my friends and family know me. If TechPaladin would go against my values or rights, all of them would know.

Conclusions

Draw your own conclusions.

Or better yet, join KDE to help keep the project running: https://community.kde.org/Get_Involved

Maybe this post helps shine light on things, anyway. Not that I really need to do this, since it's all private matters, but since it's been blown open, meh. Might as well. I'm tired of the misinformation I've seen around.

glhf.

ps. if some youtuber reads this, hi

KWin Gamepad Plugin: Weeks 3-4

Picking up from weeks 1+2 ( research + prototypes with libevdev/uinput ), these two past weeks were about moving from “research-only mode” to turning ideas into programming logic that lives inside KWin to: detect gaming controllers and their input events, keeps Plasma awake on controller activity, handles hot-plug and pre-existing connections on startup, and lays down the first mappings from controller input to keyboard/mouse actions without stepping on other apps utilizing the controllers.

From the start my mentors and I have had a general idea of the features we wanted to add but weren't too sure how to implement them. After some thinking and experimenting they advised me to start off with a KWin::Plugin. This would allow us to start introducing the gaming controller functionalities to KWin while avoiding having to edit the core or guts of KWin. It would also be a great entry point for current and future game controller input objectives, allowing us to start small with a 1st party KWin plugin, build on it, and possibly integrate it into core functionality.

When it comes to creating KWin plugins I had a few options:

• Scripts: Written in QML/JavaScript and used for automating window management, tiling, shortcuts, etc.
• Effects: Implement visual effects on windows, the desktop, or transitions.
• Core/Native: These are built into KWin itself and extend KWin’s internal functionality.

Since the plugin needs low-level device access, such as monitoring /dev/input/event*, listening to udev hotplugs, opening fds, and reacting to evdev events the best choice was to go with Core / Native plugin. As opposed to Effect and Script plugins which aren’t designed to open devices or do long-running I/O, most simply just live inside the rendering/scripting layers.

I started off by searching for an example of how to build a KWin plugin so I could start learning how to build my own. Thankfully my mentor @zamundaaa provided me with some great examples:

• Example / Tutorial plugin located in src/plugin/examples/plugin
• Screenshots plugin located in src/plugins

Between both of these examples and mentoring I was able to piece together the scaffolding ( essential parts ) of a KWin plugin and was able to put together the first version of this plugin, gamepad plugin, located in: kwin/src/plugins/gamepad. At this point the plugin is structured as follows:

main.cpp // Entry point & Defines GamepadManagerFactory Class
metadata.json // Declares the plugin to KWin, define information about plugin
CMakeLists.txt // C++ Build/Installation/Logging wiring
gamepadManager.{cpp/h} // Plugin Logic: Defines GamepadManager Class
gamepad.{cpp/h} // Game Controller Object: Wrapper Class for Physical Controller

Implementation notes

GamepadManagerFactory

GamepadManagerFactory Class serves simply as the entry point for the plugin. It's a factory class, or a class used to create other classes / object types. Like the examples, it inherits from PluginFactory and declares it as its interface as well as pointing to the metadata.json file for this plugin. It initializes the plugin through its create() function which returns a GamepadManager.

GamepadManager

GamepadManager class serves as the central coordinator (the “brain” or “hub”) of the entire project. While creating this I took a lot of inspiration from src/backend/drm/drm_backend.{cpp/h}, which itself is responsible for handling drm/gpu devices. GamepadManager covers many responsibilities. It owns and manages all gamepad devices, handles discovery (startup enumeration, hot-plug), lifecycle (adding/removing), and communication (signals when pads are added/removed, or when their state changes). Overall its responsible for keeping track of the current set of controllers and their status.

Detect hot-plug and pre-existing device detection:

For this part many of the DRM backend pattern were used. The first thing the manager class does on initialization is create two QMetaObject::Connections that monitor the current KWin session for devicePaused and deviceResumed signals. This helps track devices when Plasma goes in and out of sleep/suspend which causes devices to be Paused and Resumed. It then enumerates over all event devices located in /dev/input/event* to handle any pre-existing connections to game controllers. If it discovers an event device it adds the gamepad ( start tracking it and its input ).

// On init:
// Enumerate current input nodes to filter and add ONLY event nodes
QDir dir(QStringLiteral("/dev/input"));
const auto files = dir.entryList({QStringLiteral("event*")}, QDir::Files | QDir::Readable | QDir::System);
for (const QString &file : files) {
 const QString path = dir.absoluteFilePath(file);
 if (!isTracked(path)) {
 addGamepad(path);
 }
}

Finally using udev it monitors the subsystems and filter for only "input" subsystem events. It uses QSocketNotifier to produce signal notifications from udev events and creates a connections between that notifier and a memeber function, handleUdevEvent, that handles events coming from the udev monitor when an input device is detecetd. Some checks are performed to verify if the device is a gaming controller, such as expected input events and input event types. This include input events like BTN_JOYSTICK and BTN_GAMEPAD, which are commonly defined in gaming controllers. As well as checking for joystick or D-pad capabilities. If the checks pass the game controller is "added", or in other words, the device is wrapped in a Gamepad class, kept track of and its presence monitored.

// setup udevMonitor
if (m_udevMonitor) {
 m_udevMonitor->filterSubsystemDevType("input");
 const int fd = m_udevMonitor->fd();
 if (fd != -1) {
 m_socketNotifier = std::make_unique<QSocketNotifier>(fd, QSocketNotifier::Read);
 connect(m_socketNotifier.get(), &QSocketNotifier::activated, this, &GamepadManager::handleUdevEvent);
 m_udevMonitor->enable();
 }
}

Gamepad

Gamepad is a wrapper class. It's purpose is to be tied to a physical controller. One Gamepad object per physical game controller. This enables quick access/reference to the device and allows for the physical controller to be treated like an object. This class is also responsible for device input handling, Plasma Idle refresh, and button to keyboard/mouse mappings. In the future things might get split up into seperate files but as it is, it handles a lot. As with the GamepadManager, this class takes a lot of inspiration from DRM backend patterns.

Detect Input Events:

Once a gaming controller device is detected it gets wrapped in a Gamepad class object. Which in turn wraps the controller in a libevdev object pointer. This is the part that gives access to the controller through the libevdev API, making it easier to work with it and monitor its input events. Like GamepadManager the first thing this class does is use QSocketNotifier to produce notifications from the controllers fd, i.e monitor for input. It then creates a connections between that notifier and a member function, handleEvdevEvent, which handles all incoming input events from that device.

libevdev *evdev = createEvDevice();
if (evdev) {
 m_evdev.reset(evdev);

 m_notifier = std::make_unique<QSocketNotifier>(m_fd, QSocketNotifier::Read, this);
 connect(m_notifier.get(), &QSocketNotifier::activated, this, &Gamepad::handleEvdevEvent);

 qCDebug(KWIN_GAMEPAD) << "Connected to Gamepad ( new libevdev* ): " << libevdev_get_name(m_evdev.get()) << "at" << m_path;
}

Plasma Idle Refresh On Controller Activity

With the ability to monitor for all input events from the device, the plugin then uses that information to know when to reset Plasma idle timer. For this Gamepad imports/includes input.h file and makes a call to input()->simulateUserActivity() when an input event is detected from the controller. This causes Plasma idle timer to be reset and prevents the system from going into sleep/suspend mode while using only gaming controller.

// reset idle time
input()->simulateUserActivity();

Controller -> Keyboard & Mouse Mapping

Gamepad uses API function from libevdev to check for input events, identify the specific input event and map that to a keyboard or mouse input event. Using libevdev_next_event() it checks for the input event coming from that game controller. It then identifies the specific input event through its input event type, code, and value. To simulate a mouse and keyboard the core/inputdevice.h file is imported and used to declare GenericInputDevice which inherits from InputDevice. That GenericInputDevice effectively behaves like a virtual keyboard and mouse inside KWin’s input stack.

When specific libevdev input event are identified, such as EV_KEY + BTN_SOUTH ( A button press ) OR EV_KEY + BTN_EAST ( B button press ), it call InputDevice::sendKey() to simulate keyboard key press and inject the desired keys into KWin input pipeline. In this case Enter for A ( BTN_SOUTH ) and Escape for B ( BTN_EAST ). To emulate mouse/pointer the plugin makes calls to InputDevice::sendPointerButton() for left and right mouse buttons, and InputDevice::sendPointerMotionDelta() for pointer movement.

Here is a list of all the buttons to keyboard/mouse mappings:

Face Buttons
------------
BTN_SOUTH → Enter (Qt::Key_Return)
BTN_EAST → Escape (Qt::Key_Escape)
BTN_NORTH
BTN_WEST

Bumpers
-------
BTN_TL → Alt (Qt::Key_Alt)
BTN_TR → Tab (Qt::Key_Tab)

Trigger Buttons
---------------
ABS_Z → Mouse Left Click
ABS_RZ → Mouse Right Click

D-Pad
-----
BTN_DPAD_LEFT → Arrow Left (Qt::Key_Left)
BTN_DPAD_RIGHT → Arrow Right (Qt::Key_Right)
BTN_DPAD_UP → Arrow Up (Qt::Key_Up)
BTN_DPAD_DOWN → Arrow Down (Qt::Key_Down)

Analog Sticks
-------------
ABS_RX / ABS_RY → Pointer Motion

Center Buttons
--------------
BTN_SELECT → Show On-Screen Keyboard ( WIP )
BTN_START → Meta/Super (Qt::Key_Meta)

Prevent Stepping On Other Apps

It's essential that the plugin doesn't emulate keyboard and mouse for the gaming controller when another app is reading from it. Most likely in such cases the device is being used for something else and not being used to navigate the desktop. To achieve this the GamepadManager class creates an instance of inotify object, and adds a watch device to the fd of each game controller that’s added as a Gamepad. Whenever inotify produces a notification a function, GamepadManager::handleFdAccess, is called which increments a counter in Gamepad, Gamepad::m_usageCount by +1 if the event value is IN_OPEN or Gamepad::m_usageCount by -1 if the event value is IN_CLOSE_WRITE | IN_CLOSE_NOWRITE. The plugin will only attempt to emualte keyboard/mouse if m_usageCount is 0. This prevents emulation of keyboard and mouse when other apps have the game controller opened / in use.

// Process all inotify events in the buffer
for (char *ptr = buffer; ptr < buffer + length;) {
 struct inotify_event *event = reinterpret_cast<struct inotify_event *>(ptr);

 auto it = m_watchesToGamepads.find(event->wd);
 if (it != m_watchesToGamepads.end()) {
 Gamepad *pad = it.value();
 if (event->mask & IN_OPEN) {
 pad->countUsage(+1);
 } else if (event->mask & (IN_CLOSE_WRITE | IN_CLOSE_NOWRITE)) {
 pad->countUsage(-1);
 }
 qCDebug(KWIN_GAMEPAD) << "Device" << pad->path() << "in use by:" << pad->usageCount() << " other apps";
 }
 ptr += sizeof(struct inotify_event) + event->len;
}

Opt-In

Many of the native plugins that ship with KWin are enabled by default but for our gaming controller plugin we will disable it by default and make it an opt-in option. This will allow users to start experimenting and benefiting from the plugin without risking the possibility of breaking current game controller input on their system.

{
 "KPlugin": {
 "Category": "Input",
 "Description": "Enable KWin game controller input detection",
 "EnabledByDefault": false, <---------- Not enabled by default. 
 "License": "GPL",
 "Name": "gamepad"
 },
 "X-KDE-ServiceTypes": ["KWin/Plugin"]
}

Testing

• Controller awareness at startup and hot-plugging: tested in development session, KWin logs show the plugin picking up controllers in both scenarios, works as expected.
• Preventing sleep/suspend: tested in development session. Set suspend timer to 1min, repeatedly press A and B back and forth, and at 5min no suspend was initiated, works as expected.
• USB and Bluetooth connectivity support: tested in development session, KWin logs show plugin picking up on the controllers in both scenarios, works as expected.
• Mapping from controller to keyboard and mouse: tested in development session, all buttons are map to expected keyboard and mouse, works as expected.
• Backoff On Grab: tested in development session. Verified mapping work, started Steam app, verify mapping no longer enabled.

Testing device: 8Bitdo Gaming Controller (USB/2.4h/Bluetooth)

What’s next from here

• Integration into KWin Proper: Start pushing changes upstream for others to test.
• Map to Virtual Keyboard: Allow users to navigate over and get input from a virtual keyboard. Might open the way for logging in using only game controller.
• Test Cases: As per best practices when developing for KWin.
• KCM integration: A GUI option for users to toggle plugin ON/OFF. Ground work for more robust, user defined, button remapping.
• Use Config for Mapping: Using a config file to keep track of and read from all the button to keyboard/mouse button mapping.

Reference documentation:

• Example / Tutorial KWin Plugin: https://invent.kde.org/plasma/kwin/-/tree/master/examples/plugin
• Screenshots KWin Plugin: https://invent.kde.org/plasma/kwin/-/tree/33262fef1a6e4e3bcebc05181edbde2d9a72f38c/src/plugins/screenshot
• DRM Backend: https://invent.kde.org/yorisoft/kwin/-/tree/master/src/backends/drm/drm_backend.cpp
• Linux Input Subsystem (overview): https://www.kernel.org/doc/html/latest/input/index.html
• Libevdev Library: https://www.freedesktop.org/software/libevdev/doc/latest/
• Udev Library: https://man7.org/linux/man-pages/man7/udev.7.html
• Inotify Library: https://man7.org/linux/man-pages/man7/inotify.7.html

Checkout the source code here: KWin Gamepad Plugin: https://invent.kde.org/yorisoft/kwin/-/tree/work/yorisoft/gamepad-plugin/src/plugins/gamepad

I was at Akademy 2025 last-last week where I did some preliminary research on optimizing the VM viewer’s display rendering on Karton. After some more work this past week, it’s somewhat here! I’m still finishing up the merge request, but exciting news to come!

This has been something I’ve been planning on for quite a while now and will significantly improve the experience using Karton :)

a comparison with an old video I had.

Old Rendering Pipeline

My original approach for rendering listened to display-primary-create and invalidate-display-primary SPICE signals. Everytime it received a callback, it would create a new QImage and render that to the QQuickItem (the viewer window). As you can imagine, this was very inefficient as it is basically generating new images for every single frame being rendered. It suffered a lot from screen-tearing any time there were sudden changes to the screen.

You can read more about my experiences in my SPICE client blog.

We can do better!

Rendering via OpenGL can offload a lot of these tasks to the GPU and can significantly improve performance. I had known about GL properties in SPICE for a while now, but I kept putting it off since I really didn’t want to deal with any more graphics stuff after my last attempt.

Fast forward to last-last week, I was attending my first ever KDE Akademy in Berlin and all of a sudden gained some motivation.

It was really exciting hearing talks about all the kool things happening in KDE.

gl-draw

My first order of business was getting the gl-draw signal to properly receive gl-scanouts from my SPICE connection. After setting up the callback, I found out that I had to reconfigure my VMs to properly support it.

This was easy enough as I’ve made the Karton VM installation classes a few months ago done through the libvirt domain XML format. VMs need enabling of GL and 3D acceleration through the graphics element in the XML. The socket connection to SPICE also had to be switched from TCP to UNIX, which was set to /tmp/spice-vm{uuid}.sock. As a result, previous VMs configured in Karton will no longer work as the previous rendering pipeline has been removed.

<graphics type="spice" socket="/tmp/spice-vm{uuid}.sock">
    <listen type="socket" socket="/tmp/spice-vm{uuid}.sock"/>
    <gl enable="yes"/>
</graphics>
<video>
    <model type="virtio" heads="1" primary="yes">
        <acceleration accel3d="yes"/>
    </model>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
</video>

An example libvirt domain XML snippet generated by Karton

Once properly configured, I was able to get SpiceGlScanout objects from my callback linked to the gl-draw signal. Now, I needed to render these scanouts onto my QQuickItem canvas.

EGL stuff

Having no background in graphics, I pretty much had no idea what I was doing by this point.

The SpiceGlScanout is a struct that looks like this:

struct SpiceGlScanout {
    gint fd;
    guint32 width;
    guint32 height;
    guint32 stride;
    guint32 format;
    gboolean y0top;
};

The width, height, stride, etc…, are all parameters that can be used to set your final rendered frame, but the important field is the fd (file descriptor) which is a “a drm DMABUF file that can be imported with eglCreateImageKHR”. I didn’t know what that was; but at least I learned I should be using the EGL library to do the processing.

I had found some forum articles (Qt forum, Arm developer forum) related to rendering OpenGL textures which used the EGL library and were quite helpful. I also looked at the SPICE GTK widget source code which gave me some ideas on the GL parameters to work with.

From these references, I saw that they pretty much followed the same pattern. Very simply put:

-> create egl image from a bunch of attributes/settings
-> generate texture from the fd 
-> bind texture to a texture type 
-> "glEGLImageTargetTexture2DOES" use this function?? still don't know what this does lol
-> destroy egl image

I originally tried setting the GL context properties manually, but there were some issues with getting it to detect my display and apparently thread syncronization. Then, I found out that Qt had a QOpenGLFunctions library which had all of the EGL functions and context properties wrapped and made my life a whole bunch easier.

OpenGL texture -> Qt

After a ton of trial and error, it looked like my EGL images were properly being created. Now I needed to render these GL textures to the QQuickItem.

How you do so is, within the inherited updatePaintNode() function, you return a QSGNode which has the information for updating that frame. Looking through the Qt documentation, QNativeTexture is a struct that allows you to store a texture ID to an OpenGL image. With that, you can create a wrapper QRhi class from the QNativeTexture with some of the generic context of your display.

Finally, you can use the createTextureFromRhiTexture() function under QQuickWindow which allows you to create a QSGTexture from that RHI for a QSGNode that can be returned by updatePaintNode(). And, we’re done! Yay!

To sum it up, here’s the framebuffer pipeline:

gl-draw signal->receive gl-scanout->import GL texture->GL texture ID->QNativeTexture->QRhi->QSGTexture->QSGNode->QQuickItem

so much smoother! yes, I was very excited.

Socials

Website: https://kenoi.dev/

Mastodon: https://mastodon.social/@kenoi

GitLab: https://invent.kde.org/kenoi

GitHub: https://github.com/kenoi1

Matrix: @kenoi:matrix.org

Discord: kenyoy

I’m happy to announce the 0.8.2 release of Subtitle Composer.

This release contains bugfixes and few improvements including:

• Fixed issues and crashes with newer Qt6 versions
• Fixed Waveform and VideoPlayer paint issues
• Fixed PGS subtitle mime type
• Improved Wayland compatibility
• Improved GoogleCloudEngine translations
• Added configurable whitespace detection to VobSub import
• Replaced deprecated FFmpeg channel code
• Require FFmpeg >= 5.1.5

As usual all binaries are available from download page.

Source tarball can be downloaded from download.kde.org.

— Mladen

I was able to attend the talks at Akademy this year in Berlin! The last time I attended Akademy in person was in 2022, so it was really nice being able to come back and meet everyone again.

I was unfortunately not able to attend BoFs (development meetings) due to having to leave early. I did attend some meetings a few months earlier however, you can read more in my Plasma sprint recap post.

Talks 🔗

Akademy runs with two concurrent tracks of talks, and so sometimes there were two talks at the same that I both wanted to attend, I had a hard time deciding! Here are some of the ones I attended:

KDE Linux: Banana Growth Cycle 🔗

Harald released KDE Linux Alpha was to the public during the talk! I hadn’t followed the project super closely, but it was awesome getting up to speed learning about the state of the project and the inner workings of how the distribution works.

The Role of New Languages in the Future of the Qt Ecosystem 🔗

I was introduced to Qt Bridges, which is an effort to go beyond Qt bindings for other languages and tightly integrate with them (ex. Rust, Python). Once this is more mature, it will likely be an easy recommendation for others to start learning Qt with, who don’t want to use C++!

KDE Goals - One Year Recap 🔗

It was interesting to see all the work that had been done on the KDE Goals so far!

I am actually involved with one of them this time around (“We care about your input”) through my work on plasma-keyboard. Blog post likely coming in a few months, once that work is further along!

Next-Gen Documentation Infrastructure for KDE 🔗

KDE’s reference API documentation has been a bit of sore spot for me, since it didn’t support QML very well. As a result, I usually go manually go through header files instead in the source code to figure out how to use libraries.

The talk went over Nicolas’s work on doing the mammoth task of porting all of KDE’s API documentation to QDoc from Doxygen, which properly supports QML. The new api.kde.org went live, and boy is it such an improvement! It’s much easier for me to point new developers to the Kirigami documentation now.

Fedora KDE Plasma Desktop Edition is Real, Now What? 🔗

I personally use Fedora on my workstation and laptops, and so it was cool to get some history about how Plasma on Fedora was revived in the past, and plans for the future. Neal also expressed some interest in a Plasma Bigscreen spin (similar to the one for Plasma Mobile), which could be pretty interesting once it becomes more mature!

Plasma Mobile Power Management: Reliable Sleep and Wake Ups 🔗

Bhushan gave an update on his work power management work across the Plasma stack! He obtained an NLNet grant recently for the project, detailed on his blog.

Discussions 🔗

I was really happy to meet and discuss with quite a few people during the event.

I met Bart, Luca, Casey and Pablo from the postmarketOS project! As it is the main platform I test and develop Plasma Mobile with, it was really nice to finally meet some of their developers (I had met Bart and Luca at Akademy 2022)! I also was able to finally meet Florian, who has been collaborating with me in contributing to Plasma Mobile in the past few years!

I met Dorota, who has been working on Wayland input related things for the past few years, and is in the process of pushing through updates to text-input-v3, and Jakob who has been working on the KDE side pushing through the input related KDE goals! We discussed some input related topics, which was insightful as I worked on the client side through plasma-keyboard (and my limited Wayland knowledge).

I also discussed some Kirigami page navigation related topics with Marco. I’m doing a bit of investigation into how we can improve the way we navigate between pages in applications, and perhaps restricting the page left/right gesture into the side (similar to iOS).

From the 3rd to the 5th of September, the Kdenlive team was reunited in Berlin for a sprint and to attend Akademy, KDE's annual conference. This was an occasion for us to meet in person since our team is spread across continents, and to join our forces to make Kdenlive better. And I must say this was one of the most productive sprints in Kdenlive's history!

We were kindly hosted by c-base for our Sprint so a big thanks to the team for welcoming us there!

Let's get into the details of what we did:

We started by reviewing and updating our roadmap, so it is easier to understand what we are working on, what we plan and when. Another important step towards improving our workflows is that we created issues for each of these goals where the details will be discussed, so everyone can follow and possibly help us on the road to success.

Dopesheet

Very exciting, I received a grant from the NGI Zero Commons Fund through NLnet to work on a dopesheet feature in Kdenlive. This will bring a much improved keyframing interface with powerful features. We discussed what core features we want in it and some drafts on how that would work. This feature won't be ready for the December release, but I will post updates on the progress of this task in the coming months.

We then reviewed specific parts of the UI that we would like to improve. All these ideas will be discussed in specific issues so that we can refine the implementation.

Menu reorganization

This task started two years ago but we never took time to finalize it. We progressed a lot on this and you can expect it to land in the December release. Among the changes, we decided to rename the Project Bin to Media, Render to Export, and reorganize the menus to make things more logical. We will make another blog to present these changes in detail once this is done.

Timeline toolbar

We want to cleanup the UI, make the timeline timecode display cleaner and get rid of the large Master button currently taking a lot of space.

Monitor UI

We plan to move the audio vu-meter to a collapsible vertical widget on the right side of the monitor to free some space in the toolbar, make the zone duration always visible and move the insert/overwrite actions currently in the timeline toolbar there.

Audio monitor

When selecting an audio clip, the Clip Monitor currently displays a huge audio waveform that is not that useful. We reviewed the UI to also display an overview at the top, making it easier to zoom and see where you are in the clip.

Layout and docks

We have several open issues regarding docking. One of the frequent request we have is to save the layout per project file, since sometimes you want very specific layouts for a project. We discussed how to make it happen and are also evaluating switching the library managing the widgets docking to KDDockWidgets that would bring us some very nice improvements like being able to detach the timeline or group several undocked widgets together

Titler

Our current titler does the job for simple tasks but many users would like to be able to use some animation presets to make their titles more dynamic. We discussed the possible options to make this a reality. Among the ideas, we could use Lottie animations, since our video backend MLT already has support to play them through the Glaxnimate module. Another option would be to implement a Qml producer for MLT, allowing to play Qml files directly as a video. Any help on that topic is welcome.

Website

We have some planned changes to make our website look better and discussed some of the options.

And all the rest

Akademy 2025

Akademy was also an occasion to have interesting exchanges, notably with Glaxnimate's maintainer, Plasma developers and more. We are now back home with tons of ideas and TODO's, and the next release of Kdenlive, to be launched in December, will shine with some of the improvements we prepared during this week in Berlin !

If you would like to help our small team, you are always welcome to contribute by giving some feedback, talk about us, create a merge request or donate.

Despite the lack of posts (which we apologise for) the builds have continued to happen on the neon build servers. Packages for Plasma 6.4.5, coupled with KDE frameworks 6.18, and KDE release service 25.08.1 built on top of Qt 6.9.2 have just been released to the neon user archives. Live Image ISO’s and containers are available for download from the usual location.

The builds will continue to happen for the foreseeable future and hope that everyone enjoys the latest and greatest KDE created software, if that’s your cup of tea.