Bonjour à toutes et à tous, Durant mes prochaines vacances de Noël en France, je vais accomplir une mission qui me procure toujours de la joie. Je vais installer une distribution Linux sur un ordinateur équipé d’un Windows devenu trop gras. L’engin qui doit subir l’intervention appartient à des débutants qui n’ont jamais utilisé Linux. [...]
Note de service : still alive, blog mis à jour et on va essayer d’y poster un peu plus en 2020…
Ces derniers jours, j’ai remarqué qu’un processus GnuPG prenait inhabituellement beaucoup de temps et CPU.
Une commande gpg --list-keys semblait tourner en boucle pendant de longues minutes.
Avec un peu de recherche, je comprends que j’avais importé une clef victime de l’attaque de spam de signature GnuPG annoncée il y a quelques mois.
$ ls -lh ~/.gnupg/pubring.gpg
... 33M ...
Une (ou plusieurs) clef a été signée des centaines de milliers de fois, rendant le système inutilisable. Une attaque simple mais pourtant assez difficile à régler pour des raisons peu rassurantes:
Why Hasn’t It Been Fixed?
There are powerful technical and social factors inhibiting further keyserver development.
The software is Byzantine. The standard keyserver software is called SKS, for « Synchronizing Key Server ». A bright fellow named Yaron Minsky devised a brilliant algorithm that could do reconciliations very quickly. It became the keystone of his Ph.D thesis, and he wrote SKS originally as a proof of concept of his idea. It’s written in an unusual programming language called OCaml, and in a fairly idiosyncratic dialect of it at that. This is of course no problem for a proof of concept meant to support a Ph.D thesis, but for software that’s deployed in the field it makes maintenance quite difficult. Not only do we need to be bright enough to understand an algorithm that’s literally someone’s Ph.D thesis, but we need expertise in obscure programming languages and strange programming customs.
[…]
On utilise donc un proof-of-concept comme serveur de clef GPG et personne ne sait exactement comment il fonctionne. Joie.
gpg –list-keys
Solution
La solution la plus simple serait évidemment de supprimer l’ensemble du répertoire ~/.gnupg et de recommencer. Si, pour de bonnes raisons, cette solution ne vous plaît pas, il nous faudra identifier la ou les clefs problématiques et les supprimer.
Attention, toutes les commandes ci-dessous sont très lentes (une quinzaine de minute chez moi) ! Pensez à prendre un café…
La (grande) commande bash ci-dessous vous listera vos clefs avec la taille de celles-ci. Les deux dernières avec une taille à 8 chiffres sont les clefs problématiques.
Si l’on veut les garder (au cas où), vous pouvez les exporter en plaintext (ce qui donne un fichier de 21MB pour la clef ci-dessous)
$ gpg -a --export 'DB1187B9DD5F693B' > badkey.asc
Mais, il y a de bonnes chances que vous désiriez plutôt les supprimer.
$ gpg --delete-key 'DB1187B9DD5F693B'
gpg (GnuPG) 2.2.17; Copyright (C) 2019 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
pub rsa4096/DB1187B9DD5F693B 2015-01-17 Patrick Brunschwig
Delete this key from the keyring? (y/N) y
gpg: removing stale lockfile (created by 598252)
Après la suppression des clefs problématiques, tout devrait rentrer dans l’ordre !
C'est en ce mardi 26 novembre 2019 que Fedora 29 a été déclaré comme en fin
de vie.
Qu'est-ce que c'est ?
Un mois après la sortie d'une version de Fedora n, ici Fedora 31, la version
n-2 (donc Fedora 29) est déclarée comme en fin de vie.
Ce mois sert à donner du temps aux utilisateurs pour faire la mise à niveau.
Ce qui fait qu'en moyenne une version est officiellement maintenue pendant 13
mois.
En effet, la fin de vie d'une version signifie qu'elle n'aura plus de mises
à jour et plus aucun bogue ne sera corrigé. Pour des questions de sécurité,
avec des failles non corrigées, il est vivement conseillé aux utilisateurs de
Fedora 29 et antérieurs d'effectuer la mise à niveau vers Fedora 31 ou 30.
GNOME Logiciels a également dû vous prévenir par une pop-up de la
disponibilité de Fedora 30 ou 31. N'hésitez pas à lancer la mise à niveau par
ce biais.
Comme le projet Fedora est communautaire, une partie du collège des
organisations suivantes doit être renouvelée : Council, FESCo et Mindshare. Et
ce sont les contributeurs qui décident. Chaque candidat a bien sûr un programme
et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter
le projet Fedora dans certaines directions. Je vous invite à étudier les
propositions des différents candidats pour cela.
Pour voter, il est nécessaire d'avoir un compte FAS
actif et de faire son choix sur le site du
scrutin. Vous avez jusqu'au vendredi 6 décembre à 1h heure française pour
le faire. Donc n'attendez pas trop.
Par ailleurs, comme pour le choix des fonds d'écran additionnel, vous pouvez récupérer un badge si vous cliquez sur un lien depuis
l'interface après avoir participé à un vote.
Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités
afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser
le caractère communautaire de celui-ci.
Council
Le Council est ce qu'on pourrait qualifier le grand conseil du projet.
C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit
les objectifs à long terme du projet Fedora et participe à l'organisation de
celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions
ouvertes et transparentes vis à vis de la communauté.
Mais il gère également l'aspect financier. Cela concerne notamment les
budgets alloués pour organiser les évènements, produire les goodies, ou des
initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge
de régler les conflits personnels importants au sein du projet, tout comme les
aspects légaux liés à la marque Fedora.
Les rôles au sein du conseil sont complexes.
Ceux avec droit de vote complet
Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil
et de facto le représentant du projet. Son rôle est lié à la tenue de
l'agenda et des discussions du conseil, mais aussi de représenter le projet
Fedora dans son ensemble. Il doit également servir à dégager un consensus au
cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec
le consentement du conseil en question.
Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui
fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et
encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui
occupe cette position avec l'approbation du conseil.
Il y a deux places destinées à la représentation technique et à la
représentation plus marketing / ambassadrice du projet. Ces deux places
découlent d'une nomination décidée au sein des organes dédiées à ces activités
: le FESCo et le Mindshare. Ces places sont communautaires mais ce sont
uniquement ces comités qui décident des attributions.
Il reste deux places communautaires totalement ouvertes et dont tout le
monde peut soumettre sa candidature ou voter. Cela permet de représenter les
autres secteurs d'activité comme la traduction ou la documentation mais aussi
la voix communautaire au sens la plus large possible. C'est pour une de ces
places que le vote est ouvert cette semaine !
Ceux avec le droit de vote partiel
Un conseiller en diversité est nommé par le FPL avec le soutien du conseil
pour favoriser l'intégration au sein du projet des populations le plus souvent
discriminées. Son objectif est donc de déterminer les programmes pour régler
cette problématique et résoudre les conflits associés qui peuvent se
présenter.
Un gestionnaire du programme Fedora qui s'occupe du planning des différentes
versions de Fedora. Il s'assure du bon respect des délais, du suivi des
fonctionnalités et des cycles de tests. Il fait également office de secrétaire
du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec
l'approbation du conseil.
Ils vont donc traiter en particulier les points suivants :
Les nouvelles fonctionnalités de la distribution ;
Les sponsors pour le rôle d'empaqueteur (ceux qui pourront donc superviser
un débutant) ;
La création et la gestion des SIGs
(Special Interest Group) pour organiser des équipes autour de certaines
thématiques ;
La procédure d'empaquetage des paquets.
Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un
an, sachant que chaque élection renouvelle la moitié du collège. Ici 5 places
sont à remplacer.
Mindshare
Mindshare est une évolution du FAmSCo (Fedora Ambassadors Steering Committee) qu'il
remplace. Il est l'équivalent du FESCo sur l'aspect plus humain du projet.
Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la
préoccupation de ce conseil est plutôt l'ambassadeur et les nouveaux
contributeurs.
Voici un exemple des thèmes dont il a compétence qui viennent du FAmSCo
:
Gérer l'accroissement des ambassadeurs à travers le mentoring ;
Pousser à la création et au développement des communautés plus locales
comme la communauté française par exemple ;
Réaliser le suivi des évènements auxquels participent les ambassadeurs
;
Accorder les ressources aux différentes communautés ou activités, en
fonction des besoin et de l'intérêt ;
S'occuper des conflits entre ambassadeurs.
Et ses nouvelles compétences :
La communication entre les équipes, notamment entre la technique et le
marketing ;
Motiver les contributeurs à s'impliquer dans différents groupes de travail
;
Gérer l'arrivé de nouveaux contributeurs pour les guider, essayer de
favoriser l'inclusion de personnes souvent peu représentées dans Fedora
(femmes, personnes non américaines et non européennes, étudiants, etc.) ;
Gestion de l'équipe marketing.
Il y a 9 membres pour gérer ce nouveau comité. Un gérant, 2 proviennent des
ambassadeurs, un du design et web, un de la documentation, un du marketing, un
de la commops et les deux derniers sont élus. C'est pour un de ces derniers
sièges que le scrutin est ouvert.
Asus TUF Gaming, Asus ROG Gaming, Asus Aurora, AlienWare, Gigabyte Aero, Gigabyte Fusion RGB, Nvidia, Corsair, Seasonic, NZXT, …. sont des noms qui résonnent forts dans le cœur des Gamers. Et vous le savez bien car ils résonnent aussi dans votre cœur, même si vous n’en êtes pas vraiment un. C’est ce que nous allons voir mais maintenant que vous avez l’eau à la bouche, nous allons commencer ………….doucement. Vous commencez à avoir l’habitude depuis le temps.
Commençons par Gigabyte et sa gamme de portable Gaming Aero avec 3 projets.
fusion-kdb-controller
Créé par martin31821, fusion-kdb-controler permet la configuration RGB du clavier de ce portable.
Il fonctionne sur un Aero 15(X) cependant, d’après son auteur, il est loin d’être complet.
Il n’est packagé pour aucune distribution. Vous serez donc obligé de le compiler en lisant la section correspondante dans le Readme.
A lancer avec les privilèges root!
fusion-kdb-controller-rs
fusion-kdb-controller-rs est, comme vous devez vous en doutez, un fork un plus évolué du projet précédant : fusion-kdb-controller. daniel5151, son auteur, est allé un peu plus loin. En effet, vous pouvez actuellement :
basculer entre les différents présets pré-installés
lecture du fichier personnalisé de configuration
maj du fichier personnalisé de configuration
Bien entendu, là aussi, il n’y a aucun paquet quelque soit la distribution utilisée.
dotnet-core-fusion-keyboard-api
dotnet-core-fusion-keyboard-api est un jeune projet de deux mois à peine réalisé par un français de son alias rameauv. Je ne pourrais vous en dire guère plus sauf qu’il est basé là aussi, sur le travail initial de martin31821 pour l’Aero 15(X).
Bien entendu, là aussi, il n’y a aucun paquet quelque soit la distribution utilisée.
Faustus
Voici un autre projet intéressant. Faustus est un driver pour Linux concernant la série des portables Asus TUF Gaming.
Il permet entre autre, de contrôler l’intensité du clavier rétroéclairée, les leds de celui-ci ainsi que le mode du ventilateur.
Un coup d’œil sur le site Github du projet vous permettra de savoir si votre matériel est supporté, de poser des questions et de voir l’état et l’usage de ce projet.
En attendant, voici la liste officielle du matériel supporté:
Il est disponible sur Aur pour toutes les distributions basées sur Archlinux dont Manjaro et il s’installe de la manière suivante :
yaourt -S faustaus-aur
Après les portables Asus Tuf Gaming, c’est au tour des portables Asus ROG d’enter dans cette liste avec 2 projets sur 4 autres découverts lors de l’écriture de cette partie, ….sur sa fin. Il est toujours conseillé de jeter un œil plus ou moins profond sur les Issues et les PR, y compris celles qui sont fermées. C’est toujours une mine d’informations qui sont souvent omises dans les Readme et les Wiki quand ils existent.
OpenAuraNb
Commençons donc par le premier : openauranb le bien nommé. Il s’agit d’un driver open-source pour contrôler les lumières du portable Gaming ASUS ROG GL553VE.
Bien entendu, il n’est pas disponible pour aucune distribution. Toutefois, d’après le Readme, son utilisation est plutôt simple. Télécharger le projet de la manière qui vous va le mieux.
Voici l’exemple en console avec ce formidable outil qu’est git.
Cette liste est plus importante que le projet précédant. Voici celle-ci :
GL 533 id 0b05:1854
GL 753 id 0b05:1854
GL 503 id 0b05:1869
FX 503 id 0b05:1869
GL 703 id 0b05:1869
GL 504 id 0b05:1866
GL 703 id 0b05:1866
GX 501 id 0b05:1866
GM 501 id 0b05:1866
Bien entendu, il n’est pas disponible pour aucune distribution. Cependant, l’auteur indique dans le Readme comment le compiler pour Ubuntu et aussi si on l’ a récupérer en clonant le dépôt Github. Assez bizarrement, la procédure diffère un peu.
Son usage est plutôt simple :
rogauracore COMMAND_ARGUMENTS
Bien entendu, COMMAND_ARGUMENTS doit être remplacé par un élément de la liste suivante :
single_static
single_breathing
single_colorcycle
multi_static
multi_breathing
red
green
blue
yellow
cyan
magneta
white
black
rainbow
Attaquons nous maintenant à un autre grand (et cher !) fournisseur de portable Gaming : AlienWare. J’ai sélectionné 4 projets qui me semblent/sont particulièrement abouti.
AlienFxLite
Premier à ouvrir le bal, AlienFxLite est un projet en Java Bien que ce projet ne semble plus développé depuis environ 3 ans, il est à voir. Initialement développé pour les portables des séries M15x et M17x, les dernières modifications ayant été testées, l’ont été sur les portables M14x R2 et R3.
Bien entendu, là aussi, il n’existe aucun paquet, quelque soit la distribution. il faudra donc récupérer les sources pour les compiler après s’être assuré que toutes les dépendances nécessaires à la compilations soient présentes. Je n’aurai qu’un conseil : lisez bien le Readme avant.
AlienFx
Écris en Python, AlienFx est un programme fonctionnant à la fois en CLI (alienfx) et avec une interface graphique (alienfx-gtk) dont l’objectif est de contrôler tous les effets lumineux des portables AlienWare. Il a été testé avec succès sur Debian/Ubuntu, Kali, Linux Mint 19, Fedora et Archlinux.
AlienFx est disponible que sur AUR. Pour cela, il suffit de taper la ligne suivante dans un terminal:
yay -S alienfx
Comme vous pouvez vous en doutez, il n’est pas packagé pour les autres distributions. Vous serez donc obligé de l’installer manuellement. Mais dans la sectionDependencies du Readme, vous disposez de toutes les instructions nécessaires à cette tâche.
A noter que le programme dispose des fameuses règles Udev qui évitent à l’utilisateur quand elles sont présentes de lancer le programme en tant que root.
Voici une liste impressionnante de portables supportés par AlienFx.
Dommage que son auteur n’ai pas mis une capture d’écran de la Gui et aussi des explications sur son utilisation en CLI.
Vous avez en votre possession deux méthodes pour l’installer car il n’est packagé pour aucune distribution.
Le moyen le plus facile est de l’installer avec Pip puisqu’il s’agit d’un programme Python disponible sur PiPY.org.
sudo pip(3) install alienware-13r3-alien-effects
L’autre moyen est de l’installer à partir des sources en clonant le repo puis de lancer l’installation en exécutant le setup. à l’aide de la commande suivante:
sudo python(3) install setup.py
Une fois ceci réalisé, vous êtes aptes à configurer les Leds des 8 zones configurables du portable. Alieneffects 13 R3 est un outil en ligne de commande (CLI) qui dispose toutefois d’offrir la possibilité d’ouvrir une TUI (Textual User Interface) pour appliquer un thème pré-défini. L’auteur ne précise pas si Alieneffects 13 R3 vient avec des thèmes pré-défini, ni combien. Cependant, il explique comment créer son/ses propre(s) thème(s).
Voici le TUI en question.
Voici la liste des commandes :
Différentes zones de codes peuvent être attribuées avec différentes zones de couleurs éclairées.
Un peu plus d’informations sur la manière dont Alieneffects 13 R3 fonctionne ici. Il est quand même dommage de ne pas fournir une GUI plus aboutie et fonctionnelle qu’un TUI pour ce logiciel très complet mais seulementlimité au modèle 13 R 3.
AKBL
AKBL est le dernier logiciel de ce comparatif pour les portables Gaming de la marqueAlienWare. C’est aussi un logiciel écris en Python (CLI)qui dispose cependant d’une belle et complète interface en Gtk3 épaulé par un menu dans le systray. Comme les précédents, il a pour but de contrôler les Leds (du clavier, du logo, des haut-parleurs, etc …) des portables AlienWare.
Avant toute chose, il faut l’installer. Et comme souvent, vous commencez à le savoir, il n’est disponible pour aucune distribution pour le moment. Pour cela, en suivant les conseils de l’auteur, télécharger la branche stable de la manière qui vous sied le mieux. Avec Git cela donnera la CLI suivante:
Installer ensuite les dépendances en suivant les indications de la section correspondante. Celles-ci sont pour Debian/Ubuntu et pour Archlinux et dérivées. Assez étrangement, il n’existe aucun PKBUILD alors que son auteur semble tourner sur Archlinux. Ensuite exécuter le setup de la manière habituelle. Si vous avez réussi à installer akbd sur une autre distribution, veuillez ouvrir une demande afin de compléter la section correspondante du Readme.
Vous avez ensuite le choix soit d’utiliser la ligne de commande ou bien l’interface graphique. L’usage en CLI est assez simple:
akbl
Voici la liste des options.
A noter deux fonctionnalités assez intéressantes et inhabituelles:
Vous pouvez aussi changer les couleurs des Leds en fonction de la température du CPU.
Vous pouvez aussi changer les couleurs des Leds en fonction de la météo
Dernier point, akbl est une API Python qui fournit en plus de la GUI et de la CLI un daemon. Un programme vraiment complet. Mieux qu’une explication, un schéma.
Bien que cela ne soit pas mis en avant, et c’est dommage, en fouillant un peu j’ai pu établir la liste des portables supportés, liste assez conséquente que voici:
Le projet est très bien documenté et pour couronner le tout, il s’agit d’un français de Toulouse rsm-gh. Cocoricooo. N’hésitez pas à solliciter rsm-gh qui semble particulièrement réactif aux demandes des ses utilisateurs.
nvidia-led
nvidia-led est l’équivalent à GeForce Experience LED Visualizer mais pour Linux pour les cartes graphiques NVidia GeForce GTX disposant de LED.
Grâce à lui, et en ayant installer les drivers propriétaires nvidia version supérieur ou égale au 331.38, vous piloterez les Leds de la carte.
Cet outil en ligne de commande, est disponible sur AUR et donc pour Manjaro et il s’installe de la manière suivante:
yaourt -S nvidia-led
L’usage de cet outil est simple : on définie l’effet voulu avec l’intensité et son intervalle. Par exemple:
gigabyte_ambientled_ctl est un ensemble de scripts permettant de contrôler l’ambiance des leds qui sont sur certaines cartes mères GIGABYTE. Ce support concerne les cartes utilisant le chip GPIOITE 8620/8628.
Voici la liste des cartes actuellement supportées.
gigabyte_ambientled_ctrl autorise les fonctionnalités suivantes :
configuration des Leds du panneau arrière
contrôle des Leds du mode Audio
fonctionne (pour l’audio) seulement quand la carte son est utilisée
Bien entendu, ce logiciel doit être lancé en tant que root ; votre kernel doit être capable de fonctionner avec le chip gpio-it87. Le support pour le contrôleur ITE 8620/8628 est disponible depuis le kernel 4.7. Si vous disposez d’un kernel plus vieux, il existe un patch qui peut-être trouvé ici.
Si votre carte n’est pas supportée, n’hésitez-pas à ouvrir un ticket sur le site du projet et de tirer en même temps son auteur de sa léthargie. Il n’y a rien de pire d’être seul pour être inactif.
AsrLed
Découvert par hasard il y a seulement deux jours, AsrLed est un pilote Python gérant les Leds pour les cartes mères ASROCK. Pour info, ASROCK est le 4ème fabricant de carte mères avec ASUS, MSI, GYGABYTE. C’est un projet en devenir de seulement un mois d’existance. Malheureusement, pour l’instant, il ne concerne qu’une seule carte mère ASROCK : la carte Fatal1ty AB350 Gaming-ITX/ac. Comme vous pouvez vous en doutez, vous serez obligé de l’installer manuellement. En regardant le code, j’ai pu constaté que ce pilote permet les effets Leds suivant pour ce modèle de carte mère :
static
breathing
strobe
cycling
random
music
wave
A essayer si vous avez ce genre de matériel et que vous êtes téméraires. Et que vous en trouvez l’utilité et pourquoi pas aider ce projet en devenir. A noter un rapprochement avec l’auteur d’un autre grand projet OpenAuraSDK que nous verrons un peu plus loin.
Linux ASUS WMI Sensor Driver
Linux Asus WMI Sensor Driver est un pilote/driver HWMON en utilisant lm_sensors pour de multiples Cartes Mères Asus pour les processeurs Ryzen et Threadripper. Pour info, lm_sensorsfournit des outils et des drivers pour gérer les températures, le voltage, l’humidité, les ventilateurs et aussi les intrusions des châssis de tours des cartes mères qui en sont équipés.
Pour l’installer sous Manjaro (et donc Archlinux), rien de plus simple puisqu’il est disponible sur AUR.
yay -S asus-wmi-sensors
Voici la liste des cartes mères supportées par le logiciel:
Ces fonctionnalités sont les suivantes:
aucune configuration des capteurs n’est requise
information identiques (noms et valeurs) à celles fournit par UEFI de la carte mère
Et pour finir, voici un exemple de sortie des capteurs.
Même si ce ne sont pas les derniers projets de cet article, ce sont certainement les plus intéressants que se soit par les fonctionnalités qu’ils apportent, que par le domaine auxquels ils s’attaquent. Tous les projets que nous avons vu jusqu’à présent tout au long de ces articles utilisent deux librairies : libusb et hidraw. Ce sont des protocoles pour avoir accès a ce type de périphériques qui l’utilisent aussi en sens inverse. Par exemple, l’idVendor et l’idProduct sont intégrés par le constructeur à son périphérique. Et ils sont lu en retour par libusbet /ou hidraw. Et ces informations sont communes à tous les systèmes puisqu’elles appartiennent au périphérique lui-même. Faites un petit test avec la commande lsusb dans un terminal.
Vous ne vous êtes pas demandé tout au long de ces articles pourquoi certains produits, même s’ils figurent en tant que demande, ne sont pas inclus dans aucun des projets que nous avons vu et ne le seront jamais, pas du moins sans passer par SMBus.
Et le plus bel exemple est ……………….les barrettes mémoires. Mais nous en reparlerons un peu plus loin.
LiquidCtl
Crée en Python par Jonas Malaco, un brésilien de Sao Paulo, liquidctl est un programme en ligne de commande CLI, brillamment crée en utilisant non seulement pyusb (la variante python de libusb), hidapi (la variante python aussi) mais aussi et surtoutPMBus. Il est disponible non seulement pour Linux mais aussi pour MacOS et même Windows.
Liquidctl prends en charge en premier lieu les All-In-One. Dans la partie n 5 de cette série, je m’interrogeai sur le fait que certains fabricants étaient très bien pris en charge par les logiciels présentés mais pas d’autres.
La réponse est sur l’utilisation des protocoles
Voici la liste des AIO pris en charge par Liquidctl:
Mais Liquidctl prends aussi en charge d’autres périphériques tel que les alimentations intelligentes Corsair des séries RMi et HiX, les alimentation Seasonic/NZXT de la série E, les Hub intelligents pour ventilateurs et bandes leds de la marque NZXT, de type, Grid+V3, Hue2, Hue 2 Ambient, Smart Device inclus dans les boîtiers H510 Elite, H510i, H710i, M210i. Comme vous pouvez le voir, la liste des périphériques et de leur utilisation est assez variée.
Mais avant toute chose, commençons par l’installer. Je ne parlerai que pour Linux, les instructions pour MacOs sont iciet pour Windows ici.
Sous Manjaro (et donc sous Archlinux), liquidctl est packagé sur AUR en deux versions : la stable et celle de développement. En ligne de commande voici ce qu’il faut faire:
la version stable
$ sudo yay -S python-liquidctl
la version de développement
$ sudo yay -S python-liquidctl-git
Maintenant que tout est en place, apprenons à nous servir basiquement du logiciel.
En premier lieu, le périphérique doit être initialisé. Une fois cette opération réalisée, à ce moment là, le logiciel pourra alors gérer, contrôler beaucoup de choses. Notez que vous pouvez gérer à la fois sans soucis plusieurs périphériques par Liquidctl. Comme ce logiciel touche au bas niveau, il doit être lancé en root. Pour l’arrêter, c’est l’opération inverse : on réinitialise le périphérique avec la même commande. Ce qui revient à faire :
#liquidctl initialize
On peut obtenir la liste des périphériques reconnus par liquidclt:
#liquidctl list --verbose
On peut obtenir de nombreuses informations sur le périphérique tel que :
la température
la vitesse des ventilateurs
la vitesse de la pompe
le firmware (si disponible)
les led disponibles connectées
etc….
Si on veut savoir la version utilisée de Liquidctl, on fait:
#liquidctl --version
Un bon réflexe est de vérifier s’il y a une aide et dans certain cas
#liquidctl --help
Dans certain cas, le logiciel possède un manuel que nous pouvons avoir dans un fichier texte que nous appellerons ici manliquidctl.
man liquidctl > manliquidctl.txt 2>&1
Plutôt qu’un long discours, passons à la pratique en images :
Initialisation du Smart Device v2Monitoring – GestionGestion RGBContrôle du ventilateur
Si on veut passer du mode multi-rail par défaut au mode mono-rail on rajoute l’option –single-12v–ocp à la suite de la commande initialize.
Liquidclt dispose d’une très bonne documentation. D’abord dans le Readme qui explique les bases du maniement du logiciel puis, comme vous pouvez le voir sur les deux captures d’écran plus hautes pour chaque périphérique. Ce sont celles qu’ils vous faut pour optimiser celui-ci et partir ainsi du bon pied. Liquidctl est un logiciel excellent et il serait dommage de partir du mauvais pied. De plus, Jonas est un développeur assez actifet surtout très réactif. Il y a vraiment peu de chance pour que votre requête reste sans réponse, contrairement à d’autres projets…
La CLI peut rebuter certains d’entre-nous et c’est compréhensible, surtout à notre époque. Des utilisateurs de ce merveilleux logiciel ont développé de belles interfaces graphiques. Toutefois, ils ne sont que 2 avec des styles et des langages complètement différents. C’est au choix.
GKraken est un logiciel que vous connaissez déjà si vous suivez l’actualité de ce blog. Il est inutile d’en dire plus et je vous laisse regarder l’article en question. Sachez qu’il est packagé pour Manjaro et voici la ligne de commande adéquate:
$ yay -S python-gkraken
NZXQT a été sommairement présenté dans l’article précédant. Son interface se rapproche plus du logiciel officiel NZXT CAM. Il a pour avantage d’être complet pour les pompes et ventilateurs des AIO (refroidissement, Éclairage, Overclocking) et pour désavantage de ne pas être (encore !) packagé pour AUR. Il faudra donc passer par la récupération de la dernière version puis de lancer son setup. Peut-être faudra-t-il créer un lien pour le lanceur.
Malgré leurs qualités respectives, ces deux logiciels ont un défaut communs. Ils ne supportent pas toutes les fonctionnalités de liquidclt. Effectivement, seule la partie Refroidissement, Éclairage et Overclockingdes pompes et ventilateurs des AIO sont pris en charge, ce qui se résume au premier tableau. Et pour le deuxième Rien. Et c’est dommage. Ne serait-ce que pour les alimentations et je ne parle pas des kits d’Ambiance. C’est le seul logiciel sous Linux a prendre en charge totalement les fonctionnalités des alimentations intelligentes Corsairdes séries RMi et HIx et de prendre en charge une partie seulement des alimentations Seasonicdes séries E.D’ailleurs, à ce titre, si vous disposez de ce genre de matos et d’un peu de temps, aidez Jonas à finaliser les fonctionnalités manquantes. Jonas est très réactifs et si vous l’êtes aussi, en 15 jours maxi ce sera fait. Un petit pas pour vous et un grand de plus pour liquidctlet le libre. Quand on a implanté le code pour les Corsair je ne pensais pas que cela aurai si vite. L’avantage est que toutes les fonctionnalités de ce genre de matos présent dans iCuel’est aussi et uniquement pour le moment dans liquidclt. Il ne manque plus qu’une belle GUI.
Les protocoles PMBus et SMBus sont des mots qui vont venir de plus en plus souvent au fil de ces lignes. Si le premier a été vu juste avant, maintenant , nous allons voir le second avec ce premier logiciel. Une Bombe tant il est ambitieux.
OpenAuraSDK: Pilotez vos RAM G.Skills Trident Z RGB, Corsair Vengence RGB, Corsair Vengence Pro RGB
Voici certainement le plus grand et ambitieux projet de toute cette série d’articles sur les périphériques Gaming. OpenAuraSDK est un projet grandiose dont l’objectif est de fournir les fonctionnalités d’ Asus Aura pour Linux en passant par le fameux protocole SMBus, une évolution du protocole i2C. Ce nom ne vous dis peut-être rien du tout et pourtant. De plus en plus de périphériques utilisent ce protocole. Et pose de plus en plus de problèmes aux Développeurs Libre. Et comme le terrain est encore vierge sous Linux, vous commencez à en mesurer l’enjeu. Si ce n’est pas encore le cas, lisez la suite.
Parmi tous les projets que je vous ai présenté au fil de cette série d’articles, n’y a-t-il pas quelque chose qui vous interloquer ? Non ? En êtes-vous sur ? Ai-je déjà parler d’un logiciel contrôlant les RGB des barrettes mémoires (RAM) ? Non et pour cause. Tout passe par les fameux contrôleurs SMBus. Et pas qu’elles. De plus en plus de périphériques utilisent ce standard et son évolution PMBus. Et en plus, pour corser le tout, il y a aussi des périphériques USB Aura.
Mais venons en au fait. Actuellement, OpenAuraSDK supporte un nombre limité de Cartes Mères et de modules RAM qui sont les suivants:
de détecter le plus de périphériques compatibles avec le contrôleur Asus Aura
de ne pas s’occuper des périphériques compatibles avec les contrôleurs USB Aura.
Pour en revenir à la mémoire Corsair Vengence Pro RGB, le tableau ci-dessous vous montrera ce qui a été fait et ce qui reste à faire, à savoir l’identification/la découverte des possibilités de chaque périphérique. Et c’ est un énorme travail car, vous vous en doutez bien, chaque produit ayant ces propres spécifications. Quand je vous disais que le travail est immense.
Pour l’instant, à partir de l’interface graphique, l’utilisateur peut modifier pas mal de paramètres tel que les couleurs, les modes et les effets de la RAM. Toutefois, il y a un gros hic. En effet, la sauvegarde de ces paramètres n’est pas persistance cad qu’au prochain redémarrage, il faudra tout recommencer. L’auteur Calcprogrammer1 ou plutôt devrais-je dire Adam Honsen’a pas encore investi profondément dans ce domaine. Et comme je le soulignais plus haut, le travail consiste pour l’instant à la découverte du maximum de périphériques Aura. De plus, Adam Honse pense qu’il y a un second endroit dans la mémoire du périphérique qui stocke les paramètres énoncés plus haut. Et que ceux-ci doivent être écris séparément. Ces explications sont pour les plus curieux qui se demandent pourquoi cela n’a pas été encore fait.
Et voici ce que propose le logiciel ASUS AURA.
Ne vous emballez pas trop (comme moi) car il s’agit d’Asus Aura et non de l’interface OpenAuraSDK. A noter que pour l’instant tout le travail se concentre sur le support des cartes mères plutôt que sur l’interface. D’ailleurs, Adam Honse travaille avec plusieurs autres projets qui sont en autre Openaura-CLI, Lights, et openPyaura.
Voici à quoi ressemble actuellement l’interface principale et les écrans qui lui sont associés. Et vous verrez que ce n’est pas la même chose que précédemment :
Le travail est loin d’être fini puisqu’il en est qu’ à son commencement. Toutefois, on peut dire deux choses:
l’ambition du projet
l’intérêt suscité par son travail qui a débouché sur une multitude de projets. Et on en est qu’au début.
Les modules pour les CPU AMD sont packagés au moins sur AUR pour Archlinux et donc Manjaro grâce à Térence Clastres. Voici la commande qui va bien:
Pour la version Intel: un patch est disponible ici
Pour la version AMD: sudo yay -S i2c-piix4-aura-dkms
Assez étrangement, OpenAuraSDK n’est pas distribué sur AUR. Allez, faites un effort, une version stable et une version Git. On pourrait aider plus facilement Adam.
Si la version stable n’a pas beaucoup évoluée récemment, et qu’il y a 8 branches, l’endroit où il faut être en ce momentse situe dans la branche generic_rgb_interface_test.
Si je devais décerner un prix parmi tous ces projets et d’autres…, c’est Le projet de l’année.A surveiller de très près son évolution.
Et voici maintenant le premier projet de cette liste directement dérivé du travail en cours sur OpenAuraSDK.
Openaura-cli
openaura-cli est la version en C++ et en CLI de OpenAuraSDKdébarrassé de son interface graphique et du code de Windows (les dll). Pour l’instant, c’est le but du projet. D’ailleurs, c’est assez basique rien que pour l’installer. Vous vous en doutez bien, il n’y a aucun paquet pour aucune distribution. Il n’y a même pas de makefile. Rassurez-vous, son auteur a quand même mis deux scripts bash pour le construire et le lancer. C’est d’ailleurs sur sa Toto liste. A voir.
openpyaura
openpyaura est un autre projet en Python pour les cartes mères
ASUS. Petite précision. Le projet initié par Vinay Dargar n’est pas un dérivé de OpenAuraSDK (contrairement aux autres) mais un projet à part entière. D’ailleurs, son auteur aide Adam Honse. Bien entendu, il n’y a aucun paquet pour aucune distribution.
Aura-Kernel-Mod
Crée par Thomas Berger, et basé sur OpenAuraSDK, aura-led-mod est un module kernel pour les chipsets Asus Aura.
Bien entendu, il n’y a aucun paquet pour aucune distribution.
Borealis
Crée par Phipax en Rust, Borealis est un pilote Linux dont le but est le contrôle de vos périphériques RGB Aurasans avoir à utiliser l’application Asus Aura. Borealis couvre de multiples protocoles selon son auteur mais toutefois seul les cartes mères utilisant le protocole I2C/SMBus sont actuellement supportés. Et donc seules les Leds des Cartes Mères et des barrettes mémoires sont supportées. Toujours d’après son auteur, ce logiciel n’aurait pas vu le jour sans le travail de OpenAuraSDK. Dans le futur, Borealis supportera d’autres périphériques tel que les GPU.
Actuellement, Borealis permet de changer les Leds dans une seule couleur. C’est un outil en ligne de commande (CLI) dont les arguments sont une triplette ex: cargo run127 0 127 affiche toutes les lumières de la Carte Mère en Violet.
Bien entendu, il n’y a aucun paquet pour aucune distribution.
Vous l’aurez compris, Borealis est un Gros travail en cours.
Lights
Lights est un projet en plein développement et est déconseillé d’utiliser en l’état, pas tant du moins qu’il n’y aura pas de version stable. Cependant, pour les téméraires et les testeurs, toute aide apporté à son auteur est le bienvenue mais mesurer bien avant les risques que vous pourrez peut-être rencontrer. Cela étant dis, poursuivons. Le but est de fournir un ensemble de pilotes et modules Linux et aussi d’explorer des domaines pas encore étudié par OpenAuraSDK.Ces drivers permettront d’interagir simplement avec tous les périphériques Asus Aura.
Actuellement, Light se compose deux modules principaux. Chaque module crée dans le noyau un ou plusieurs répertoires qui couvre une zone RGB disponible au niveau hardware. Chaque zone peut contenir les fichiers suivants:
color : correspond au code couleur en hexadécimal
mode : correspond à la zone d’effet RGB
leds : active les paramètres individuels aux périphériques ARGB
speed :correspond à une valeur numérique comprise en 1 et 5
La création d’une classe interface dans le noyau lui-même rendra plus facile la programmation des modes/zones/leds. A partir de là, n’importe quel périphérique de n’importe quel fournisseur pourra être ajouté facilement avec un minimum de tracas pour le développeur.
Et plus tard, un module système et une interface graphique compléterons l’ensemble. D’après son auteur le plus gros du travail est fait. Seul, les GPU Navi posent problème à son créateur car le protocole I2C est différent. La bonne nouvelle est que les cartes NVIDIAet les GPU VEGA et précédents fonctionnent bien. Bien entendu, bien qu’il soit encore trop top pour le voir, cela semble très prometteur. La bonne nouvelle est que tout ce travail réalisé en amont sera ensuite retro-porté dans OpenAuraSDK.
Bien entendu, il n’y a aucun paquet pour aucune distribution. Du moins, pas encore pour celui-ci, le plus intéressant de tous les projets tournant autour d’OpenAuraSDK.
OpenAuraGtk
OpenAuraGtk est le dernier projet , à la fois de ce comparatif et dérivé d’OpenAuraSDK. Bien qu’il soit encore trop tôt pour en dire davantage vu qu’il en est à ses balbutiements, OpenAuraGtk est une GUI en GTK (qui respecte les Gnome Human Interface Guidelines) qui privilégie deux idées:
la meilleur intégration dans les environnements respectant les règles précédentes
avoir une interface la plus intuitive pour contrôler les périphériques gérés initialement par Asus Aura.
A voir puisqu’il s’agit d’un projet en devenir.
Et maintenant ?
Ce sera tout dans l’immédiat. Dans la 9 ème partie, j’envisage de faire un récapitulatif des projets qui me semblent le plus intéressants sur différents critères. Je n’ai pas encore défini ceux-ci ni comment je procéderai car il y a plein de critères à prendre en compte et qu’ils ne sont pas encore arrêté. De plus c’est un travail difficile. Toutefois, cela peut changer entre-temps. Rien n’est encore fixé. On verra. En attendant, bonne lecture, bonne découvertes et bon tests.
