Skip to content

Commit 7856931

Browse files
friesoftfriesoft
committed
kde blogs
1 parent e5de094 commit 7856931

31 files changed

Lines changed: 781 additions & 24 deletions

‎content/projects/kde/_index.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,4 @@
11
---
22
title: KDE
3+
type: "kde"
34
---

‎content/projects/kde/cpu-architecture-libksysguard.md‎

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
---
2+
title: "CPU Architecture Detection in libksysguard"
3+
date: 2026-04-05
4+
image: "/images/projects/kde/cpu-architecture.png"
5+
type: "kde"
6+
status: "Pending Review"
7+
tags: ["KDE", "Plasma", "libksysguard"]
8+
merge_requests:
9+
- url: "https://invent.kde.org/plasma/libksysguard/-/merge_requests/467"
10+
status: "Pending Review"
11+
---
12+
13+
I've added support for displaying the CPU architecture of processes (32-bit/64-bit for x86/ARM/RISC-V) in `libksysguard`. This information is now available to plasma-systemmonitor. In addition it also detects when running x86/x86-64 binaries on arm64/aarch64 and displays it as "Emulated".
14+
15+
![CPU Architecture](/images/projects/kde/cpu-architecture.png)
16+
17+
*CPU architecture of processes (where current user can read) is shown in plasma-systemmonitor*

‎content/projects/kde/dbus-path-sanitization.md‎

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
---
2+
title: "Fix D-Bus Path Sanitization"
3+
date: 2026-04-16
4+
image: "/images/projects/kde/dbus-path-sanitization.png"
5+
type: "kde"
6+
status: "Released"
7+
tags: ["KDE", "Plasma", "D-Bus"]
8+
merge_requests:
9+
- url: "https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3667"
10+
status: "Merged"
11+
release: "Plasma 6.6.5"
12+
---
13+
14+
After adding actions to plasma-systemmonitor I noticed I couldn't run those actions from krunner.
15+
16+
This ensures that applications with dashes in their names (like `plasma-systemmonitor`) can be run via D-Bus (like krunner does). This uses the same logic as already present in kglobalacceld.
17+
18+
![D-Bus Path Sanitization](/images/projects/kde/dbus-path-sanitization.png)
19+
20+
*Actions from plasma-systemmonitor shown in krunner and working after this fix*

‎content/projects/kde/gif-filesize.md‎

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
---
2+
title: "Optimized GIF filesize"
3+
date: 2026-04-14
4+
image: "/images/projects/kde/gif-filesize.png"
5+
type: "kde"
6+
status: "Released"
7+
tags: ["KDE", "Spectacle", "KPipeWire"]
8+
merge_requests:
9+
- url: "https://invent.kde.org/plasma/kpipewire/-/merge_requests/247"
10+
status: "Merged"
11+
release: "Plasma 6.7.0"
12+
---
13+
14+
As I'm mostly using GIFs as attachments for Jira tasks, and their file size with Spectacle was previously abysmally (read: unusable) large, I was looking into how to improve this.
15+
16+
By enabling diff mode, setting a static color palette and bayer dither the filesize has been reduced drastically.
17+
18+
For a typical 10-second 1080p screen recording where content doesn't change that much, the file size now shrinks from about 33 MB to about 500 KB—with quality that is, in my opinion, more than good enough.
19+
20+
![GIF filesize](/images/projects/kde/gif-filesize.png)
21+
22+
*GIF filesize comparison*

‎content/projects/kde/gpu-naming-systemmonitor.md‎

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
---
2+
title: "GPU naming in System Monitor"
3+
date: 2026-03-20
4+
image: "/images/projects/kde/gpu-naming-1.png"
5+
type: "kde"
6+
status: "Released"
7+
tags: ["KDE", "Plasma", "libksysguard", "ksystemstats"]
8+
merge_requests:
9+
- url: "https://invent.kde.org/plasma/libksysguard/-/merge_requests/464"
10+
status: "Merged"
11+
release: "Plasma 6.7.0"
12+
- url: "https://invent.kde.org/plasma/ksystemstats/-/merge_requests/129"
13+
status: "Merged"
14+
release: "Plasma 6.7.0"
15+
---
16+
17+
On my new computer, the internal and dedicated GPU are most of the time powerful enough that it's hard to distinguish which one is in use (e.g., Minecraft runs on the internal GPU perfectly fine until enabling shaders).
18+
19+
In addition, the GPU numbers seem to sometimes change, so just setting `DRI_PRIME=1` didn't work; I had to use the PCI ID.
20+
To make things worse, `plasma-systemmonitor` only showed generic labels like "gpu 2" or "gpu 3," which wasn't helpful at all for determining which GPU was being utilized.
21+
22+
To circumvent these problems, I added proper GPU naming to `libksysguard` for the application/process view in `plasma-systemmonitor` and `ksystemstats` for sensor readings.
23+
24+
I moved the GPU naming logic into `libksysguard` and reused it in `ksystemstats` to ensure consistency across the system.
25+
26+
![gpu-naming-1](/images/projects/kde/gpu-naming-1.png)
27+
28+
![gpu-naming-2](/images/projects/kde/gpu-naming-2.png)
29+
30+
![gpu-naming-3](/images/projects/kde/gpu-naming-3.png)
31+
32+
![gpu-naming-4](/images/projects/kde/gpu-naming-4.png)

‎content/projects/kde/gpu-usage-fixes.md‎

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
---
2+
title: "GPU Usage and Memory Fixes"
3+
date: 2026-03-23
4+
image: "/images/projects/kde/gpu-usage-fixes-1.png"
5+
type: "kde"
6+
status: "Released"
7+
tags: ["KDE", "Plasma", "libksysguard"]
8+
merge_requests:
9+
- url: "https://invent.kde.org/plasma/libksysguard/-/merge_requests/465"
10+
status: "Merged"
11+
release: "Plasma 6.6.4"
12+
---
13+
14+
On my system (with Intel and NVIDIA GPUs), the GPU usage and memory graphs shown in `plasma-systemmonitor` were completely broken.
15+
16+
![GPU Usage Fixes Before](/images/projects/kde/gpu-usage-fixes-1.png)
17+
18+
With this change, graphs now display useful values 😄.
19+
20+
![GPU Usage Fixes After](/images/projects/kde/gpu-usage-fixes-2.png)
21+
22+
I compared the VRAM values of processes with `nvidia-smi` and `intel_gpu_top`, and they look plausible now. In addition, I optimized the implementation by removing a wasteful `nvidia-smi` call that occurred in a loop for every line read.

‎content/projects/kde/kwin-keyboard-input.md‎

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
---
2+
title: "KWin Plugin: Keyboard Input Display"
3+
date: 2026-04-01
4+
type: "kde"
5+
status: "Idea"
6+
tags: ["KDE", "KWin", "Wayland"]
7+
---
8+
9+
I'm thinking about developing a new KWin plugin that provides a visual overlay displaying each key stroke. This is particularly useful for screen recording and presentations where you want the audience to see which keys are being pressed in real-time.
10+
11+
The plugin should leverage KWin's internal event filtering to capture key presses without interfering with application focus. It should support customizable positioning and styling through QML.

‎content/projects/kde/my-first-kde-update.md‎

Lines changed: 0 additions & 8 deletions
This file was deleted.

‎content/projects/kde/pin-unlock-screenlocker.md‎

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
---
2+
title: "PIN Unlock with autosubmit for Plasma Screenlocker"
3+
date: 2026-03-29
4+
type: "kde"
5+
status: "Idea"
6+
tags: ["KDE", "Plasma", "Security", "TPM2", "Screenlocker"]
7+
merge_requests:
8+
- url: "https://invent.kde.org/friedreich/plasma-desktop/-/compare/master...work%2Fpinpam?from_project_id=2802"
9+
status: "Work in Progress"
10+
- url: "https://invent.kde.org/friedreich/kscreenlocker/-/compare/master...work%2Fpinpam?from_project_id=2683"
11+
status: "Work in Progress"
12+
- url: "https://invent.kde.org/friedreich/plasma-workspace/-/compare/master...work%2Fpinpam?from_project_id=2703"
13+
status: "Work in Progress"
14+
---
15+
16+
I'm trying to bring native PIN unlock with auto-submit support to the Plasma Screenlocker, mimicking the experience found on Windows.
17+
18+
### The Objective
19+
20+
The goal is to allow users to set a numeric PIN in the "Users" KCM, which can then be used to quickly unlock the desktop using a short PIN but still keeping your strong password as a fallback.
21+
22+
This includes:
23+
1. **Auto-submit**: The lockscreen automatically attempts to unlock once the entered PIN length matches the configured length.
24+
2. **Numeric Keypad**: A dedicated keypad UI on the lockscreen for touch and mouse friendliness.
25+
3. **TPM 2.0 Integration**: If TPM 2.0 is available PINs can be saved using the `pinpam` PAM module that interacts with the TPM.
26+
27+
### Technical Implementation
28+
29+
The feature consists of multiple components:
30+
* **Users KCM (`plasma-workspace`)**: A new section to set/change/remove the PIN.
31+
* **Screenlocker (`kscreenlocker`)**: New configuration entries for `PinEnabled` and `PinLength`.
32+
* **Lockscreen UI (`plasma-desktop`)**: Porting the Plasma Mobile numeric keypad to the desktop Breeze theme and adding the auto-submit logic.
33+
34+
### Backend with pinpam (hardware based)
35+
36+
The backend uses [pinpam](https://github.com/RazeLighter777/pinpam), a PAM module written in Rust that leverages TPM 2.0 for secret storage and lockout management. Since no official Fedora packages are available, I've created a [COPR repository](https://copr.fedorainfracloud.org/coprs/friesoft/pinpam/) for it.
37+
38+
### Backend using pam_pinlock (software based)
39+
40+
For systems without a TPM, I'm looking at [pam_pinlock](https://github.com/saltnpepper97/pam_pinlock). I've also made a [COPR repository](https://copr.fedorainfracloud.org/coprs/friesoft/pam_pinlock/) available for Fedora users.
41+
42+
### Security & Development Status
43+
44+
> [!WARNING]
45+
> Both of these PAM modules are currently in the early stages of development and may not yet meet the security standards required. There is a strong possibility that we will need to invest more into developing a dedicated, robust PAM module.

‎content/projects/kde/spectacle-video-presets.md‎

Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
---
2+
title: "Video recording presets for Spectacle"
3+
date: 2026-04-08
4+
type: "kde"
5+
status: "Idea"
6+
tags: ["KDE", "Spectacle", "KPipeWire", "FFmpeg"]
7+
merge_requests:
8+
- url: "https://invent.kde.org/friedreich/kpipewire/-/compare/master...work%2Fencoding-preferences?from_project_id=1911"
9+
status: "Work in Progress"
10+
- url: "https://invent.kde.org/friedreich/spectacle/-/compare/master...work%2Fencoding-preferences?from_project_id=2004"
11+
status: "Work in Progress"
12+
---
13+
14+
I want the ability to configure the encoding preferences for video recordings in Spectacle. This is useful for users who want to optimize for file size, quality, or speed. I also want to be able to benchmark the different encoding preferences to actually see the difference in file size and quality.
15+
16+
### Spectacle Settings UI
17+
18+
Users can now explicitly set a **Max frame rate** (defaulting to 30 fps) and choose an **Encoding preference** (Balanced, Highest Quality, Fast, or Smallest Size).
19+
20+
### KPipeWire Backend
21+
22+
I refactored the backend to ensure that these preferences are actually respected by all encoders
23+
24+
### Benchmarks
25+
26+
To allow benchmarking I added cli options to Spectacle for running headless recordings with varying encoders, frame rates and presets.
27+
28+
The results of my testing across 48 combinations show the impact of these presets (10-second recordings):
29+
30+
| Format | Preset | 10 FPS | 60 FPS | 120 FPS |
31+
|---|---|---|---|---|
32+
| **vp9** | balanced | 125.9 KiB | 460.4 KiB | 473.3 KiB |
33+
| **vp9** | quality | 169.8 KiB | 491.9 KiB | 495.7 KiB |
34+
| **vp9** | speed | 195.2 KiB | 568.5 KiB | 573.3 KiB |
35+
| **vp9** | size | 159.8 KiB | 312.8 KiB | 444.9 KiB |
36+
| **h264** | balanced | 110.7 KiB | 408.1 KiB | 415.6 KiB |
37+
| **h264** | quality | 118.7 KiB | 433.1 KiB | 438.5 KiB |
38+
| **h264** | speed | 119.8 KiB | 446.2 KiB | 437.7 KiB |
39+
| **h264** | size | 210.7 KiB | 460.9 KiB | 468.6 KiB |
40+
| **webp** | balanced | 8.69 MiB | 29.37 MiB | 29.86 MiB |
41+
| **webp** | quality | 8.35 MiB | 30.19 MiB | 31.32 MiB |
42+
| **webp** | speed | 15.94 MiB | 42.60 MiB | 41.22 MiB |
43+
| **webp** | size | 8.40 MiB | 31.67 MiB | 32.90 MiB |
44+
| **gif** | balanced | 425.6 KiB | 635.7 KiB | 616.3 KiB |
45+
| **gif** | quality | 14.44 MiB | 48.22 MiB | 51.51 MiB |
46+
| **gif** | speed | 356.1 KiB | 499.5 KiB | 433.4 KiB |
47+
| **gif** | size | 392.8 KiB | 537.2 KiB | 496.3 KiB |

0 commit comments

Comments
 (0)