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. Sur ses quatre éléments lumineux (le clavier, le bouton d’alimentation, le logo du capot, c’est-à-dire le dos de l’écran, et la bande lumineuse arrière), trois répondaient, mais seulement tous ensemble, dans la même couleur. Le clavier, lui, restait sur son bleu clair d’usine. Mon issue sur AWCC n’a jamais abouti (j’y ai depuis posté la réponse). J’ai donc tenté autre chose : braquer une caméra sur le clavier et confier le problème à un agent IA (Claude Code), c’est-à-dire une IA qui lance elle-même les commandes sur la machine et en lit les résultats. Il a travaillé en autonomie totale, sans aucune intervention humaine. 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, le contrôleur AW-ELC d’Alienware (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 savent piloter que le premier, à une exception près, alienfx-linux, qui bloque alors la frappe au clavier.
• Le clavier se règle par des messages de 64 octets (des rapports HID FEATURE) portant le numéro 0xCC, détaillés plus bas. Il y a un piège : juste après un changement de mode, les messages de couleurs envoyés sont droppés silencieusement, sans aucune erreur, 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 (quatre touches ont deux numéros), Fn et la touche de verrouillage de la touche Windows compris. Ces deux-là n’envoient rien à l’ordinateur quand on les presse : une méthode « appuyez sur la touche qui s’allume » n’aurait jamais pu les trouver.
• Le clavier transmet par le même canal ses couleurs et les touches tapées. Donner aux applications l’accès à ce canal 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 de la caméra, ont fini mesurés à la caméra : sur le contrôleur AW-ELC, 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’à ce qu’une mesure témoin (un placebo) donne le même signal.
• Le résultat s’appelle AlienFX LEDs : un service système, une application de bureau, un bouton dans le menu des réglages rapides 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, 0d62 = Darfon). 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). Dans l’article, un rapport envoyé s’appelle un message ; ses premiers octets forment la commande, qui dit quoi faire.
• Contrôleur. La petite puce qui reçoit ces messages et allume les LED.
• Contrôleur AW-ELC. Le contrôleur d’éclairage du châssis des Alienware et Dell G récents : bouton d’alimentation, logo, bande arrière. « AW-ELC » est le nom qu’il annonce lui-même sur l’USB ; aucune documentation ne développe le sigle ELC. Chaque zone y porte un numéro.
• Darfon. Un fabricant taïwanais de claviers, qui fournit le clavier rétroéclairé de ce portable avec son propre contrôleur.
• WMI (Windows Management Instrumentation). Une interface par laquelle le système d’exploitation demande des services au BIOS de la machine. Le pilote Linux alienware-wmi l’utilise pour régler certaines fonctions des Alienware.
• 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.
• Service. Un programme système qui tourne en arrière-plan, sans fenêtre.

Le symptôme, et la cause en une ligne

Voici ce qu’affiche lsusb :

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 et OpenRGB, les outils Linux habituels pour ces machines, ne connaissent que le premier, le contrôleur AW-ELC (187c:0550) ; akbl, plus ancien, ne sait même pas lui parler (voir le tableau plus bas). Le clavier est un autre périphérique USB, qui utilise un autre protocole. Le noyau n’aide pas non plus : sur ce modèle, son pilote alienware-wmi 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 (l’outil vidéo en ligne de commande) 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, ce qui a servi aussitôt :
• 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 le capteur saturait : trop de lumière, et tout devient blanc. 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 AW-ELC, 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 AW-ELC (sous le nom « Dell G Series LED Controller »), zone par zone. Il ne connaît pas le contrôleur Darfon du clavier.
akbl	Interface graphique pour les Alienware	Archivé. Il utilise l’ancien protocole AlienFX des Alienware de 2010 à 2017, incompatible avec les deux contrôleurs du m15 R7.
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. Son auteur l’utilise dans son application Windows, alienfx-tools	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 détache le clavier du pilote du noyau et le pilote lui-même. Résultat : tant que l’outil tourne, on ne peut plus taper sur le clavier interne.

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

• « L’effet 4 du clavier 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 AW-ELC 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, en décimal, de deux de ses commandes (0x21 et 0x22 en hexadécimal). Cette réponse prouve que la commande est arrivée, jamais qu’elle a eu un effet.
• « L’octet d’état que renvoie le clavier indique où il en est. » Il 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] : le clavier compte à partir de 1, alors que les numéros de LED de cet article commencent à 0. 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 le bon mode, et le clavier garde son mode jusqu’à ce qu’on coupe le courant. 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 messages de couleurs envoyés sont droppés silencieusement. Sur un message qui colore 15 LED : 0 LED colorée sur 15 si on l’envoie aussitôt (deux essais sur deux), un essai réussi 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, la lumière monte et descend en douceur), vague (3), pulsation (8, un flash puis un fondu vers le noir), pulsation bicolore (9), chenillard (10, une bande qui fait l’aller-retour).
• 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.
• Le contrôleur AW-ELC (bouton, logo, bande arrière) est lent : 64 ms par message, quelle que soit la façon de l’envoyer. Le bouton d’alimentation (numéro 2 du contrôleur AW-ELC) ne change de couleur qu’avec une séquence de cinq messages, répétée pour chacun de ses six états d’alimentation (branché, sur batterie, en charge, en veille…), plus un message d’ouverture et un de clôture. Cela fait 32 messages, soit 2 s, mais c’est ce qui lui permet de garder sa couleur même 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 : Retour arrière, Verr. Maj, Maj gauche et Windows. C’est une seule LED, joignable par deux numéros. L’agent avait d’abord supposé « deux LED sous une touche large »… mais la touche Windows est une touche normale.
• Chaque numéro k répond aussi au numéro k + 140, sauf celui de la touche <, propre aux claviers européens ; on ne sait pas pourquoi. Ces doublons ne sont pas comptés dans les 89, et le service ne s’en sert pas.
• Pour distinguer volume + et volume −, il a fallu compter, à la loupe sur l’image, les petites ondes sonores dessinées sur les deux touches.
• 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

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 (un retard de 0,1 s avait été mesuré en début de session), 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, braquée sur le clavier. 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 un groupe de numéros témoins, censés 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, c’est-à-dire une mesure témoin « 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 du contrôleur AW-ELC 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. La bande arrière se compose en fait de deux bandes, une haute et une basse. Avec le 0 en rouge et le 1 en bleu, la bande haute est rouge à gauche et bleue à droite, avec un fondu au milieu. La bande basse 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 du contrôleur AW-ELC.
• Les animations du contrôleur AW-ELC 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, le service système d’AlienFX LEDs (son nom vient d’alienfix, le nom de travail du projet), 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 (systemd-analyze security) le note 0,9, sur une échelle d’exposition où 0 est le plus fermé et 10 le plus exposé : « 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 : une connexion ssh ouverte depuis la session graphique, vers la machine elle-même, était acceptée, 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 le menu des réglages rapides : elle est donc passée dans le service, qui mémorise ce réglage 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 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, son profil : 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, Alienware 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 en plus du m15 R7, tous marqués reported (« signalé ») : l’application indique, zone par zone, que personne ne les a vérifiés ici. Seul le m15 R7 est verified (« vérifié »). Le recoupement des sources a relevé une incohérence : akbl et un ancien outil en Python (alienfx) 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 profil 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 envoyée à l’aveugle dans la recherche GNOME (l’agent pilotait le bureau en simulant des frappes avec xdotool), avant que le texte cherché soit arrivé, 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, le script de surveillance écrit par l’agent 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

La réponse est désormais publiée là où la recherche avait commencé : une réponse à mon issue AWCC explique la cause et les deux contrôleurs, et renvoie vers AlienFX LEDs et vers cet article.

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 : la saisie au clavier continue de fonctionner ;
• 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 contourner la règle 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 le journal de la conversation avec l’agent. Le mot de passe a été masqué à la source. Les 26 heures se lisent en deux minutes environ : les temps morts sont réduits à 0,5 s, et le reste est lu en ×4 ; 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 filmées. Elles ont été essayées caméra tournée vers l’arrière, où le bouton est hors du champ.
• L’animation 11, probablement réactive aux frappes, n’a pas pu être vérifiée : il aurait fallu un humain qui tape au clavier pendant que la caméra filme.
• L’éclairage survit à la mise en veille, mais on ne sait pas pourquoi : le clavier garde peut-être ses couleurs de lui-même, ou c’est le service qui les renvoie au réveil.

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, ouvrez une issue sur le dépôt pour dire ce qui s’allume vraiment : c’est ainsi que sa carte pourra être corrigée, puis vérifiée.