# RedRTOS — gestion d'energie, defauts systeme (/etc/xdg).
#
# ☠️☠️ POURQUOI CE FICHIER EXISTE. Le 02/08, le proprietaire signale que la jauge
#    batterie « est nulle, elle affiche deja 100 % ». Diagnostic :
#
#    ~/.config/powerdevilrc portait AutoSuspendIdleTimeoutSec=0 dans LES TROIS
#    profils (AC, Battery, LowBattery) et l'extinction d'ecran par inactivite
#    desactivee. MESURE : ZERO entree en veille sur un boot de 5 h 17 et un autre
#    de 1 h 23 — temoin pris, le journal du boot -2 est lisible (44 730 lignes).
#    Le telephone ne dormait JAMAIS.
#
#    CONSEQUENCE EN CHAINE, et c'est la le piege : le micrologiciel du PMIC ne
#    rafraichit son registre SDAM qu'a la SORTIE DE VEILLE (documente dans
#    0006-qcom_qg-ocv-capacity.patch). Jamais de veille ⇒ jamais de
#    rafraichissement ⇒ `capacity` fige a sa valeur d'allumage (100 %) et
#    `voltage_ocv` bloque a 4,4172 V, soit AU-DESSUS du maximum physique de la
#    cellule (voltage_max_design = 4,4 V). Une valeur impossible, donc morte.
#    🔑 LA JAUGE N'ETAIT PAS CASSEE : ELLE ETAIT AFFAMEE.
#
#    Le reglage fautif vivait dans ~/.config — un des 89 fichiers NON EMPAQUETES.
#    Tres probablement un contournement pose pendant un debogage (garder SSH
#    vivant : une session SSH inhibe la veille) et jamais retire. Il n'aurait pas
#    survecu a un reflash, et personne n'aurait su pourquoi le telephone se
#    remettait a dormir. C'est exactement ce que ce paquet doit empecher.
#
# ⚠️ CE FICHIER EST UN DEFAUT SYSTEME. Un ~/.config/powerdevilrc existant le
#    MASQUE : sur un appareil deja en service il faut corriger aussi le fichier
#    utilisateur. Ici il ne rattrape que les installations neuves.
#
# ⚠️ Effet de bord assume, deja paye sur ce projet : la veille active COUPE les
#    sondes longues par SSH, et inversement une session SSH ouverte INHIBE la
#    veille — un compteur de veille a zero pendant un debogage ne prouve donc
#    rien. Voir le piege « sleep-inhibitor ».

[AC][Display]
DimDisplayIdleTimeoutSec=60
DimDisplayWhenIdle=true
TurnOffDisplayIdleTimeoutSec=120
TurnOffDisplayWhenIdle=true

# Sur secteur on dort quand meme (10 min) : c'est le comportement normal d'un
# telephone, ET c'est ce qui donne au PMIC l'occasion de rafraichir sa jauge
# pendant la charge. Sans ca, le pourcentage reste faux tant qu'il est branche.
[AC][SuspendAndShutdown]
AutoSuspendAction=1
AutoSuspendIdleTimeoutSec=600

[Battery][Display]
DimDisplayIdleTimeoutSec=20
DimDisplayWhenIdle=true
TurnOffDisplayIdleTimeoutSec=30
TurnOffDisplayWhenIdle=true

# ☠️☠️ 06/08 — 180 -> 60 -> 180 EN TROIS HEURES. LIRE AVANT DE RETOUCHER A CETTE VALEUR.
#
# Passe a 60 s a la demande du proprietaire (il avait regle « 1 min » dans l'interface,
# sans effet : la cle etait alors IMMUABLE — PowerDevil acceptait et n'ecrivait rien.
# ⚠️ CE N'EST PLUS LE CAS depuis le 06/08 au soir : le gel est leve, voir plus bas.
# Cette valeur n'est donc plus qu'un DEFAUT, surchargeable depuis l'interface).
# REMIS A 180 s le soir meme, sur ce constat de sa part : « le tel se met en veille meme
# quand je suis actif dessus ».
#
# 🔑 LA CAUSE N'ETAIT PAS LE DELAI, et c'est ce qui rend le piege interessant. Sur un
#    telephone sain la sequence est TAMISAGE -> ECRAN ETEINT -> VEILLE : l'ecran qui
#    s'eteint EST l'avertissement. Or ~/.config/powerdevilrc, reecrit par PowerDevil le
#    03/08 a 22:38, portait dans les TROIS profils :
#        TurnOffDisplayIdleTimeoutSec=0
#        TurnOffDisplayWhenIdle=false
#    L'ecran ne s'eteignait donc JAMAIS, et PowerDevil passait directement d'« inactif »
#    a « veille », ecran allume, sous les yeux de l'utilisateur. A 180 s ca laissait trois
#    minutes ; a 60 s ca tombe en pleine lecture.
# ➜ MORALE : ce delai n'est lisible qu'avec l'extinction d'ecran EN FACE. Le raccourcir
#   sans verifier que l'ecran s'eteint d'abord, c'est programmer une veille qui surprend.
# ⚠️ Et c'est le MEME piege qu'en r55, d'un cran plus bas : les cles Display sont laissees
#   LIBRES a dessein, et PowerDevil s'en sert pour ecrire des valeurs qui cassent l'usage.
[Battery][SuspendAndShutdown]
AutoSuspendAction=1
AutoSuspendIdleTimeoutSec=180

[LowBattery][Display]
DimDisplayIdleTimeoutSec=15
DimDisplayWhenIdle=true
TurnOffDisplayIdleTimeoutSec=20
TurnOffDisplayWhenIdle=true

[LowBattery][SuspendAndShutdown]
AutoSuspendAction=1
AutoSuspendIdleTimeoutSec=60

# ═══════════════════════════════════════════════════════════════════════════════
#  ☠️☠️ 03/08 — LES CLES DE VEILLE SONT IMMUABLES, ET VOICI CE QUE CA A COUTE
# ═══════════════════════════════════════════════════════════════════════════════
#
#  Le correctif du 02/08 (ci-dessus) a pose les bons defauts ICI, dans /etc/xdg.
#  Il n'a pas tenu 24 heures : le 03/08 a 21 h 56, PowerDevil a REECRIT
#  ~/.config/powerdevilrc avec AutoSuspendIdleTimeoutSec=0 dans les trois
#  profils — exactement les valeurs que cet en-tete denonce. Le fichier
#  utilisateur GAGNE sur /etc/xdg, donc le telephone a cesse de dormir.
#
#  MESURE, le soir meme : compteur de veilles FIGE a 3 pendant tout l'essai,
#  ecran eteint. Une fois ~/.config/powerdevilrc retire : DEUX veilles en dix
#  minutes, et le RTC a reveille l'appareil a l'heure dite.
#
#  🔑 CE QUI REND CE DEFAUT SI COUTEUX : il ne casse pas la veille toute seule.
#     Le micrologiciel du PMIC ne rafraichit son OCV qu'AU REVEIL — un telephone
#     qui ne dort jamais a donc AUSSI une jauge figee. Un seul « 0 » dans un
#     fichier de confort, et l'appareil annonce 100 % en s'eteignant.
#
#  ➜ `[$i]` = cle IMMUABLE en KConfig : l'espace utilisateur ne peut plus la
#    surcharger. Meme mecanisme que /etc/xdg/kdeglobals, qui l'emploie deja ici.
#
# ═══════════════════════════════════════════════════════════════════════════════
#  ✅ 06/08 — LE GEL EST LEVE. SON MOTIF A ETE DISSOUS PAR NOS PROPRES CORRECTIFS.
# ═══════════════════════════════════════════════════════════════════════════════
#  Tout le raisonnement ci-dessus tenait a UNE phrase : « le micrologiciel du PMIC
#  ne rafraichit son OCV qu'AU REVEIL, donc un telephone qui ne dort jamais a AUSSI
#  une jauge figee ». C'etait vrai le 03/08. Ca ne l'est plus.
#
#  🔑 CE QUI A CHANGE, cote noyau :
#     - 0023 a CESSE de lire la copie SDAM (jamais ecrite, valeurs impossibles) et
#       ancre desormais sur l'OCV que le MATERIEL mesure (S3/S7), rafraichi des que
#       le courant reste faible assez longtemps — pas seulement au reveil ;
#     - 0029 integre le courant moyen ENTRE deux ancres, toutes les 10 s ;
#     - 0032 (r68) annonce enfin les changements a l'espace utilisateur.
#
#  🔬 MESURE, le 06/08, DEUX FOIS, et c'est ce qui autorise a lever le gel :
#     pendant les deux temoins de jauge l'appareil etait tenu EVEILLE par un
#     inhibiteur — ZERO veille pendant 12 minutes a chaque fois — et la capacite a
#     bouge quand meme : 96 -> 95 -> 94 -> 93, puis 78 -> 77 -> 76 -> 75 -> 74 -> 73.
#     ➜ LA JAUGE NE DEPEND PLUS DE LA VEILLE. La protection protegeait contre un
#       danger qui n'existe plus. Meme motif que le « SoC SDAM 0x47 » du TODO n°13,
#       reclame par un texte que les patches suivants avaient rendu caduc.
#
#  ⚖️ CE QUI RESTE COMME RISQUE, nomme et assume : si quelqu'un met le delai a 0 ou
#     l'action a « ne rien faire », le telephone ne dormira plus et se videra plus
#     vite. C'est VISIBLE, c'est un choix, et ca se defait d'un curseur — plus une
#     corruption silencieuse de la jauge comme en 02/08.
#  ⛔ Ce qui reste INTERDIT de figer : Dim/TurnOffDisplay*. Voir le 06/08 plus haut —
#     sans extinction d'ecran, la veille tombe sans prevenir sous les yeux du
#     proprietaire. Ces cles doivent rester libres ET a true.
#
# ═══════════════════════════════════════════════════════════════════════════════
#  ⚠️ 06/08 — POURQUOI RACCOURCIR CE DELAI COUTE, mesure le jour meme
# ═══════════════════════════════════════════════════════════════════════════════
#  ☠️ D'ABORD : LA VEILLE N'A JAMAIS ETE CASSEE. Mesure du 06/08 — 12 veilles sur un
#  boot de 5 h 51, 74 % du temps endormi, dont 8 h 42 d'un bloc la nuit du 05 au 06.
#  Le 60 s avait ete demande pour PROVOQUER une veille qu'on croyait absente ; le
#  diagnostic etait faux (j'avais lu des durees en horloge MONOTONE, qui s'arrete
#  pendant la veille — voir TODO n°13). Il n'y avait rien a reparer ici.
#
#  Et chaque cycle supplementaire a un cout mesure :
#   ① le Wi-Fi est integralement demonte (`deauthenticating … Reason: 3=DEAUTH_LEAVING`)
#     et refait au reveil — WoWLAN n'est demande par personne alors que le
#     micrologiciel l'annonce (`features wowlan,…` dans le journal ath10k).
#   ② i2c_qcom_cci echoue a rallumer `cam_cc_camnoc_axi_clk` a CHAQUE reveil
#     (`Failed to enable clk 'camnoc_axi': -16`, 48 fois sur ce boot).
#   ③ ☠️ et surtout : sur les longues veilles, le MODEM peut partir en erreur fatale
#     au reveil (`remoteproc0: crash detected in modem`), ce qui emporte le WCN3990 —
#     il vit dans le DSP modem. ath10k rebondit 4 fois puis rend les armes :
#     « consecutive fail 4 times, will shutdown driver! ». Wi-Fi mort jusqu'au REBOOT.
#  ➜ Si le Wi-Fi se met a mourir plus souvent qu'avant, c'est ICI qu'il faut revenir :
#    repasser a 180 s coute une minute d'autonomie et divise les cycles par trois.
