kde on espidev

Akademy 2025

Sun, 14 Sep 2025 19:00:00 +0000

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).

Diving into Plasma Bigscreen

Thu, 10 Jul 2025 19:00:00 +0000

I have been a long time Plasma Mobile contributor, but I have always had a keen interest in having Linux on my TV! I have noticed that in the past few months, the Plasma Bigscreen project has had some interest from people wanting to contribute, but there have not been any active KDE developers working on the project. Since I have some time off school (having just graduated university), I decided to take a swing at improving the project for a week.

Background 🔗

Plasma Bigscreen is a Plasma-based shell (desktop environment) for TVs and other large displays. It is designed to be used with arrow navigation using remotes or controllers.

I have not been involved with the project in the past so its history is a bit murky to me. From what I know, it was originally developed with Mycroft in mind, which was a open source virtual assistant. They had even developed hardware for it, but unfortunately, the company shut down in recent years. The work by the developers at that time appears to have been sponsored by Blue Systems.

Plasma Bigscreen itself emerged around 2020 and was designed as a “Plasma shell”, in a similar way to Plasma Desktop and Plasma Mobile. Back when development was active, it provided a TV friendly launcher to launch Linux apps, and even had its own “mini-apps”, known as Mycroft Skills. These could be downloaded from the KDE Store. A TV-friendly web browser and media player were also developed for the project. The project itself was released in the Plasma 5 release cycle, but got dropped with Plasma 6 in 2024 because it was not ported in time for the megarelease.

About a year ago, the project was ported to Plasma 6 (and Qt 6), but has not yet received a release since being removed from the Plasma release schedule.

Stepping in 🔗

A few months ago, my friend Seshan started doing some work and opened a few merge requests against the Plasma Bigscreen shell repository. I noticed that there had basically been no activity on the repository since the initial Qt6/Plasma6 port, and the matrix channel had no active developers. I sensed an opportunity…

Housekeeping 🔗

I started with some housekeeping work with the repository. I added a README, and a REUSE license checker to the CI. I then ported the QML library to be a declarative plugin, and removed a bunch of abandoned code folders that were not used anywhere in the codebase.

Merge requests:

UI 🔗

At this point prior to my work, the shell UI looked like this:

I was digging around some old Breeze Ocean mockups and stumbled across some Bigscreen mockups by Manuel. It seems the original Bigscreen UI did try to follow it, but did not quite get there. I felt inspired to fully complete implementing them.

Homescreen 🔗

I first worked on the homescreen UI. I flattened the layout to reduce visual complexity, removing panel backgrounds and shadows where possible, while adding tooltips for the indicators. I then added an “expanded clock” view for when the user is at the top of application categories (based on the mockups), which shrinks when the user goes down the view. I ported the application lists to use ListView and delegate caching rather than having all elements having their coordinates positioned manually to improve performance. The background now also blurs when it is not the main focus of the UI.

I also added a search view based on KRunner. This allows users to search for the applications they need without needing to manually scroll through the entire application list.

Merge requests:

Settings 🔗

I redesigned the system settings view to have a sidebar with categories, with a simple two-pane look.

The settings modules (KCMs) had a lot of hardcoded UI elements and layouts. I decided to make a small component library to build TV focused UIs (that still look Breeze like), and ported all of the settings modules to it. I moved away from horizontal layouts to vertical layouts for content, and put a heavier emphasis on sidebars for interacting with individual delegates. I think it looks pretty nice:

I ported settings modules to my controls library, and also fixed some issues:

Display KCM (rewritten with libkscreen backend, as it was otherwise completely broken)
Sound KCM (ported to new UI)
KDE Connect KCM (ported to new UI, fixed some state issues)
Bigscreen KCM (ported to new UI, fix shortcuts, fixed timezone selection)
Wi-Fi KCM (ported to new UI)

Merge requests:

https://invent.kde.org/plasma/plasma-bigscreen/-/merge_requests/115 (rework settings app)
https://invent.kde.org/plasma/plasma-bigscreen/-/merge_requests/129 (controls library)
https://invent.kde.org/plasma/plasma-bigscreen/-/merge_requests/130 (kdeconnect)
https://invent.kde.org/plasma/plasma-bigscreen/-/merge_requests/131 (bigscreen settings)
https://invent.kde.org/plasma/plasma-bigscreen/-/merge_requests/132 (audio)
https://invent.kde.org/plasma/plasma-bigscreen/-/merge_requests/139 (don’t sort settings modules with bogosort)
https://invent.kde.org/plasma/plasma-bigscreen/-/merge_requests/145 (displays)

Startup feedback 🔗

The UI feedback for starting an application was broken, so I decided to overhaul it to be something similar to what we have on mobile:

Merge request:

https://invent.kde.org/plasma/plasma-bigscreen/-/merge_requests/125

Envmanager 🔗

I wrote envmanager as a program in Plasma Mobile that manages shell specific configuration we need in services such as KWin. This avoids the need for distros to ship custom configs to set certain settings that the shell needs. I recently changed Plasma Mobile to use config overlays in order to achieve this, with more details can be found in my other blog post.

Merge requests:

https://invent.kde.org/plasma/plasma-bigscreen/-/merge_requests/109 (import from Plasma Mobile, by Seshan)
https://invent.kde.org/plasma/plasma-bigscreen/-/merge_requests/113 (port to overlays)

Trying it out 🔗

In order to try it out (on a TV for realsies, not just on my workstation), I used a Raspberry Pi 5. I flashed postmarketOS onto it, and then manually compiled and installed the Plasma Bigscreen shell.

Note: If you are trying to build and install on postmarketOS yourself, be sure install the dependencies and pass the build flags in this manifest, as they are required: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/blob/ee4de8c6702a113914d6ed899c88cb9411e75427/packages/plasma-bigscreen/APKBUILD#L57

As a user you can otherwise install plasma-bigscreen from the nightly repo, or use the AUR package on Arch (though I haven’t tried it).

It’s dangling off the HDMI cable, I know

Applications 🔗

In its heyday, Plasma Bigscreen relied on “Mycroft Skills” to provide some media applications such as YouTube and SoundCloud. We do not have that anymore, so I tried out some other Linux applications.

These are some of the ones I tried from Flathub:

Kodi - Works well with arrow navigation, allows you to manage a local digital library of content
VacuumTube - Provides the YouTube TV web UI wrapped in an application, works well with arrow navigation
Jellyfin - I don’t have a Jellyfin server; it launches fine but I don’t think it supports arrow navigation
SuperTux - Fun game!
SuperTuxKart - It ran somewhat poorly on the Pi, but playing it with a controller was quite nice!

Of course, we also have KDE applications designed for TV:

Controller support 🔗

There is a repository called plasma-remotecontrollers, which contains a daemon that is able to take both game controllers (ex. Xbox) and TV remotes (over CEC on HDMI) and map them to keyboard arrow keys. It also has a settings module to configure the shortcuts.

I was able to successfully test having an Xbox controller connected (with the daemon online), and having it map the arrow buttons to arrow keys on the system. I wasn’t able to however test the CEC support, which would allow buttons on TV remotes (over HDMI) map to arrow keys.

Other contributors 🔗

Seshan and User8395 have also been contributing to the project here and there in the past few weeks, here are some highlights:

https://invent.kde.org/plasma/plasma-bigscreen/-/merge_requests/127 - (Seshan - Add a UVC viewer app)
https://invent.kde.org/plasma/plasma-bigscreen/-/merge_requests/117 - (Seshan - Add an “app” to swap session directly from Plasma Desktop)
https://invent.kde.org/plasma/plasma-bigscreen/-/merge_requests/123 - (Seshan - Make Meta key go to home)
https://invent.kde.org/plasma/plasma-bigscreen/-/merge_requests/106 - (Seshan - Improve the favorites selector)
https://invent.kde.org/plasma/plasma-bigscreen/-/merge_requests/147 - (User8395 - Create a new bluetooth KCM)

Unresolved issues 🔗

There is still a lot to work on in the project.

Input 🔗

There isn’t a virtual keyboard to input text with that supports arrow navigation. This is something planned for Plasma Keyboard however, please stay tuned!

The plasma-remotecontrollers’s (TV remote/game controller support) settings module is also not yet properly ported and tested on Bigscreen.

So… it is probably best to still use a bluetooth keyboard and mouse for now, or an air remote.

Application design 🔗

We do not have any framework to design TV-based UIs in KDE. Aura browser and Plank both use Qt Quick Controls and Kirigami, but have a lot of hardcoding and custom controls in order to be usable on a TV. I do have a few TV focused components for building settings modules, but that is a very narrow set of controls.

Goals 🔗

What are the usecases we want to achieve with a TV focused desktop environment? Do we need to also pursue making frontends for various media services? There isn’t a clear direction for the project at the moment, beyond making it a working desktop environment. In the past, this project was heavily focused on Mycroft but that no longer exists.

Getting it released again 🔗

Distributions dropped their respective plasma-bigscreen packages when Plasma 6 rolled out, as it is no longer part of the Plasma release. We need to have the project return to the Plasma release cycle, hopefully starting with Plasma 6.5.

Overall 🔗

I am fairly happy with the work that I was able to produce for Bigscreen last month. I have since returned to working on Plasma Mobile (due to having limited time as a volunteer contributor), but I can still step in and help review merge requests and guide new contributors to the project.

Feel free to join us in the Bigscreen Matrix group #plasma-bigscreen:kde.org!

A libcamera port of Plasma Camera

Mon, 07 Jul 2025 00:00:00 +0000

Cameras!

Today, I am announcing a new release of Plasma Camera, a camera application for Plasma Mobile (though it can also be used on desktop!). This release ports the application to use libcamera as the backend for interfacing with cameras, finally allowing for it to be used on Linux mobile devices (such as the OnePlus 6).

The main porting work was done by my friend Andrew (koitu) a couple of months ago. It remained stalled on some issues, so I picked it up in the past week to complete the port and finish the application. Here is a link, which has more technical details!

Background 🔗

Cameras have been a long neglected area in Plasma Mobile, ever since the focus shifted from halium to mainline devices. With mainline devices, libcamera drivers have been developed for them, allowing for cameras to be used in applications over Pipewire (ex. GNOME Snapshot, Firefox, Chromium).

Plasma Camera was originally created in 2019 with halium devices in mind, using the official Qt Camera library as a backend for interfacing with cameras. This library allows for the app to work on Android and on desktop with USB webcams. Unfortunately, Qt Camera does not currently have support for using Pipewire or libcamera directly as a backend, and so is unable to interface with the cameras on the OnePlus 6 and Pixel 3a.

Porting Plasma Camera 🔗

Qt Camera is a fairly high-level API designed to abstract over many different platforms, beyond Linux. Since our focus is on Linux, we decided to take this chance to port Plasma Camera to use libcamera directly for best control over the camera pipeline and features. Note that this approach differs from some other camera applications that use Pipewire, which has a backend to communicate with libcamera.

The API for libcamera is fairly comprehensive.

In order to implement the viewfinder (camera preview), we create a worker thread that is responsible for polling the camera for frames. A series of “requests” with a framebuffers allocated to each were created, which we cycle through when polling for frames. Libcamera then gives us a frame for each poll request, in which we send to our application thread to display.

For simplicity, Qt Multimedia was used for media processing. Frames from libcamera are wrapped in QImages and sent to a QVideoSink to be displayed in the UI. Any transformations needed (such as rotation correction due to how sensors are mounted on phones, or mirroring for front-facing cameras) are done before the frame is added to the sink. For taking photos and videos, we reuse the viewfinder’s frames.

For photos, we simply write the QImage to the disk.

Videos are much more tricky. Using Qt Multimedia we can build a video processing pipeline. We create a QMediaCaptureSession to facilitate all of the inputs and outputs needed. We then attach a media recorder QMediaRecorder for writing the video, an audio input (QAudioInput) and a video input (QVideoFrameInput). We have a separate polling timer that polls at the framerate of the video (which can differ from the framerate of the viewfinder), copying frames one-by-one into the QVideoFrameInput instance (more on this later) to be encoded by QMediaRecorder.

In the future, it may make sense to investigate whether we could benefit from porting to using GStreamer directly for media processing. We currently use Qt Multimedia with its ffmpeg backend. While Qt Multimedia does have an gstreamer backend, it has some limitations and was thus removed from being the default backend as a result.

UI work 🔗

I also took the liberty of doing some substantial refactoring and reworking of the UI code. We dropped some camera settings for the initial port of the application, to be restored later. However some other features were introduced.

The application has these features:

Photo capture
Video capture
Audio recording toggle for video capture
EV setting (exposure value)
Captured photo/video preview
Video recording settings (codec, resolution, FPS, quality)
Timer before taking a photo
Warnings for when the encoder is detected to not be keeping up with the video stream
Settings persistence

Results 🔗

With USB webcams, both photo capture and video recording work.

It also sort of works on phones. I tested on the OnePlus 6 and Pixel 3a. I suspect that most of the issues are simply due to the camera driver not yet being mature enough, as I can replicate most of the issues on other camera applications. The photo quality and colours are not optimal, and there appears to be a fixed focal length, and so far away things look blurry.

The viewfinder stream is fine on my OnePlus 6 and looks smooth. However, for my Pixel 3a, the frames start flashing light and dark colours when I point the camera at any bright light source. I suspect it is due to the camera driver overcompensating for exposure perhaps? Not sure 😅

Photo capture works on both devices, outputting the frame from the viewfinder at full resolution to the disk almost instantly. Though the quality of the pictures is reminiscent of early 2000s phone photography.

The video recording experience however isn’t quite usable unfortunately, the video encoder does not appear to be able to keep up.

Limitations 🔗

Video recording issues on phones 🔗

The main barrier to video recording seems to be the performance of the video encoder. I’ve noticed on both phones that many frame calls to QVideoFrameInput fail because QMediaRecorder’s queue is simply full and cannot keep up with the amount of frames coming in. This can be mitigated somewhat by playing with the video recording settings. I’ve generally found the MPEG2 codec to be substantially faster for devices, though it gives very ugly artifacting at low quality, and sometimes gives an error. Of course, lowering the resolution and FPS also can help too.

For each frame given to QVideoFrameInput, I also set its timestamp to ensure that the encoder places it at the correct place. However, when we start dropping frames due to the encoder being full, we end up with gaps in the video without a frame, which I suspect is what is causing the pixelated “corrupt video” effect (though it only happens with H264, and not MPEG2 encoding?). We cannot really queue frames for the encoder, because we would very quickly run out of memory. I have an open issue about this since I am not really sure how to address it yet.

Rotation issues 🔗

Device rotation can be a bit of a problem with the application right now. We already account for the screen orientation in comparison to the camera orientation, which is reported as a property by libcamera.

The viewfinder however can be a problem when the display rotation is different from the screen’s orientation (ex. rotated 90, 180, 270 degrees). This is done by the compositor (ex. KWin), the application only sees that the window size has changed. However, that means the viewfinder is rotated as well! We are able to adjust for this in taken photos and video by reading the rotation sensor data (with QOrientationSensor/iio-sensor-proxy), however we cannot do the same for the viewfinder because we don’t know which orientation the compositor has the application in, which could be different from the sensor due to rotation-lock and manual settings.

I recommend keeping an orientation lock on “portrait” mode when using the application on a phone until we find a fix, that way the viewfinder does not get mismatched from what you see. We are tracking this issue here: https://invent.kde.org/plasma-mobile/plasma-camera/-/issues/14

Missing camera controls 🔗

The drivers for the OnePlus 6 and Pixel 3a seem to be missing almost all of the libcamera controls. At least, calling camera->controls() (doc) gives only the Contrast control from libcamera. There are other controls that I would like to implement once they become available, such as focus windows.

Once these are implemented in the driver (or if it’s fixed as an issue on our side) and support is added in the application, we will have a lot more camera features to play with!

Conclusion 🔗

We finally have a base on to use for the camera stack on Linux mobile. I hope the application continues to improve as drivers and camera support get better over time on these devices.

So, give it a try! And feel free to come join us to talk about it in the Plasma Mobile matrix channel!

A Plasma (Mobile) Sprint in Graz

Sat, 03 May 2025 11:26:29 +0100

I attended the Plasma sprint this year in Graz, Austria!

It has been a couple of years since I have last met KDE contributors in-person (Akademy 2022), so I really looked forward to finally being able to meet again. This sprint was the first time I met Bhushan, who is a long time contributor to Plasma Mobile, and was the one that initially guided me through contributions! He recently got funding to overhaul and improve the power management stack we have in Plasma Mobile, which you can read about here. I also met Luis for the first time, who has been contributing to the project for quite a while, notably having contributed the system navigation gestures we have now!

I brought my brother along as well, who is starting to also make contributions to KDE. After the sprint, we travelled around a bit (I will eventually have another post about it, link coming when that happens). This post will focus on just the sprint itself.

Be sure to also check out blog posts about the sprint by other Plasma developers over at planet.kde.org.

Photo by Kevin Krammer

Lockscreen overlays and more 🔗

A few years ago, Aleix implemented the ability to allow windows to be overlaid on top of the lockscreen. We utilize this for the Phone dialer application in order to have the call screen show up over the lockscreen. In the past, I had made some attempts to also have the power menu, status bar, and quick settings panel also shown over the lockscreen, but was unsuccessful. At the sprint, we were able to make it happen!

For the power menu, Bhushan first investigated why the holding the power button on the lockscreen did not get passed to the shell. After a rabbit chase through many different places, he was able to create a fix. With Luis and the KWin developers, he also figured out why lockscreen overlays would get stuck visually after they are closed (fix).

After those fixes were done, Bhushan and I spent some time figuring out why my old merge requests did not work. We were eventually able to fix it up and get it working (video in this merge request)! We also investigated overlaying the status bar and quick settings panel from the shell to improve the lockscreen load time. While I was not able to finish the implementation at the sprint, we got the fundamental parts working too!

https://invent.kde.org/plasma/kwin/-/merge_requests/6752 (Restore lockscreen overlay test)
https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/270 (Status bar and quick settings overlay on lockscreen)
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2406 (Power screen overlay on lockscreen)

I also did some more investigation into the performance of the lockscreen. We currently load a new status bar and quick settings panel when the device is locked (as part of the lockscreen theme), which have some components that load quite slowly.

Merge requests related to this investigation:

https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/714 (Plasma-nm singleton)
https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/713 (Load speed test)
https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/715 (caffeine quicksetting: Port away from DataSource)
https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/718 (record quicksetting: load less things initially)
https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/710 (Lockscreen keypad sync load)

Kirigami 🔗

Marco was at the sprint, and so I had the opportunity to discuss some mobile related issues with him.

Marco made the following fixes:

https://invent.kde.org/frameworks/kirigami/-/merge_requests/1784 (Fix vertical/horizontal touch drag detection on PageRow, so that the direction of movement is correct)
https://invent.kde.org/frameworks/kirigami/-/merge_requests/1785 (Fix back button visibility behavior with certain page row setups)

Broader Discussions 🔗

We were able to discuss some topics together at the sprint with other Plasma developers!

Photo by Kevin Krammer

Haptics stack 🔗

We discussed the stack that we use for vibrations and LEDs (issue). We currently use hfd-service (from Ubuntu Touch) as a backend to interact with the hardware, and QtFeedback on top for the system and applications to interact with them. However, QtFeedback is no longer developed by Qt (though we have forked it within KDE to port it to Qt 6), and gives a very simplistic API for vibrations (on and off with set durations). We also have had the issue that vibrations are not customized per-device, and so events that work fine on one device might feel too heavy on others, or not resonate at all.

We ended up deciding on giving feedbackd (used in Phosh) a try, using it directly in the shell and implementing a feedbackd backend in our fork of QtFeedback (KTactileFeedback) for backward compatibility. This allows us to potentially adopt the event system that feedbackd provides, so that they can be adapted to devices based on how they feel. While feedbackd does has an DBus API for applications, we will eventually want to look at having a generic portal API for applications on having haptics.

I created the following merge requests:

https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/719 (Adopt it in the shell)
https://invent.kde.org/jbbgameich/ktactilefeedback/-/merge_requests/2 (Add a feedbackd backend to QtFeedback/KTactileFeedback)

Notch Support 🔗

Plasma Mobile does not currently have any support for notches or rounded corners. Phosh developers have already proposed a new Wayland specification that will allow the shell and applications alike to receive information about screen cutouts. We discussed it with the KWin developers to get it on their radar, and decided upon pursuing an experimental implementation of it in KWin, and using it in the shell to make any UI adjustments necessary. Qt 6.9 also recently introduced a screen edge “safe areas” API (for Android and iOS), and so we can eventually also implement a backend there to support it on Linux.

Envmanager 🔗

Plasma Mobile has a service called envmanager that manages configurations that are used by both Desktop and Mobile, and swaps configuration as necessary between the sessions. There are many drawbacks to this approach because it affects the user’s Plasma configurations directly, and needs to run before session startup (and so bad stuff can happen if it is uninstalled before logging into the desktop session). We discussed having a more robust approach, and one of the ideas floated was to add a path to XDG_CONFIG_DIRS in the Plasma Mobile startup script, where we can have a “Plasma Mobile” folder that only the shell controls to provide our intended configuration. Our configuration framework (KConfig) supports overlaying config options from various locations, and so we can have the user’s config be overlaid on top of our “Plasma Mobile” config. envmanager can then directly write to this folder without having to affect the user’s configuration, and without affecting the Desktop session.

I created a merge request to implement this:

https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/723

Power management 🔗

Bhushan has been doing a lot of work in this area recently, and did some work on this at the sprint (hopefully his blog post will come soon!). Jakob, who has done a lot of work on overhauling the power management stack in the past year, was also at the sprint. Together, we had a conversation about the future of the power management KCM. Currently, there are separate desktop and mobile KCMs for power, mainly because the desktop one contains far too many options that are not relevant on mobile. The mobile KCM has suffered from some bitrot in the past, and so I had moved the code to be located in the same repository as the desktop one in order to share code. We discussed potentially merging the two KCMs, but decided on continuing with the status quo for now because of the complexity involved in both having good UX, and in how to streamline the desktop settings to have some features apply more directly to mobile. It is a much larger topic that could perhaps be suited for a future GSoC project.

I created a merge request to share more code with the desktop KCM for the time being:

https://invent.kde.org/plasma/powerdevil/-/merge_requests/543 (KCM KConfig XT port)

Thank you 🔗

I am really glad to have been able to finally attend an in-person KDE event, it was really productive! Thank you for having me!

I know I have not really shared many updates about Plasma Mobile in the past few years, mainly due to being busy with school and work. Rest assured, the project is still moving along, I plan to hopefully push through a new blog post on plasma-mobile.org in the coming weeks!

Plasma Mobile: tuned up to 6!

Wed, 13 Dec 2023 20:26:29 +0100

There are some plans to have a more official blog post on the plasma-mobile.org, these are my personal ramblings below…

Plasma 6 is coming together nicely on the desktop!

Coming back from hiatus, I was pleasantly greeted by a much more working session than when I last saw it in May; I have now completely switched over to it on my main machine!

On the other hand, there is still a lot of work to do on mobile to prepare it for the Plasma 6 release in February. I will outline the current situation and the work I have done in the past few months in order to make Plasma 6 a possibility for Plasma Mobile.

Context 🔗

I started working on KDE projects again in October (after an 8 month hiatus), slowly getting back into the groove of things. I unfortunately do not have as much spare time these days after work and school, but I try to do what I can!

The distro situation 🔗

For Plasma Mobile shell development on phones, we need to have distributions with KDE packages built from git master.

Many years ago, we used to have Neon images with Plasma Mobile that were maintained by Bhushan that were used for development, but required a large investment in time to maintain. We no longer have the (human) resources to maintain a distribution, so we are dependent on working with other distributions for development images.

Until this year, Manjaro had helped us by providing daily development images. Unfortunately, I have not really had contact with the project since one of their employees left earlier this year.

As a sidenote: Maintenance of the Manjaro Plasma Mobile images seemed to be inactive in the past few months, though there have been some encouraging signs from the forum in the past few days?

And so, there was a predicament. While I could develop the Plasma 6 mobile shell on the desktop, I had no way of testing it on a phone.

Thankfully, postmarketOS graciously took up the effort of maintaining a repository of KDE packages that track git master. Instructions can be viewed here. With the Plasma 6 beta release, there will be postmarketOS images that can be easily downloaded and tested with!

Seshan has also been working on an immutable distro ProLinux which has images that track git master as well, which have been useful to test with.

Porting 🔗

A big part of the porting effort is simply porting the shell and applications to Qt 6 and KDE Frameworks 6.

In the case of the shell, porting to Qt 6 was luckily fairly trivial. There were far more changes to the base KDE frameworks as package structures and QML plugins were being reworked, though that has stabilized in recent months. There are still some major regressions that need to be resolved before February (will be discussed later), but I am reasonably confident that the shell will in good shape by then.

For applications however, it is more of a mixed bag.

Several applications do not have active maintainers, and others need much more polish for mobile usage (as not all application developers have phones to test with).

Technically, I am responsible for KClock, KWeather and KRecorder, but I have typically done contributions to a multitude of applications to ensure that they work well on mobile. This time around though, I have only been really able to work on the shell with the limited spare time I have, and so I have not been able to do some of the heavier porting work for applications.

KRecorder in particular is unlikely to be ported in time for Plasma 6 as it depends on Qt Multimedia, which has had significant changes in Qt 6.

Beyond porting, I have also noticed some significant mobile-specific regressions in other applications that have been ported, which need to be addressed.

I would encourage anyone who is thinking of contributing to KDE to start here, application development is a very good way to learn Qt and get into further KDE contributions (as it is quite self-contained, compared to, say, the shell).

Styles 🔗

Plasma Mobile currently uses a separate Qt Quick style from the desktop (qqc2-breeze-style vs. qqc2-desktop-style), in which maintenance was lagging for Plasma 6.

The separate style is needed in order to have better performance, as it avoids some of the complex theming that the desktop needs to use for unifying styles between Qt Quick and Qt Widgets applications. However, it is a maintenance burden.

In November, I did a bunch of work on qqc2-breeze-style in order fix Plasma 6 related regressions, and to make it render more similarly to qqc2-desktop-style.

Task Switcher moving to KWin 🔗

In Plasma 5, the task switcher was built into the plasmashell process (which contains the homescreen, panels and most of what you see in Plasma), piping the application thumbnails from KWin.

In order to improve performance, it was a bit of a hack; the task switcher was built into the homescreen, so when it was opened, apps were minimized, showing the task switcher underneath. It was not optimal though, as it required convoluted logic in order to swap between the homescreen and task switcher views, and the thumbnails provided from the stream from KWin were not optimal performance wise.

With Plasma 6, I am moving the task switcher to be a self-contained KWin effect instead, which is inline with how the Desktop overview effect is implemented. This moves the task switcher off of plasmashell to KWin, cleaning up the code and potentially having performance improvements with how the application previews will be displayed.

We can also make use of KWin’s infrastructure for gesture-only mode (removing the navigation bar), rather than relying on a hack with invisible panels in order to trigger it.

The move has been a bit problematic though, as KWin developed regressions during Plasma 6 development that cause effect rendering to be broken on the PinePhone and SDM845 devices (possibly due to OpenGL versions?), but the issues are being worked on. As of Dec. 13, this has been fixed.

Rewriting Folio - the homescreen 🔗

Note: I will be writing a separate blog post that goes much more into detail in the future.

For some context, the default homescreen in Plasma 5 is Halcyon, which provides a simple way have a list of applications, while allowing them to be pinned and grouped into folders.

We also have the Folio homescreen, which was the original default (before Plasma 5.26) that was more similar to a traditional homescreen, having favourites pages and an application drawer to access the full list of apps.

The problem with Folio in Plasma 5 though was that it was particularly unstable (known to brick the shell), and was effectively an extended desktop canvas, so screen rotations and scaling changes would completely ruin the layout.

I knew that it would require a very significant effort in order to rewrite it and fix its issues, so I developed Halcyon as a stopgap solution until I had the time to fix Folio.

And so I spent about 5 weeks starting in October working solely on the Folio rewrite! It will be shipping as the default homescreen once again in Plasma 6.

I am pretty happy with how it turned out, it supports:

An app drawer
KRunner search
Folders
Pages
Drag and drop between all of the above
Applets/widgets
Row-column flipping for screen rotations
Customizable row and column counts
Customizable page transitions
Ability to import and export homescreen layouts as files
… and more!

Applets in particular are pretty exciting, though still need some work. They use the same infrastructure that the Desktop uses, so we can use existing applets!

New applets for mobile apps can eventually also be developed, pending interest.

A new service: `plasma-mobile-envmanager` 🔗

Plasma Mobile relies on some configurations (set in files) for KWin and the shell in general that directly conflict with what Plasma Desktop expects.

For example, we use different look-and-feel packages to provide pieces such as the lockscreen theme, as well as tweaks for features such as disabling window decorations.

In Plasma 5, this was accomplished by having the distribution ship config files that are installed to /etc/xdg (from plasma-phone-settings), which overrode Plasma related settings for users.

This was problematic in that this would affect the desktop session, making it impossible to use both the desktop and mobile sessions without doing some tweaking before switching. This also made it a barrier to be easily installable as “just another desktop environment”, which was a common complaint.

In Plasma 6, I introduced plasma-mobile-envmanager a utility that runs prior to shell startup that automatically does the configuration switching between what is needed for Plasma Mobile, and what is needed for Plasma Desktop.

This now allows distros to drop having to install hardcoded configs onto the system, and makes it easy to simply install as a separate desktop environment for existing systems.

A new application: `plasma-mobile-initial-start` 🔗

I added an application that runs when starting Plasma Mobile for the first time, guiding users on configuration on their system, from setting up the Wi-Fi, to configuring cellular settings.

It currently exists as an application that runs when the shell is started for the first time.

However, it likely needs to eventually be ported to be a true first-start wizard similar to what GNOME has as well as pico-wizard (used by Manjaro), in order to have elevated permissions so that the user does not have to be prompted for their password.

Docked mode 🔗

With Plasma 6, I am making some steps toward improving support with attaching a monitor, keyboard and mouse.

A new “Docked Mode” quick setting was introduced that, when activated:

Bring back window decorations
Stops opening application windows in fullscreen

Eventually, some more work can be done in order to have the external monitors load desktop panels instead of the mobile ones, which should make the experience equivalent to Plasma Desktop.

Telephony 🔗

I have historically not done much work on the telephony front.

There have luckily been contributors that have worked on Spacebar and Plasma Dialer (shoutout to Michael and Alexey!) in the past few years, allowing me to focus on other things.

From recent testing though, there have been a lot of regressions in Plasma 6, so I likely need to start learning the ropes of how it all works in order to help out. Of particular focus for me will be improving the quality of the cellular settings and overall shell integration with ModemManager.

My current carrier only supports VoLTE so I have been unable to test calling, and I have had trouble with my PinePhone in getting cellular working, but I will probably try buying a USB modem to do testing on the desktop with.

Settings module consolidation 🔗

In Plasma 5, a lot of mobile specific settings modules lived outside of the Plasma Mobile repository, in places such as the settings application.

I moved these settings modules together to be in the Plasma Mobile repository. This also removes the need to have a separate build of plasma-nm.

Other things to address 🔗

A big pain point in Plasma 5 was the mobile lockscreen. There were many cases of it crashing (causing the white text on black screen issue) as well as extraordinarily slow load times.

Much of it likely stems from the fact that it has to load the QML files right after the device locks, which can be slow and sometimes has graphical issues when coupled with suspend. I have tried to optimize the load time in the past, but it may be the case that we need to rethink the architecture a bit, not sure…

Conclusion 🔗

I will be returning to a university term in January, likely making it harder for me to contribute for a few months again.

I have luckily finished most of the features I have wanted to get done for Plasma 6, and am now spending my effort fixing bugs and improving code quality. I hope that we can have a successful, bug-free Plasma Mobile release in February, but it is quite daunting at the moment as a single volunteer contributor for the mobile shell.

If you are interested in helping contribute, I encourage you to join the Plasma Mobile matrix room!

There is also some documentation on the wiki that can help you get started.

go konqi!

Akademy 2022

Tue, 11 Oct 2022 11:26:29 +0100

This year, I had the amazing opportunity to attend Akademy in person (@ Barcelona) for the first time!

For context, I first started contributing to Plasma Mobile in 2020, right around when easily testable hardware (ex. PinePhone) was taking shape. I originally started with some contributions to some applications to learn Qt and C++, but have since then taken more responsibility with tasks from all around the software stack.

Talks 🔗

We first had a welcome event on Friday where attendees got to know each other. It was quite cool to finally be able to match usernames to faces, and finally meet the people I had been working with in-person.

I also met up with amazing people from the postmarketOS team! I had the chance to see a Fairphone 4 with the OS running Plasma Mobile smoothly, which was amazing.

Day 1 & 2 🔗

I had a great start… I missed the first two hours of talks on the first day because I slept in.

Luckily, my talk, Plasma Mobile in 2022 with Bhushan was in the afternoon. Unfortunately, Bhushan was unable to come in-person this time around. Hopefully I will be able to meet him next year!

You can see our talk here (at around 5:21:00):

I attended quite a few interesting talks:

Konquering the World: Are We There Yet (Nate Graham) - The state of Plasma shipping with hardware
Full Steam Ahead! (David Edmundson) - Steam Deck with Plasma
Stop Crashing Already! (Harald Sitter) - Integrating Dr. Konqi with powerful tools for developers to find issues
Getting your application ready for KF6 (Nicolas Fella & Alexander Lohnau)
Asahi Linux (Hector Martin) - Information about the Asahi Linux project, how it came about
Push Notifications - Infrastructure (not just) for Plasma Mobile (Volker Krause) - Status of building the framework to have push notifications on Plasma (Mobile!)
Fedora, KDE, Kinoite, and Mobile (Neal Gompa) - Overview of Fedora shipping Plasma

… and there were many other cool shorter talks as well!

There were also people from Pine64 and Manjaro there that I met. It was really cool hearing about Pine64’s future plans for RISC V (coming soon!), as well as seeing some of the devices that Manjaro had running Plasma Mobile on (portable game console, mini tablet/netbook?).

Meetings/BoFs 🔗

After the weekend of talks, we had several days where rooms at the university we were at were available for BoFs.

BoFs, or “Birds of Feather” meetings are ways to gather people with similar interests in the same room, and discuss specific topics and plans.

There were quite a few BoF sessions, of which I attended a few:

Plasma Mobile BoF 🔗

This was my first time attending a BoF, as well as hosting one. We unfortunately had some trouble with audio, which made it hard to communicate with online attendees.

However, we did discuss the following topics:

Helping Bhushan do Plasma Mobile Gear releases since he does them himself at the moment
Moving some Plasma Mobile applications to KDE Gear due to limited changes
How to proceed with QtFeedback (vibrations stack) for Qt 6 as it is unmaintained
Possibility of switching to feedbackd (by Purism) from hfd-service instead
Plan is one last release of Plasma Mobile with KF 5 (5.27), before branches are made for Plasma 6
No large changes anticipated for Plasma Mobile 6
SHIFTphones and Fairphone can run pmOS with Plasma Mobile, perhaps we can open communication channels with them?
Manjaro was working with 2 tablet (?) vendors, they have positive reception and had a few suggestions

KDE PIM BoF 🔗

KDE PIM (Personal Information Management) refers to the KDE stack for applications like KMail, KOrganizer, Kalendar, etc.

Improving Akonadi for mobile devices was discussed, including the possibility to try using SQLite by default, which may improve resource consumption.

I had started working on a mail application called Raven for Plasma Mobile recently, and so it was also discussed how to better share code between it and other applications that use the Akonadi stack.

Plasma Ink BoF 🔗

I attended a BoF about an upcoming project, Plasma Ink, which brings Plasma to e-ink devices. They can be useful for reading, taking notes, as well as simply being an enjoyable interface to write content.

This platform however needs special consideration for the way content is rendered, since e-ink devices typically have slow-refresh screens, and so animations as well as colours need to be adjusted to be as light as possible.

Pine64 has been developing the PineNote which can run Plasma Ink theoretically, I had the chance to try one and was quite impressed at the responsiveness for pen notetaking.

While I likely will not be very involved with the project since I am preoccupied with Plasma Mobile, I hope it continues forward!

Debugging session with Aleix 🔗

We have had a severe regression for several months now with the lockscreen, which crashes frequently when waking from suspend: https://invent.kde.org/teams/plasma-mobile/issues/-/issues/156

I sat down with Aleix to really focus on trying to fix this issue, since he knows about KWin for more than me, though his PinePhone had not been working and so he couldn’t replicate it previously.

After hours of jumping around git commits of kscreenlocker (compiling it on device is painful), we realized that the issue was elsewhere in the stack. There is some sort of Wayland registry failure that occurs when kscreenlocker is started immediately after waking from suspend, which causes it to crash. We unfortunately did not have enough time to pinpoint the issue, but we do have some ways to move forward with investigating in the future. We suspect it may be related to when KWaylandServer was merged into KWin.

Convergent Forms BoF 🔗

The last BoF I attended was about convergent forms, and how we can design forms that use a single codebase, but have designs that work for both mobile and desktop.

Currently, we have special components in kirigami-addons for mobile, but are not necessarily great on desktop.

What was decided was to create a new “FormLayout” component in Kirigami, which can take a set of instructions to build the form, and generates the necessary components to display properly on whichever platform it is running on.

Closing 🔗

Overall, I had an amazing time at Akademy this year, and hope to attend more in the future!

Going to Akademy!

Wed, 27 Jul 2022 20:23:29 -0400

I am going to be attending Akademy 2022 in person!

This is my first time going to Akademy in-person, so it is quite exciting! I will be doing a talk with Bhushan on the state of Plasma Mobile.

A bit of background on my experience at KDE:

I first started contributing to KDE in 2020, creating the KClock project as a way to learn Qt Quick, and to pick up one of the pending tasks of Plasma Mobile.

Through 2020, I worked on many Plasma Mobile applications such as KWeather, and also started poking around contributing to the shell. I also did some work for the desktop, including some work on adding fingerprint support to the users kcm.

In 2021 and 2022, I got much more heavily involved in KDE frameworks (namely Kirigami) and Plasma Mobile shell contributions.

One of the most exciting developments in the project over the past few years has been the expansion in the number of devices that can now run Plasma Mobile. I will be sure to bring some devices I have for demo purposes :3

Overall, I am very excited to be able to share a lot of the work that has been done when I attend this year’s Akademy! Be sure to check out my talk!

someone here is me…

kde on espidev

Akademy 2025

Talks 🔗

KDE Linux: Banana Growth Cycle 🔗

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

KDE Goals - One Year Recap 🔗

Next-Gen Documentation Infrastructure for KDE 🔗

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

Plasma Mobile Power Management: Reliable Sleep and Wake Ups 🔗

Discussions 🔗

Diving into Plasma Bigscreen

Background 🔗

Stepping in 🔗

Housekeeping 🔗

UI 🔗

Homescreen 🔗

Settings 🔗

Startup feedback 🔗

Envmanager 🔗

Trying it out 🔗

Applications 🔗

Controller support 🔗

Other contributors 🔗

Unresolved issues 🔗

Input 🔗

Application design 🔗

Goals 🔗

Getting it released again 🔗

Overall 🔗

A libcamera port of Plasma Camera

Background 🔗

Porting Plasma Camera 🔗

UI work 🔗

Results 🔗

Limitations 🔗

Video recording issues on phones 🔗

Rotation issues 🔗

Missing camera controls 🔗

Conclusion 🔗

A Plasma (Mobile) Sprint in Graz

Lockscreen overlays and more 🔗

Kirigami 🔗

Broader Discussions 🔗

Haptics stack 🔗

Notch Support 🔗

Envmanager 🔗

Power management 🔗

Thank you 🔗

Plasma Mobile: tuned up to 6!

Context 🔗

The distro situation 🔗

Porting 🔗

Styles 🔗

Task Switcher moving to KWin 🔗

Rewriting Folio - the homescreen 🔗

A new service: plasma-mobile-envmanager 🔗

A new application: plasma-mobile-initial-start 🔗

Docked mode 🔗

Telephony 🔗

Settings module consolidation 🔗

Other things to address 🔗

Conclusion 🔗

Akademy 2022

Talks 🔗

Day 1 & 2 🔗

Meetings/BoFs 🔗

Plasma Mobile BoF 🔗

KDE PIM BoF 🔗

Plasma Ink BoF 🔗

Debugging session with Aleix 🔗

Convergent Forms BoF 🔗

Closing 🔗

Going to Akademy!

A new service: `plasma-mobile-envmanager` 🔗

A new application: `plasma-mobile-initial-start` 🔗