# Versions de Debian et le yoyo des mises en veille de l'écran

**URL:** <https://www.debian-fr.org/t/versions-de-debian-et-le-yoyo-des-mises-en-veille-de-lecran/88491>\
**Category:** Support Debian\
**Created:** [Juillet 7, 2023, 1:08 UTC](https://www.debian-fr.org/t/versions-de-debian-et-le-yoyo-des-mises-en-veille-de-lecran/88491 "2023-07-07T13:08:16Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\
**Post date:** [Juillet 7, 2023, 1:08 UTC](https://www.debian-fr.org/t/versions-de-debian-et-le-yoyo-des-mises-en-veille-de-lecran/88491/1 "2023-07-07T13:08:16Z")

</div>

je regrette vraiment de ne pas pouvoir comprendre le fonctionnement de la partie **gestion de l’alimentation** d’un noyau car elle est tout sauf continue d’une version à l’autre . J’ai commencé à utiliser Debian comme unique S.E de mon portable à partir de Debian 9 : tout fonctionnait sans aucun souci . Idem pour Debian 10 . Les ratés ont commencé avec Debian 11 :

- blocage aléatoire du clavier que j’ai contourné grâce à l’utilisation d’un noyau de la série 6.xx ( rétroporté )

- impossibilité de changer d’utilisateur même avec 6.xx

Comme **dmesg -l err / warn** ne liste rien d’inquiétant je vais rester avec ce noyau pas encore estampillé «&nbsp;rétroporté&nbsp;» mais qui devrait le devenir .

ps : pourtant mon pilote graphique n’a rien d’un truc exotique puisqu’il s’agit de **i915**.

```nohighlight
~# inxi -Gx
Graphics:
  Device-1: Intel GeminiLake [UHD Graphics 605] vendor: CLEVO/KAPOK driver: i915
    v: kernel arch: Gen-9 bus-ID: 00:02.0
  Device-2: Chicony USB2.0 Camera type: USB driver: uvcvideo bus-ID: 1-6:3
  Display: x11 server: X.org v: 1.21.1.7 driver: X: loaded: modesetting
    unloaded: fbdev,vesa dri: iris gpu: i915 tty: 85x25 resolution: 1920x1080
  API: OpenGL Message: GL data unavailable in console for root.

```

---

<div class="post-metadata">

**Author:** ![PmGs](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/dfb087/32.png) [@PmGs](https://www.debian-fr.org/u/PmGs)\
**Post date:** [Juillet 8, 2023, 6:21 UTC](https://www.debian-fr.org/t/versions-de-debian-et-le-yoyo-des-mises-en-veille-de-lecran/88491/2 "2023-07-08T06:21:48Z")

</div>

Hello @zao

Je n’ai pas vraiment d’idée comme cela, mais des problèmes «&nbsp;similaires&nbsp;» j’en ai déjà rencontré, pas nécessairement toujours (bien) résolus mais je n’ai pas souvenir avoir changé le noyau pour cette raison. Concernant les blocages «&nbsp;aléatoires&nbsp;» clavier, soit ils étaient causés par une charge très importante de la machine soit suffisant peu fréquent pour que je me satisfasse d’un reboot sans plus d’analyse.

Es-tu vraiment sûr que c’est la bonne piste? A défaut je commencerais par remettre le noyau conforme à la distribution et à mettre les outils des outils de surveillance en remote à partir d’une autre machine.

---

<div class="post-metadata">

**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\
**Post date:** [Juillet 8, 2023, 6:44 UTC](https://www.debian-fr.org/t/versions-de-debian-et-le-yoyo-des-mises-en-veille-de-lecran/88491/3 "2023-07-08T06:44:34Z")

</div>

bonjour ,

les blocages du clavier sont nettement plus ennuyeux que les écrans noirs d’une mise en veille de l’écran car ils obligent à redémarrer le portable à partir du bouton M/A . Leur fréquence m’a conduit , avec Debian 11 , à utiliser un noyau rétroporté et c’est la raison pour laquelle je suis passé à debian 12 = les noyaux 6.1xx devenaient stables . Je n’avais tout simplement pas prévu qu’ils auraient un effet secondaire car avec Debian 11 ils n’en avaient aucun : on entre dans les mytères de l’informatique ( pour moi en tout cas ) .

Mais je pense que tu as raison sur " le noyau conforme à la distribution " , politique que j’avais adoptée en installant Debian 12 . Je vais simplement revenir à la situation précédente = désactivation de la gestion de l’alimentation de l’écran et mise en position N°1 ( dans le menu de Grub ) du noyau stable 6.1xx en attendant que 6.3xx apparaisse dans **bookworm-backports** car il aura alors été testé et aura été déclaré «&nbsp;apte&nbsp;» à fonctionner avec Debian 12 ( me trompe-je ? ) .

merci pour la réponse .

note : **à mettre les outils des outils de surveillance en remote à partir d’une autre machine.** je vais essayer de décrypter ça pour voir si je peux en tirer quelque chose .

---

<div class="post-metadata">

**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\
**Post date:** [Juillet 10, 2023, 12:58 UTC](https://www.debian-fr.org/t/versions-de-debian-et-le-yoyo-des-mises-en-veille-de-lecran/88491/4 "2023-07-10T12:58:27Z")

</div>

j’ai finalement trouvé un contournement pour simuler une mise en veille de l’écran ( pas pour l’éteindre ) , je mets la méthode utilisée des fois que ça donne des idées :

- soit pour avoir une appréciation quant à sa validité et à ses possibles effets secondaires
- soit pour proposer une amélioration
- soit à qq’un de pas plus avancé que moi et qui chercherait une solution à un problème similaire tout en utilisant _Xfce_

```nohighlight
:~$ xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/brightness-level-on-ac -t int -s 0 --create

:~$ xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/brightness-on-ac -t int -s 180 --create

:~$ xfconf-query -c xfce4-power-manager -lv
/xfce4-power-manager/blank-on-ac 0
/xfce4-power-manager/blank-on-battery 0
/xfce4-power-manager/brightness-level-on-ac 0
/xfce4-power-manager/brightness-level-on-battery 6
/xfce4-power-manager/brightness-on-ac 180

```

ps1 : je me suis servi de commandes trouvées sur le forum [Xfce](https://forum.xfce.org/viewtopic.php?id=16686) en les modifiant pour que les unités soient correctes .

ps 2 : si ça tient dans la durée je pourrais rester en 100% stable : plus besoin du rétroportage .

Même si ça ne constitue pas une vraie solution je vais quand même arrêter le chrono et mettre résolu .

**Edit 1** :

Soit l’informatique , soit moi-même , soit un composé en pourcentage non défini des deux , sont pleins d’imprévu . Peut-être que qq’un connaissant bien Xfce saura trouver une explication :

- après redémarrage ce matin la sortie de mise en veille de l’écran se faisait en 2 étapes , comme hier d’ailleurs alors que je n’avais pas testé le redémarrage , mais avec des durées et des % de brillance différents . Comme j’ai compris le pourquoi des % différents et réglé le problème reste le plus épineux
- juste après avoir réglé la durée avant mise en veille à 180 s , l’écran s’éteignait après 180 s montre en main , mais maintenant après le démarrage matinal et 3 autres redémarrages pour tester ça n’est plus la même chose :  
\*\* à 180 s l’écran tombe à 1% de luminosité ( nouvelle valeur que j’ai entrée à la place de 0% qui doit être une valeur interdite je suppose )  
\*\* à 240 s , soit une minute pile après le délai souhaité ( 180 s ) entré comme valeur de consigne , l’écran s’éteint totalement . Aucun problème pour le remettre en route .

voili voilà . La conclusion pourrait bien être que l’informatique , même très basique , et moi on n’est pas fait pour s’entendre . Malgré tout mon problème semble bien résolu , car 180 ou 240 quelle différence ? C’est juste agaçant .

ps : j’ai posé la question sur le forum Xfce , des spécialistes de cet environnement . Voyons .