Alienware m15 R7 sous Linux : une caméra, une IA, et le clavier qui restait bleu

Depuis toujours, mon Alienware m15 R7 sous Ubuntu refusait de changer la couleur de son clavier. Trois éléments lumineux sur quatre répondaient, tous synchronisés, et le clavier restait sur son bleu clair d’usine. Mon issue sur AWCC n’a jamais abouti. J’ai donc tenté autre chose : braquer une webcam sur le clavier et confier le problème à un agent IA (Claude Code) en autonomie totale. Voici ce qu’il a trouvé, où il s’est trompé, et ce qui reste ouvert.

TL;DR

• Le m15 R7 a deux contrôleurs d’éclairage USB indépendants. Le premier, un Alienware « AW-ELC » (identifiant USB 187c:0550), gère le bouton d’alimentation, le logo du capot et la bande lumineuse arrière. Le second, fabriqué par Darfon (identifiant USB 0d62:dabc), pilote le clavier, touche par touche. Les outils Linux existants ne parlent qu’au premier.
• Le clavier utilise des rapports HID FEATURE de 64 octets avec l’identifiant 0xCC : ce sont les messages de réglage que le clavier accepte (détaillés plus bas). Il y a un piège : juste après un changement de mode, les paquets de couleurs envoyés sont droppés silencieusement pendant 20 à 50 ms.
• La table des touches a été relevée à la caméra, une LED à la fois : 89 numéros de LED pour 85 touches, Fn et le verrou Windows compris (aucune méthode par capture des frappes ne pouvait les trouver).
• Le clavier transmet par le même canal ses couleurs et les touches tapées. Le rendre accessible aux applications revient à offrir un enregistreur de frappes (keylogger) à n’importe quel programme. D’où un service système confiné, qui seul y a accès.
• Le logo du capot et la bande arrière, d’abord hors du champ, ont fini mesurés à la caméra : le numéro 3 est le logo, et la bande arrière a deux canaux indépendants (numéros 0 et 1). Avant cela, une mesure indirecte avait semblé positive… jusqu’au placebo.
• Le résultat s’appelle AlienFX LEDs : un service système, une application de bureau, un bouton dans le menu rapide de GNOME et une commande en terminal. En plus du m15 R7 mesuré, l’ensemble connaît 49 autres modèles Alienware et Dell, repris d’autres projets libres et marqués comme non vérifiés.

---

Quelques mots de vocabulaire

L’article reste technique, mais ces quelques termes suffisent pour le suivre :

• USB, identifiant USB. Chaque périphérique USB annonce un identifiant « fabricant:produit », par exemple 187c:0550 (187c = Alienware). C’est ce qu’affiche la commande lsusb.
• HID (Human Interface Device). La norme USB des claviers, souris et manettes. Un périphérique HID échange avec l’ordinateur de petits messages de taille fixe, appelés rapports. Chaque rapport porte un numéro qui dit à quoi il sert ; les rapports FEATURE servent aux réglages (ici, les couleurs).
• Contrôleur. La petite puce qui reçoit ces messages et allume les LED.
• Firmware. Le programme qui tourne dans ce contrôleur : c’est lui qui interprète les messages et gère les animations intégrées.
• hidraw. Sous Linux, chaque périphérique HID apparaît comme un fichier spécial (/dev/hidraw5, par exemple). Qui peut ouvrir ce fichier peut dialoguer directement avec le périphérique.
• Démon. Un service système qui tourne en arrière-plan, sans fenêtre.

Le symptôme, et la cause en une ligne

Bus 003 Device 004: ID 187c:0550 Alienware Corporation LED controller
Bus 003 Device 005: ID 0d62:dabc Darfon Electronics Corp. Keyboard

Tout est là : deux contrôleurs d’éclairage, pas un. AWCC, OpenRGB et akbl, les outils Linux habituels pour ces machines, ne connaissent que le premier, 187c:0550. Le clavier est un autre périphérique USB, qui parle un autre langage. Et ce n’est pas le pilote Linux qui peut aider : sur ce modèle, le pilote alienware_wmi du noyau ne gère que les ventilateurs et les profils de performance, pas l’éclairage.

Le dispositif : une caméra, et une règle

La règle donnée à l’agent était simple : ne jamais conclure d’après la réponse d’une commande. Ce matériel accepte poliment des commandes qui n’allument rien. Seule la lumière fait foi.

Une caméra Logitech C920, sur un pied posé à côté de l’ordinateur, est braquée sur le clavier. Deux détails ont compté :

• Un seul programme à la fois. La C920 est une caméra UVC (USB Video Class, la norme des webcams), et son flux vidéo ne peut être ouvert que par un seul programme à la fois. Or il fallait ces images à plusieurs endroits en même temps : dans la vidéo de la session, pour pouvoir revoir ensuite le travail de l’IA, et dans chacun des outils de mesure. Un seul ffmpeg lit donc la caméra et produit deux sorties : la vidéo, et une image fixe réécrite dix fois par seconde, que lisent tous les outils. Les réglages de la caméra (exposition, mise au point), eux, restent modifiables pendant l’enregistrement.
• L’exposition automatique de la caméra ment. En automatique, la LED du bouton d’alimentation apparaissait blanche, qu’elle soit rouge ou verte, parce que la caméra saturait. L’agent est donc passé en exposition manuelle, avec une balance des blancs fixe et une mise au point verrouillée sur le réglage le plus net.

Où s’arrêtent les projets existants

Projet	Ce qu’il fait	Où il s’arrête sur le m15 R7
AWCC (tr1xem)	Ligne de commande, interface graphique et service, pour les Alienware et Dell G récents	Ne parle qu’au contrôleur 187c:0550, qui gère le bouton d’alimentation, le logo du capot et les deux canaux de la bande arrière. Il les règle tous de la même couleur, et ne voit pas le clavier.
OpenRGB	Outil généraliste pour l’éclairage RGB	Gère ce même contrôleur (sous le nom « Dell G Series LED Controller »), zone par zone. Il ne connaît pas le contrôleur du clavier fabriqué par Darfon.
akbl	Interface graphique pour les Alienware	Archivé. Il utilise l’ancien protocole des Alienware d’avant 2018, incompatible avec ces contrôleurs.
AlienFX-SDK (T-Troll)	La bibliothèque de référence, sous Windows, dont s’inspirent la plupart des outils ci-dessus ; elle connaît les deux contrôleurs	Windows uniquement, et le sens de certains octets y est supposé plutôt que mesuré (voir ci-dessous).
alienfx-linux	Adaptation Linux de cette bibliothèque : le seul outil qui parle au clavier sous Linux	Pour lui parler, il retire le clavier au pilote Linux. Résultat : le clavier interne ne tape plus tant que l’outil tourne.

Et trois affirmations de l’AlienFX-SDK, la bibliothèque de référence, qui ne tiennent pas sur cette machine :

• « L’effet 4 est une vague bicolore. » Il affiche en réalité une bande figée. La vague bicolore, c’est l’effet 3 avec deux couleurs.
• « Le contrôleur répond 33 quand il est prêt, 34 quand il est occupé. » La réponse relue est en fait l’écho de la dernière commande envoyée : 33 et 34 ne sont que les numéros des commandes elles-mêmes (0x21 et 0x22). Cette réponse prouve que la commande est arrivée, jamais qu’elle a eu un effet.
• L’octet d’« état » du clavier valait 0x17 à chaque lecture, avant comme après un changement de couleur. Il ne renseigne sur rien.

Comment on parle au clavier, et les pièges

Pour changer les couleurs, on envoie au clavier des messages de 64 octets marqués 0xCC. Un message commence par une commande (quelques octets), suivie de ses données. Pour colorer des LED, la commande est 8c 02 00, suivie de blocs de 4 octets : [numéro de la LED + 1, rouge, vert, bleu]. Un message contient au plus 15 blocs, donc colore au plus 15 LED ; il en faut six pour tout le clavier.

Le premier essai allume la rangée F1, F2… F12. Victoire ? Non. Ça marchait « tout seul » parce que l’ancienne stack d’éclairage installée sur la machine avait laissé le clavier dans un état déjà partiellement initialisé. L’agent a lancé une animation intégrée, puis réessayé : plus rien ne s’affichait.

Il manquait une commande de mode. Le clavier a deux modes : soit il joue lui-même ses animations intégrées (vague, respiration…), soit il affiche les couleurs qu’on lui donne touche par touche. Tant qu’on ne lui envoie pas 80 01 fe 00 00 01 01 01 pour passer en mode « touche par touche », il ignore les couleurs reçues. Cette commande n’était documentée nulle part : elle était enfouie dans le code de l’AlienFX-SDK.

Le piège le plus sournois est apparu au premier démarrage du service, avec une rangée du haut restée noire :

Juste après ce passage en mode « touche par touche », les paquets de couleurs envoyés sont droppés silencieusement : 0 sur 15 appliqués si on les envoie aussitôt (deux essais sur deux), un essai sur deux après 20 ms, 15 sur 15 après 50 et 100 ms. Aucune erreur n’est signalée. Le service attend donc 100 ms après chaque changement de mode.

Le reste, mesuré sur la machine (à la caméra pour tout ce qui s’allume) :

• Luminosité (83 38 9c <0 à 255>) : un vrai variateur, qui baisse la lumière sans modifier les couleurs.
• Animations intégrées : respiration (2), vague (3), pulsation (8), pulsation bicolore (9), balayage (0xA).
• Vitesse des animations : le paramètre dit « tempo » est une durée, pas une vitesse. Plus il est grand, plus c’est lent : la vague fait un tour en environ 0,6 s × tempo.
• L’autre contrôleur (bouton, logo, bande arrière) est lent : 64 ms par commande, quelle que soit la façon de l’envoyer. Le bouton d’alimentation ne change de couleur qu’avec une séquence particulière, répétée pour chacun de ses six états d’alimentation (branché, sur batterie, en charge, en veille…). Cela fait 32 commandes, soit 2 s, mais c’est ce qui lui permet de garder sa couleur machine éteinte.

La cartographie à la caméra

Le clavier désigne chaque LED par un numéro, sans rapport avec la touche. Pour savoir qui est qui, on allume un numéro et on regarde. En boucle : clavier noir, un seul numéro allumé en blanc, trois images moyennées, comparaison avec une image du clavier éteint, et repérage du point le plus lumineux. Ensuite, la géométrie : les quatre coins du clavier sont repérés sur l’image, la perspective est redressée, et chaque point lumineux est rattaché à la touche la plus proche.

• 89 numéros pour 85 touches éclairées ; la barre d’espace n’a pas de LED.
• Fn et le verrou Windows ont une LED, mais n’envoient aucune frappe à l’ordinateur. Une méthode qui aurait demandé « appuyez sur la touche qui s’allume » ne les aurait jamais trouvées.
• Quatre touches répondent à deux numéros, au même endroit : une seule LED, joignable par deux adresses. L’agent avait d’abord supposé « deux LED sous une touche large »… mais la touche Windows, qui en fait partie, est une touche normale.
• Chaque numéro k répond aussi au numéro k + 140, sauf la touche <, propre aux claviers européens.
• Il a fallu compter les ondes sonores sur les icônes, à la loupe, pour distinguer volume + et volume −.
• Contrôle : 12 touches tirées au sort, allumées par leur nom, retrouvées à moins de 12 pixels près, pour des touches d’environ 100 pixels.

Le balayage décalé d’un cran, et l’identification des cas délicats

Un premier balayage complet a donné une carte décalée d’un cran, avec des doublons et 14 touches « sans LED ». Le premier réflexe a été de soupçonner le clavier. Faux. L’image de la caméra arrivait avec 0,5 s de retard (0,1 s mesuré plus tôt), alors que le balayage n’attendait que 0,35 s après chaque allumage : il regardait donc l’image où la touche précédente était encore allumée. Le balayage mesure désormais ce retard avant de commencer. Résultat : 89 numéros sur 89 conformes à la carte ci-dessus, et 12 touches sur 12 retrouvées par leur nom.

Le logo du capot et la bande arrière : un faux positif, puis la mesure

Le logo du capot et la bande lumineuse arrière sont hors du champ de la C920. L’agent a d’abord essayé une mesure indirecte : la webcam intégrée de l’ordinateur, tournée vers la pièce, cherchait si la pièce s’éclairait un peu quand on allumait ces LED. Pour faire sortir un signal aussi faible du bruit, on allume et on éteint des dizaines de fois, et on moyenne la différence. Premier résultat : les numéros 0, 1 et 3 semblaient bien éclairer la pièce… Mais le groupe de numéros censé ne rien allumer donnait lui aussi un signal.

L’agent a refait la mesure en bloquant l’exposition de la webcam, dans un ordre tiré au hasard et avec un placebo : une mesure « noir contre noir », qui ne peut rien montrer. Tout est retombé au niveau du placebo. L’effet venait des réglages automatiques de la webcam ; sans le placebo, ce premier résultat aurait été publié comme une mesure. Tant qu’on ne voit pas ces LED, la seule réponse honnête est « on ne sait pas ».

La seule solution sérieuse consistait donc à tourner la C920 vers le dos de l’écran. Même méthode que pour le clavier : tout éteindre, puis allumer chaque numéro seul, en vert.

• Le numéro 3 est le logo alien du capot.
• Les numéros 0 et 1 éclairent tous deux la bande arrière, et ce sont deux canaux indépendants. Avec le 0 en rouge et le 1 en bleu, la bande supérieure est rouge à gauche et bleue à droite, avec un fondu au milieu. La bande inférieure fait l’inverse : les deux canaux se croisent, comme si deux LED alimentaient un même anneau de diffusion (c’est une hypothèse, l’intérieur n’a pas été vu).
• Les numéros 4 à 15 n’allument rien de visible, et la LED ronde bleue visible dans un coin de l’image ne dépend pas de ce contrôleur.
• Les animations du contrôleur fonctionnent sur ces zones : une pulsation sur le logo (un cycle toutes les 2,4 s environ), et un fondu rouge ↔ bleu sur un canal pendant que l’autre reste fixe.

Dans AlienFX LEDs, ces deux canaux deviennent Rear LEDs A et Rear LEDs B : deux couleurs, ou deux effets, à régler séparément.

Un service système, parce que le clavier transmet aussi vos frappes

Le clavier de ce portable utilise le même canal (le même fichier /dev/hidraw) pour recevoir ses couleurs et pour transmettre les touches tapées. Donner aux applications le droit de changer les couleurs, ce serait leur donner aussi le droit de lire tout ce qui est tapé : un keylogger. D’où l’architecture suivante :

• alienfixd, un service système, est le seul programme qui ouvre ces fichiers. Il tourne en tant que root, mais privé de tous les pouvoirs de root dont il n’a pas besoin, et enfermé par systemd : il n’accède qu’aux périphériques d’éclairage, ne voit presque rien du système de fichiers, n’a pas de réseau, et ne peut appeler qu’une liste restreinte de fonctions du noyau. L’outil d’audit de systemd le note 0,9 sur 10 en exposition, « SAFE ».
• Une interface étroite. Les applications lui parlent par D-Bus, le système de messages du bureau Linux, avec des demandes d’éclairage uniquement (« mets cette touche en rouge ») choisies dans des listes fermées. Elles ne peuvent jamais lui faire transmettre un message brut au clavier. Chaque demande est revérifiée par le service.
• polkit, le gestionnaire d’autorisations du bureau : la personne assise devant la machine peut changer l’éclairage, pas une session à distance ni une session verrouillée. Vérifié avec une vraie connexion ssh. Au passage, une fausse alerte instructive : un premier test ssh lancé depuis la session graphique était accepté, parce que polkit juge le programme qui fait la demande, pas le chemin par lequel on s’est connecté.
• L’effet d’onde (« ripple »), qui réagit à la frappe, pose de nouveau la question du keylogger. Première version : l’application n’écoutait que les touches tapées dans sa propre fenêtre, quand celle-ci était au premier plan, et après activation manuelle. Impossible, dès lors, d’allumer l’onde depuis les réglages rapides : elle est donc passée dans le service, qui l’enregistre avec le reste de l’éclairage. Le service lit désormais les frappes, sous des règles étroites : seulement quand l’onde est allumée (elle est éteinte par défaut, et l’allumer passe par polkit) et l’éclairage aussi ; seulement depuis le clavier intégré (le périphérique USB qui est aussi le clavier lumineux, et le clavier interne du portable), jamais depuis un clavier externe ; une frappe ne devient qu’une position sur le clavier, elle n’est ni enregistrée, ni journalisée, ni transmise. Débit mesuré : 42 images de clavier complet par seconde à travers toute la chaîne, pour une animation à 30 images par seconde.

L’application de bureau, AlienFX LEDs, a une interface en anglais. Elle a son propre dépôt : Zeecka/alienfx-leds.

Et les autres Alienware et Dell ?

Le m15 R7 n’est pas une exception : beaucoup d’Alienware et de Dell G sortis depuis 2019 embarquent le même contrôleur AW-ELC, et plusieurs portables Alienware le même genre de clavier Darfon. Ce qui change d’un modèle à l’autre, c’est la carte : quel numéro allume quoi. L’application ne code donc plus le m15 R7 en dur. Chaque machine est décrite par un petit fichier modèle : ses zones lumineuses, le contrôleur qui pilote chacune, et un clavier réglable touche par touche, par zones, ou pas du tout.

Contrôleur	Identifiant USB	Machines
AW-ELC	187c:0550, 187c:0551	m15/m16/m17/m18, x17, Area-51m, Aurora ; les claviers à 4 zones des Dell G15, G5, G7
Clavier Darfon touche par touche	0d62:…	m15 R3 et suivants, m16, m17, m18, x15/x17
Ancien contrôleur AlienFX	187c:0511 à 187c:0530	2010–2017 : M11x, M14x, M17x, M18x, 13, 15, 17, Area-51, Aurora R4
Pilote alienware-wmi du noyau	aucun (réglage par le BIOS)	Ordinateurs de bureau d’avant 2018 (X51, Alpha)

Les cartes viennent d’autres projets libres, et seulement sous forme de faits (identifiants, numéros, noms de zones) : alienfx-tools (licence MIT), akbl, OpenRGB et AWCC. Cela fait 49 modèles, tous marqués reported : l’application indique, zone par zone, que personne ne les a vérifiés ici. Seul le m15 R7 est verified. Le recoupement des sources a relevé une incohérence : akbl et un ancien outil en Python attribuent à ces contrôleurs l’ancien protocole AlienFX, ce que contredisent alienfx-tools, OpenRGB et les mesures à la caméra. Ces entrées ont été écartées.

L’application reconnaît le modèle à son nom, tel que l’inscrit le BIOS, ou à l’identifiant USB de son contrôleur ; on peut aussi le choisir à la main. Une machine inconnue a quand même un modèle de base, construit à partir des contrôleurs réellement détectés, avec des noms de zones neutres (« Light 0 », « Light 1 »…). Et si elle a un clavier réglable touche par touche, c’est la même méthode qu’ici, sans la caméra : un assistant fait clignoter chaque LED, et l’on clique sur la touche qui s’allume. Sur le m15 R7, la refonte ne change rien : pour un même réglage, les messages envoyés sont identiques, octet pour octet, à ceux de la version vérifiée à la caméra.

Les erreurs, telles qu’elles se sont produites

L’agent en a fait, et je les garde, parce que ce sont elles qui rendent les mesures crédibles :

• une zone de mesure décalée de 70 pixels sur l’image, qui lui a fait conclure « le bouton ne change pas » alors qu’il était rouge ;
• le faux positif de la webcam intégrée, démasqué par le placebo ;
• une fausse faille de sécurité ssh, qui n’était qu’un artefact du test ;
• une touche Entrée pressée à l’aveugle dans la recherche GNOME, qui a lancé Steam, prêt à installer des paquets (annulé à temps, rien d’installé) ;
• environ 15 s de vidéo perdues : au réveil d’une mise en veille, son propre script de surveillance a pris la veille pour une panne et relancé l’enregistrement ;
• une attente fixe trop courte pour le retard réel de la caméra, qui a décalé un balayage complet d’un cran (voir plus haut).

Vers l’amont

Les propositions de modifications (pull requests) pour les projets existants sont rédigées et relues, mais pas encore publiées :

• AWCC : l’explication de la cause, et les zones du m15 R7 (logo, bande arrière à deux canaux) ;
• alienfx-linux : parler au clavier sans le retirer au pilote Linux, et attendre après un changement de mode. Testé sur la machine : le clavier continue de taper ;
• AlienFX-SDK : corriger les commentaires que les mesures contredisent.

Pour OpenRGB, aucune pull request : ses règles de contribution interdisent le code généré par IA, et retirer la mention pour passer serait tromper les mainteneurs. À la place, un rapport matériel factuel, qu’un humain pourra reprendre.

Toute la session en asciinema

Plutôt qu’un enregistrement d’écran (qui avait filmé un mot de passe au passage), voici la session complète en asciinema, un enregistrement de terminal rejouable dans le navigateur : demandes, raisonnement de l’agent, commandes et extraits des résultats, reconstruits depuis la transcription. Le mot de passe a été masqué à la source. Les 26 heures se lisent en deux minutes environ (lecture ×4, attentes plafonnées à 0,5 s) ; la pause et la barre de progression permettent de s’arrêter sur un passage.

Ce qui reste ouvert

• Les animations du bouton d’alimentation : envoyées comme sur les autres zones, mais jamais vues, le bouton étant hors du champ de la caméra tournée vers l’arrière.
• L’animation 11 (0xB), probablement réactive aux frappes, n’a pas pu être vérifiée sans humain au clavier.
• L’éclairage survit à la mise en veille, mais on ne sait pas pourquoi : le clavier a pu garder ses couleurs de lui-même, sans que le service ait à les renvoyer.

Le code (service, commande en terminal, application de bureau, extension GNOME et catalogue de modèles) est sur GitHub : Zeecka/alienfx-leds. Si vous avez un Alienware ou un Dell G dont la carte est marquée reported, dites-moi ce qui s’allume vraiment : c’est ainsi que sa carte pourra être corrigée, puis vérifiée.