gnome-asus-kbd-rgb/docs/RESULTAT_TEST_PERSISTANCE.md

Résultat du test : Forçage de l'état RGB au démarrage

Date : 2025-12-23 Version testée : Avec forçage inconditionnel RGB au démarrage

✅ Résultats des tests

Test 1 : Vérification de l'initialisation au démarrage GNOME Shell

Commande :

journalctl -b -o cat /usr/bin/gnome-shell | grep -i "ASUS RGB" | tail -20

Résultat :

[ASUS RGB] Initialisation au démarrage - forçage de l'état sauvegardé
[ASUS RGB] État initial appliqué : Brightness=1, RGB=(255,120,0), Master=63%
[ASUS RGB] Thème GNOME synchronisé → orange (RGB: 237, 91, 0)

✅ SUCCÈS : Les logs confirment que :

1. L'extension initialise l'état au démarrage
2. Elle force brightness + RGB indépendamment de l'état matériel
3. La synchronisation thème utilise les nouvelles couleurs GNOME corrigées

Test 2 : Vérification de l'état matériel

Commande :

cat /sys/class/leds/asus::kbd_backlight/brightness

Résultat : 1 (sur max 3)

✅ SUCCÈS : Le clavier est bien allumé avec l'intensité attendue.

Test 3 : Vérification des couleurs GNOME corrigées

Logs observés :

[ASUS RGB] Thème GNOME synchronisé → orange (RGB: 237, 91, 0)
[ASUS RGB] Thème GNOME synchronisé → yellow (RGB: 200, 136, 0)
[ASUS RGB] Thème GNOME synchronisé → blue (RGB: 53, 132, 228)

✅ SUCCÈS : Les couleurs correspondent exactement aux couleurs GNOME officielles :

• Orange : (237, 91, 0) ✅ (avant : 255, 120, 0 ❌)
• Jaune : (200, 136, 0) ✅ (avant : 246, 211, 45 ❌)
• Bleu : (53, 132, 228) ✅ (déjà correct)

🎯 Validation de la solution A

Ce qui fonctionne

1. Forçage de l'état au démarrage ✅

   • _applyCurrentState() est appelé au démarrage de l'extension
   • Brightness ET RGB sont toujours écrits, même si brightness = 0
   • Logs explicites pour le débogage

2. Élimination de la logique conditionnelle ✅

   • Suppression du if (currentBrightness === 0) dans writeRGB()
   • Le contrôleur RGB est maintenant toujours dans un état connu

3. Correction des couleurs GNOME ✅

   • Les 9 presets utilisent les couleurs officielles
   • La synchronisation thème fonctionne avec les bonnes valeurs

Prochain test à faire : Redémarrage complet du PC

Instructions :

1. Avant le redémarrage :

   • Notez l'état actuel visible dans l'extension
   • Brightness : niveau 1, 2, ou 3
   • Couleur : celle affichée dans l'aperçu

2. Redémarrer le PC

3. Après le redémarrage :

   # Vérifier les logs d'initialisation
   journalctl -b -o cat /usr/bin/gnome-shell | grep -i "ASUS RGB"
   
   # Vérifier l'état matériel
   cat /sys/class/leds/asus::kbd_backlight/brightness
   

4. Vérifier que :

   • Le clavier s'est allumé automatiquement
   • La couleur est celle sauvegardée
   • L'intensité correspond au niveau GSettings

Scénarios à tester

Scénario 1 : Redémarrage normal avec brightness > 0

• État : Brightness niveau 2, couleur orange
• Attendu : Au login, clavier orange avec intensité 2
• Vérification : Logs montrent "État initial appliqué : Brightness=2, RGB=(...)"

Scénario 2 : Redémarrage avec brightness = 0

• État : Brightness OFF (niveau 0), couleur mémorisée rouge
• Attendu : Au login, clavier éteint MAIS RGB écrit quand même
• Vérification : Logs montrent "RGB mis à (...)" même avec brightness=0
• Résultat : Si vous mettez brightness à 1/2/3, le rouge apparaît immédiatement

Scénario 3 : Dual-boot Windows puis Debian

• Pré-requis : Avoir Windows avec Armoury Crate installé
• Action :
  1. Redémarrer sous Windows
  2. Modifier la couleur du clavier (ex: vert)
  3. Éteindre le clavier dans Armoury Crate
  4. Redémarrer sous Debian
• Attendu : L'extension Debian force la couleur sauvegardée (ignore l'état Windows)
• Vérification : Le clavier affiche la couleur Debian, pas celle de Windows

📊 Diagnostic des logs

Logs normaux attendus au démarrage

[ASUS RGB] Initialisation au démarrage - forçage de l'état sauvegardé
Brightness mise à 1 (1)
RGB mis à (237, 91, 0) [master: 100%]
[ASUS RGB] État initial appliqué : Brightness=1, RGB=(237,91,0), Master=100%

Logs en cas de problème

Si vous voyez :

Erreur lors de l'écriture de brightness: [...]

→ Problème de permissions (règle udev non chargée)

Si vous voyez :

Erreur lors de l'écriture RGB: [...]

→ Problème de permissions ou matériel non supporté

Si vous ne voyez aucun log :

# Vérifier que l'extension est active
gnome-extensions list --enabled | grep asus

# Vérifier les erreurs
journalctl -b -o cat /usr/bin/gnome-shell | grep -i error | grep -i asus

🔍 Prochaines étapes

1. Tester au redémarrage réel du PC (le test le plus important !)
2. Vérifier que le problème "clavier éteint au boot" est résolu
3. Si le problème persiste, envisager la Solution B (service systemd)

💡 Notes techniques

Pourquoi cette solution devrait fonctionner

Le firmware ASUS TUF Gaming peut avoir plusieurs comportements :

1. Réinitialisation au boot : Le contrôleur RGB retourne à l'état par défaut (souvent éteint)
2. Préservation partielle : Brightness conservé mais RGB perdu
3. État aléatoire : Dépend de l'état avant extinction

Notre solution force un état connu au login GNOME, indépendamment de l'état firmware.

Timing d'exécution

Boot PC
  ↓
BIOS/UEFI (firmware ASUS peut réinitialiser RGB)
  ↓
Linux kernel charge (asus-nb-wmi module)
  ↓
Login GNOME
  ↓
GNOME Shell démarre
  ↓
Extension activée → _applyCurrentState() ← ICI ON FORCE L'ÉTAT
  ↓
Clavier dans l'état GSettings ✅

Limitation : Entre le boot et le login GNOME, le clavier peut être éteint. C'est normal et attendu.

Si cela pose problème : On peut implémenter la Solution B (service systemd) qui force l'état avant même le login.

✅ Conclusion provisoire

Le test d'initialisation au démarrage de GNOME Shell fonctionne parfaitement.

Prochaine étape critique : Test au redémarrage complet du PC pour valider que le problème est résolu définitivement.