Linux on Florian RICHER

My first participation in a KDE PIM Sprint

Mon, 15 Dec 2025 00:00:00 +0000

My First Participation in a KDE Sprint

During Akademy 2025 in Berlin, I signed up for the KDE PIM Sprint. While I had never worked on PIM before, I had contributed to Plasma Mobile, Koko (for OCR implementation, still a work in progress), and Solid (for LED implementation). This was also my first time participating in a KDE Sprint.

I arrived by train from Limoges to Paris at 10:30 PM on Friday. Unfortunately, I couldn’t arrive earlier due to professional commitments, and I had to leave again on Sunday at 5:30 PM.

Starting the Sprint

On Saturday morning, I joined everyone for breakfast. Afterward, we had meetings throughout the morning and part of the afternoon. In parallel, I compiled Merkuro and KMail on my laptop. Normally, I work on my desktop computer, so I needed to compile all the KDE packages on my laptop, which isn’t very powerful. Luckily, I had started the compilation process on the train.

Once the meetings were over, I began working on PIM projects. My first task was to read the codebase to understand the various packages related to Merkuro.

Understanding Merkuro

Merkuro relies on components from Akonadi, KMailTransport, KDE PIM Runtime, and KIdentityManagement.

However, I encountered an issue with distrobox: when Carl and I tried to configure an IMAP account in Merkuro Mail, the password was never saved. After some investigation, I discovered that this was related to KWallet and KSecrets. Since distrobox doesn’t use the Plasma Desktop environment by default, many “basic” KDE services aren’t running in the background.

To fix this, I had to run the following commands:

1
2
3
4


source ~/kde/build/kwallet/prefix.sh
ksecretd &
kwalletd6 &
wait

After that, I successfully configured my first IMAP account in KMail and Merkuro, and I was able to retrieve all my emails from Proton Mail.

Note: The IMAP accounts in KMail and Merkuro are synchronized because both use KIdentityManagement and KMailTransport.

Contributions

I also opened a small merge request based on Carl’s recommendation regarding the unnecessary use of Layout.fillWidth: true (MR #595).

Next, I tried to add a new identity in Merkuro, but it wasn’t saved. This time, the issue wasn’t related to KWallet. Instead, it was because when the identity was passed as a property to the component, it was copied. So, when I modified the identity, it only modified the copy, not the “main” identity reference itself. This happened because Identity is a QGadget type, not a QObject see the definition here.

To fix this, I changed the property type to the backend type. I could then access the current identity using backend.identity. I updated all occurrences in the code and opened the following merge requests:

MR #38 to fix the Cryptography component.
MR #40 to fix the remaining identity information.

Finally, I started investigating why I didn’t receive any errors when trying to add an IMAP account related to KSecrets. It seems to be managed here.

I left the Sprint having started work on the “Add an Identity” feature, which you can follow here.

Conclusion

I really enjoyed participating in the KDE Sprint. It was wonderful to catch up with Carl again. I’m truly grateful for the time he took to help me get up to speed with the project. The discussions with Laurent were also incredibly engaging, and even my brief conversation with Ingo was meaningful, though I still struggle a bit with spoken communication.

Once I’m less busy personally, I plan to:

Migrating the Waydroid implementation to Plasma Workspace, as discussed with Carl.
Continuing my contributions to PIM.
Helping out with KAIChat.

Looking forward to the next opportunity to collaborate with the KDE community!

Useful links

Official KDE PIM Sprint 2025 Blog post

Gitlab projects:

Configurer kde-builder sur des bases immuables et lancer un projet KDE

Sun, 06 Oct 2024 00:00:00 +0000

Introduction

Les systèmes d’exploitation à base immuable, tels que NixOS ou Fedora Atomic, offrent de nombreux avantages en termes de stabilité et de sécurité. Cependant, ils présentent également des défis uniques pour les développeurs, notamment lorsqu’il s’agit de configurer des environnements de développement comme kde-builder. Dans ce post, nous explorerons comment surmonter ces obstacles en utilisant des outils comme distrobox ou toolbox, permettant ainsi aux développeurs de profiter des avantages des systèmes immuables tout en conservant la flexibilité nécessaire pour travailler efficacement avec kde-builder.

Préparer son environnement

Introduction

La préparation de l’environnement de développement est essentielle pour utiliser kde-builder sur des systèmes immuables. Les outils et étapes varient selon la distribution : Fedora Atomic intègre toolbox, facilitant le processus, tandis que NixOS nécessite la configuration manuelle de distrobox. Je vais donc dans un premier temps expliquer comment installer distrobox sur NixOS. Ensuite, je finirais par la configuration générale pour Fedora Atomic et aussi pour Nix OS.

Installation de distrobox sur Nix OS

Pour installer distrobox, il suffit de rajouter dans sa configuration configuration.nix ou dans son flake la configuration suivante:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


# Active docker
virtualisation.docker = {
 enable = true;
};

# Rajoute l'utilisateur au group docker pour éviter d'utiliser la commande sudo tout le temps.
# Par contre, ça rajoute un risque d'élévation de privilège sur le système
# Voir le warning ici https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user
users.users.<user>.extraGroups = [ "docker" ];

# On peut aussi l'ajouter en rootless
virtualisation.docker.rootless = {
 enable = true;
 # L'option setSocketVariable définit la variable DOCKER_HOST pour l'instance Docker rootless pour les utilisateurs normaux par défaut.
 setSocketVariable = true;
};

# Si vous souhaitez utiliser podman à la place
virtualisation.containers.enable = true;
virtualisation = {
 podman = {
 enable = true;

 # Ajoute l'alias `docker` pour une utilisation plus transparente avec les outils compatibles docker seulement
 dockerCompat = true;

 # Nécessaire pour que les conteneurs sous podman-compose puissent communiquer entre eux.
 defaultNetwork.settings.dns_enabled = true;
 };
};

# On rajoute distrobox
environment.systemPackages = with pkgs; [ distrobox ];

Une fois la configuration ajouté, il suffit de taper la commande:

Sans flake

1

nixos-rebuild switch

Avec flake

1

nixos-rebuild switch --flake [path du flake]#[nom de la configuraiton]

Normalement, vous devriez avoir la commande distrobox de disponible. Si c’est le cas, vous pouvez allez à cette étape

Création du container pour travailler

NixOS Distrobox

Pour créer le container avec distrobox, on peut passer par ce fichier distrobox.ini

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


; Nom de notre environnement
[kdedev]
image=quay.io/fedora/fedora:latest
; Change le home directory si vous souhaitez isoler votre environnement de travail de votre home directory host
home="${HOME}/.distrobox_home/kdedev"
; Uniquement si vous possedez une carte NVIDIA. Distrobox va intégrer des patchs pour mieux gérer les intégrations avec NVIDIA.
nvidia=true
; Si vous souhaitez faire une image rootless
root=false
; Pull l'image durant la création de l'environnement
pull=true

Ensuite, il suffit de taper la commande pour créer notre environnement nommé kdedev

1

distrobox assemble create

Une fois l’environnement créer, il reste une dernière étape à faire. Je recommande de rajouter ceci dans votre ~/.bashrc ou dans le bashrc situé dans le container configuré avec home:

1

alias new_shell="env -u PATH -u QML2_IMPORT_PATH -u QT_PLUGIN_PATH -u NIXPKGS_QT6_QML_IMPORT_PATH -u XDG_CONFIG_DIRS bash -l"

Vous pouvez l’éditer plus facilement en allant dans votre environnement de travail avec:

1

distrobox enter kdedev

Cet alias peut-être utile pour retirer les variables d’environnements que rajoute NixOS. Sur Fedora Atomic, ça ne pose pas de problème, car ils respectent la FHS donc les librairies pointent au même endroit que dans le container. Sauf que Nix OS ne respecte pas la FHS (pour de bonnes raisons), donc on peut avoir des conflits lors de la compilation ou de l’exécution de programme que l’on aura compilé avec kde-builder.

La FHS est une structure de fichier normalisé dans le monde Linux plus d’info ici

Pour l’utiliser, une fois dans votre environnement de travail, il suffit de faire:

1
2


distrobox enter kdedev # Pour rentrer dans votre environnement de travail
new_shell

Fedora Toolbox

Pour la configuration avec Fedora Toolbox, c’est assez simple, car Fedora intègre tout par défaut. Il suffit de taper la commande:

1

toolbox create -r [numéro de release fedora] [nom de l'environnement]

Dans notre cas, ça sera:

1

toolbox create -r 40 kdedev

Note: À l’heure ou j’écris le post, j’ai encore des soucis pour lancer kwin avec Fedora Toolbox. J’ai des problèmes de permission sur les DRM. Je pense que c’est lié à selinux.

J’obtiens l’erreur ci-dessous lors du lancement de kwin_wayland

1

KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied

DRM : C’est Direct Rendering Manager et non Digital Rights Management pour plus d’infos

Test de notre environnement

Avant de lancer notre test, il faut installer kde-builder. Vous pouvez voir mon post précédent ici ou vous pouvez suivre ce lien qui est le même que dans le post.

Rappel Il faut l’installer dans votre environnement créé juste avant.

1

distrobox enter kdedev

NixOS Distrobox

1

toolbox enter kdedev

Fedora Toolbox

Une fois votre environnement configurer, normalement vous pouvez tester de compiler solid avec la commande :

1

kde-builder solid

Puis de lancer solid avec la commande:

1

source "$HOME/kde/build/solid/prefix.sh" && solid-hardware6 list

Voilà 🙂 Normalement vous êtes prêt à travailler sur KDE avec un système immuable.

Note pour le démarrage de KDE Plasma Mobile

Pour plasma-mobile, il est nécessaire de configurer d’autres variables d’environnements. Voici le script que j’utilise :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


source "$HOME/kde/build/plasma-mobile/prefix.sh"

QT_QPA_PLATFORM=offscreen plasma-mobile-envmanager --apply-settings

# Environment variables
export QT_WAYLAND_DISABLE_WINDOWDECORATION=1
export QT_QUICK_CONTROLS_MOBILE=1
export PLASMA_PLATFORM=phone:handheld
export QT_QUICK_CONTROLS_STYLE=org.kde.breeze

QT_QPA_PLATFORM=wayland dbus-run-session kwin_wayland --xwayland "plasmashell -p org.kde.plasma.mobileshell" --width 360 --height 720

Source

Vous pouvez aussi lancer le menu du haut sans lancer tout kwin avec le script :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


source "$HOME/kde/build/plasma-mobile/prefix.sh"

QT_QPA_PLATFORM=offscreen plasma-mobile-envmanager --apply-settings

# Environment variables
export QT_WAYLAND_DISABLE_WINDOWDECORATION=1
export QT_QUICK_CONTROLS_MOBILE=1
export PLASMA_PLATFORM=phone:handheld
export QT_QUICK_CONTROLS_STYLE=org.kde.breeze

qmlscene-qt6 "$HOME/kde/src/plasma-mobile/tests/ActionDrawerTest.qml"

Compiler un paquet Postmarket OS

Sun, 18 Feb 2024 00:00:00 +0000

À propos de Postmarket OS

Postmarket OS est une distribution basée sur Alpine conçut pour fonctionner sur téléphone, tablette ou sur Raspberry PI. La communauté autour du projet propose un ensemble d’outils comme pmbootstrap qui permet de configurer et d’installer Postmarket OS sur son téléphone. On peut aussi l’utiliser pour compiler son propre paquet et l’installer sur son téléphone facilement.

Configuration de notre environnement de travail

Avant de pouvoir l’utiliser, il faut d’abord l’installer depuis ce lien.

Une fois installé et configuré, il faut d’abord préparer son environnement de travail. Il est parfois nécessaire de mettre à jour le repository pmaports en local. On peut le faire assez facilement avec la commande :

1

pmbootstrap pull

Met à jour le repository pmaports.git cloné en local.

Le repo pmaports.git stocke tous les paquets Alpine avec le fichier APKBUILD utilisé par le serveur de compilation.

Le fonctionnement est similaire à PKGBUILD pour les utilisateurs de Archlinux

Ce fichier contient toute la procédure pour préparer les sources, compiler le paquet depuis les sources, le numéro de version ainsi que la procédure pour vérifier si le paquet fonctionne correctement. Généralement on utilise les tests du projet comme les tests unitaires ou les tests fonctionnels.

On peut également mettre à jour le cache de la commande apk même si c’est pas forcément obligatoire.

1

pmbootstrap update

Met à jour le cache de la commande APK depuis l’environnement de travail

L’environnement de travail se situe par défaut dans le dossier $HOME/.local/var/pmbootstrap/

Si on a déjà un environnement de travail en cours et qu’il contient du cache ou un travail en cours, on peut le réinitialiser assez facilement avec la commande :

1

pmbootstrap zap

Supprime le dossier de la commande chroot pour repartir de 0

La commande chroot permet de changer la racine Linux. Par exemple, on peut faire chroot $HOME/mon_dossier et à partir de ce moment-là, / pointera vers $HOME/mon_dossier dans notre shell actuel.

C’est très utilisé par pmbootstrap pour configurer le système Alpine.

Pour ceux qui veulent utiliser une autre branche, on peut également changer la branche disponible sur le repository.

1

git -C $workdir checkout [branch]

$workdir par défaut se situe dans le dossier $HOME/.local/var/pmbootstrap/cache_git/pmaports/

Exemple de branche utile : kde-nightly

Compilation de notre paquet Alpine

Maintenant, on va pouvoir compiler n’importe quel paquet avec la commande.

1

pmbootstrap build [nom_du_paquet]

Par exemple, on peut compiler plasma-mobile (Attention le paquet est long à compiler)

1

pmbootstrap build plasma-mobile

Par défaut, pmbootstrap va recompiler l’intégralité des dépendances du projet pour s’assurer que notre test sera reproductible. Cependant, lorsque l’on souhaite juste tester un truc, ça peut-être ultra long.

On peut donc utiliser deux options pour nous aider:

-i Permet de dire de compiler uniquement les dépendances du paquet défini dans le fichier APKBUILD
-n Permet d’éviter de compiler les dépendances du paquet défini dans le fichier APKBUILD

Avec le combot des deux options, ça nous évite de tout recompiler.

On a aussi l’option -mp qui peut-être pratique pour changer de mirroir si le téléchargement est lent ou si l’on souhaite télécharger des paquets nightly.

Un mirroir est un serveur utilisé pour télécharger les dépendances

On utilise cette option de cette manière:

1
2
3


pmbootstrap \
 -mp https://nightly.postmarketos.org/plasma-mobile/packages/ \
 -mp http://mirror.postmarketos.org/postmarketos/

On a aussi d’autres options comme:

--details-to-stdout : Affiche le fichier de log dans la console
-j N : Défini le nombre de core CPU utilisé pour la compilation
-t [En seconde] : Le nombre de secondes sans nouveau log dans le fichier avant d’abandonner la compilation
--src : Change les sources du paquet. Par défaut ce sont les sources définies dans le fichier APKBUILD
--arch [arch] : L’architecture CPU du téléphone

Un exemple concret d’une commande que j’ai utilisé pour recompiler ma version de plasma-mobile avec mes changements.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


pmbootstrap \
 -mp https://nightly.postmarketos.org/plasma-mobile/packages/ \
 -mp http://mirror.postmarketos.org/postmarketos/ \
 --details-to-stdout \
 -j 32 \ # Pour utiliser toute la puissance de mon CPU
 -t 3600 -v \ # La compilation est ultra longue donc pmbootstrap abandonne la build avant la fin de la compilation
 build plasma-mobile \
 --src $home/plasma-mobile/ \
 --arch aarch64 \ # Mon téléphone utilise l'architecture aarch64 (ARM64)
 -i \
 -n

Attention

Avant de compiler depuis le repository Nightly, il faut d’abord rajouter la clef de signature
1
2
wget https://nightly.postmarketos.org/plasma-mobile/pmos@local-662fcd2f.rsa.pub
mv pmos@local-662fcd2f.rsa.pub $(pmbootstrap config work)/config_apk_keys/
Source : https://wiki.postmarketos.org/wiki/Nightly

Si vous souhaitez avoir plus d’informations, il suffit de taper la commande

1

pmbootstrap build --help

Et pour avoir les arguments généraux

1

pmbootstrap --help

Envoie du paquet compilé sur le téléphone

Une fois le paquet compilé, il suffit de demander à pmbootstrap de l’envoyer sur notre téléphone via la connexion SSH. Avec pmbootstrap, on utilise la commande sideload comme dans l’exemple ci-dessous.

1
2
3
4
5
6


pmbootstrap sideload plasma-mobile \
 --host [SSH HOST] \
 --port [SSH PORT] \
 --user [SSH USER] \
 --arch [ARCH] \
 --install-key

On a les arguments suivants :

--host [SSH HOST] (Ex: 192.168.1.1)
--port [SSH PORT] (Ex: 22)
--user [SSH USER] (Ex: 192.168.1.1)
--arch [ARCH] : Permet de modifier la valeur définie pour le téléphone (Ex : aarch64)
--install-key : Permet d’installer la clef utilisée pour la vérification des paquets de la machine actuelle.

Tout gestionnaire de paquet comme APK, vérifie si le paquet est valide par rapport à la signature électronique du mainteneur du paquet. Dans notre cas, la signature ne sera pas valide, car le paquet n’est pas compilé par le mainteneur original donc il suffit de rajouter notre signature.

Pour revenir en arrière, il suffit de taper la commande ci-dessous depuis le téléphone ou depuis la connexion SSH

1

sudo apk upgrade -a

APK va réinstaller les paquets depuis les repos officiels.

En cas de problème liée à des conflits de fichier, on peut utiliser cette commande

1

sudo apk fix --force

Cette commande va forcer APK à écraser les fichiers en conflit.

Ma première contribution à KDE

Fri, 12 Jan 2024 00:00:00 +0000

Rapide rappel à propos de KDE

KDE est un projet qui a pour but de développer des logiciels open-source. Le projet comporte plusieurs éléments les plus connus.

KF5 ou KF6 est un ensemble de librairies utilisées pour le développement de l’ensemble des logiciels de KDE. Il est basé sur la librairie QT.

Exemple : Kirigami que l’on peut voir comme un “flutter”.

Note:

KF5 => Basé sur QT5

KF6 => Basé sur QT6

Plasma Shell est l’environnement de bureau développé pour Linux.

Ma configuration

Pour développer sur KDE, KDE fournis un utilitaire assez puissant kdesrc-build. Il permet de configurer l’IDE, compiler, exécuter et gérer les dépendances avec l’aide d’une seule ligne de commande.

Pour le configurer, il suffit de suivre la procédure sur ce lien.

EDIT: Aujourd’hui, il est recommandé d’utiliser kde-builder. C’est le même outil sauf qu’il est écrit en python au lieu de perl. C’est plus simple pour les développeurs qui souhaitent contribuer au projet, car python est plus connu. La configuration reste exactement la même.

Pour plus d’info

Mes premières difficultés

Il faut savoir que quand j’ai commencé à vouloir contribuer au projet KDE. Le projet était en train de migrer de QT5 à QT6. Donc, les configurations nécessaires pour compiler correctement la version 6 était nettement plus compliqué que maintenant. Il n’y avait aucune documentation pour migrer la configuration fournie de base, il fallait fouiller sur Github ou sur les blogs pour réussir à avoir la configuration. Aujourd’hui, il suffit juste de suivre le lien ci-dessus et on peut directement travailler sur KDE 6.

Pour le développement sur KDE Plasma 6, j’ai dû faire quelques réajustements sur le fichier ~/.config/kdesrc-buildrc.

J’ai changé la branche par défaut avec l’option branch-group kf6-qt6. Elle permet de cloner les repositories correctement et d’ajouter l’option cmake -DBUILD_WITH_QT6=on. J’ai aussi changé les fichiers de configuration utilisées pour obtenir le résultat ci-dessous.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


global
 branch-group kf6-qt6
 [...]
end global

include ~/kde/src/kdesrc-build/data/build-include/kf6-common-options.ksb
include ~/kde/src/kdesrc-build/data/build-include/kf6-frameworks.ksb
include ~/kde/src/kdesrc-build/data/build-include/kf6-workspace.ksb
include ~/kde/src/kdesrc-build/data/build-include/kf6-applications.ksb
include ~/kde/src/kdesrc-build/data/build-include/kf6-kdepim.ksb

Configurations utiles

Désactiver l’arrêt de la compilation lors d’une erreur de compilation.

En général, kdesrc-build s’adapte et retire tous les projets qui dépendent de la dépendance qui n’a pas réussi à compiler. Le projet était encore en cours de développement donc les erreurs de compilations étaient très régulières. J’ai tout simplement désactivé avec l’option stop-on-failure false.

Activer le support des LSP

C’est très pratique si on utilise VSCode ou même n’importe quel outil qui supporte les LSP.

Il suffit d’activer les options:

compile-commands-linking => true
compile-commands-export => true

Générer les projets VSCode

Il va générer automatiquement les workspaces VSCode avec les extensions recommander et le paramètrage par défaut. Ça permet de travailler dans de très bonne condition avec VSCode.

Il suffit de l’activer avec generate-vscode-project-config true

Options utiles pour la commande kdesrc-build

-D : Pour ne pas inclure les dépendances dans la compilation

Exemple: kdesrc-build -D kate

-S : Pour ne pas mettre à jour les sources

Exemple: kdesrc-build -S kate

Ma contribution

J’ai contribué sur le support de la lampe torche pour l’environnement Plasma Mobile. La lampe torche fonctionnait uniquement sur les pinephones en utilisant le fichier en dure /sys/devices/platform/led-controller/leds/white:flash/brightness (Source). J’ai réécris le module pour que ça fonctionne de manière générale sur tous les téléphones.

Rappel sur le fonctionnement du noyau Linux autour des leds

Pour comprendre comment la fonctionnalité, un petit rappel s’impose autour du fonctionnement des leds avec le noyau Linux. Dès qu’une led est détecté par le noyau, il va mettre à disposition plusieurs fichiers. On les trouvent dans le dossier correspondant au driver et aussi à l’emplacement physique sur la carte mère ou sur le SOC. Mais on peut aussi les trouver plus facilement dans le répertoire /sys/class/leds/.

sys => Fichiers système class => Trier par class. leds => La class leds. On peut trouver aussi par appareil bluetooth, puce tpm, …

On disposent de plusieurs fichiers importants :

brightness : Permet de changer ou de récupérer l’intensité de la led actuelle.
max_brightness : Permet de connaitre l’intensité max de la led.
color : Ce fichier n’existe pas tout le temps mais permet d’avoir la couleur de la led.
Le reste des fichiers ne sont pas important pour nous.

Explication du fonctionnement de mon code petit à petit

Tout d’abord, il faut savoir que j’utilise la libraire Udev. Il est prévu que je migre vers la librairie Solid une fois le support des leds ajoutées. Udev pour faire simple, c’est une librairie qui permet d’interagir avec les appareils assez directement sans intermédiaire. La librairie permet également de lister, filtrer, détecter si un appareil est connecté/déconnecté, ….

Pour commencer, je dois d’abord instancier Udev avec pour l’utiliser par la suite.

1

struct udev *udev = udev_new();

Ensuite, je liste tous les périphériques qui m’intéressent donc ceux appartenant à la class leds. Pour ça, il me suffit de créer un énumerateur sur lequel on appliquera tous les filtres.

On peut voir une class comme une catégorie d’appareils.

1

struct udev_enumerate *enumerate = udev_enumerate_new(udev);

J’applique le filtre pour lister uniquement ceux qui appartiennent à la class leds.

1
2
3


#define TORCH_SUBSYSTEM "leds"
...
udev_enumerate_add_match_subsystem(enumerate, TORCH_SUBSYSTEM);

J’applique le filtre pour lister uniquement ceux qui ont dans le nom flash ou torch.

1
2


udev_enumerate_add_match_sysname(enumerate, "*:torch");
udev_enumerate_add_match_sysname(enumerate, "*:flash");

Puis je lance le scan avec mes filtres.

1

udev_enumerate_scan_devices(enumerate);

Au début, il faut savoir que je prenais le premier appareil avec le code ci-dessous mais certain téléphone ont une torche de couleur jaune et blanche. Certain utilisateur malheureusement ne pouvait pas utiliser la fonctionnalité.

1
2


struct udev_list_entry *devices = udev_enumerate_get_list_entry(enumerate);
struct udev_list_entry *entry = udev_list_entry_get_next(devices);

Source

Donc, j’ai changé le code avec le code ci-dessous qui permet d’itérer sur tous les appareils.

1
2
3
4
5
6
7
8
9


struct udev_list_entry *devices = udev_enumerate_get_list_entry(enumerate);
struct udev_list_entry *entry = nullptr;

struct udev_device *device = nullptr;

udev_list_entry_foreach(entry, devices)
{
 [...]
}

Pour chaque appareil, j’ai récuperé le répertoire ou se situe l’appareil avec le code ci-dessous qui me renvoie par exemple: /sys/devices/platform/led-controller/leds/white:flash.

1

const char *path = udev_list_entry_get_name(entry);

J’instancie une instance udev_device pour interagir avec lui depuis le répertoire.

1

struct udev_device *device = udev_device_new_from_syspath(udev, path);

Et à partir de là, il me suffit de lire les fichiers dont j’ai besoin.

1

const char *maxBrightness = udev_device_get_sysattr_value(device, "[NOM DU FICHIER]");

Je lis d’abord le fichier ‘color’ et je regarde si la couleur est blanche sinon je continue. Si je ne trouve pas de led de couleur blanche, je prends la dernière valeur récupérée.

Une fois pour chaque appareil trouvé, il me reste plus qu’à récupérer les infos dont j’ai besoin. Donc, la luminosité maximale max_brightness et la luminosité actuelle brightness pour correctement initialiser l’interface de Plasma Mobile.

Quand je souhaite changer la valeur, je dois d’abord convertir la valeur entière en chaîne de charactère.

1

const_cast<char *>(m_torchEnabled ? "0" : m_maxBrightness)

Ensuite, je change la luminosité

1

udev_device_set_sysattr_value(m_device, "brightness", nouvelle_valeur_en_char_*);

Si vous le souhaitez, vous pouvez retrouver le fichier dans son intégralité ici

Info utile pour débugger KDE Plama Mobile depuis Postmarket OS

Le fichier de log se situe dans ~/.local/state/tinydm.log