Corruption d'écran après mise en veille prolongée - Existe-t-il un autre moyen de rafraîchir l'affichage du X11?

Lorsque je restaure de la mise en veille prolongée, l'écran est souvent corrompu. Je soupçonne que la mémoire graphique n'est pas enregistrée. Suspend-to-ram fonctionne bien sinon.

Il semble également que le cache de polices soit corrompu, car toutes les lettres sont corrompues de manière cohérente. L'effet semble cibler une police à une taille spécifique. Par exemple, si ma fenêtre de terminal est ouverte, la modification de la police et / ou de la taille de la police le corrigera, à moins que cette police de cette taille ne soit déjà endommagée.

Si la police est utilisée ailleurs (autres applications, gestionnaire de fenêtres, etc.), le problème est également là. Parfois, la police utilisée pour les titres des fenêtres est atteinte, puis tous les titres des fenêtres affichent les mêmes lettres corrompues.

Se déconnecter et se reconnecter le corrige , mais je ne veux pas avoir à le faire. Je me suis déconnecté puis j'ai hiberné, mais cela demande plus d'efforts et élimine la plupart des avantages de l'hibernation.

Existe-t-il un autre moyen de rafraîchir l'affichage du X11? Le Ctrl+ Alt+ F1… ne le corrige pas non plus. Il change de terminal mais ne redessine rien: il montre simplement l'ancien écran corrompu.

J'utilise Debian 6.

Dans cette occasion, le titre de la fenêtre est mauvais:

Le contenu du terminal est mauvais, mais le titre est (toujours) correct:

J'ai eu une situation similaire avec mon ordinateur portable. L'écran restait souvent noir lorsqu'il se réveillait de la suspension. Ma solution était d'utiliser xrandrpour réinitialiser mes écrans. Vous devez trouver la xrandrcommande qui configure votre mise en page et l'exécuter. Par exemple, sur mon système, j'avais deux écrans et cela l'a configuré comme je le voulais:

xrandr --output DP-3 --auto --output VGA-0 --auto --right-of DP-3 --primary

Si vous n'avez qu'un seul écran, vous pouvez essayer de l'éteindre et de le rallumer:

xrandr --output VGA-1 --off; xrandr --output VGA-1 --auto;

Vous pouvez voir les noms de vos écrans en exécutant xrandrsans arguments. Sur le système que j'utilise actuellement (un écran VGA), j'obtiens:

$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm
   1920x1080      60.0*+
   1680x1050      60.0  
   1280x1024      75.0     60.0  
   1152x864       75.0  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   640x480        75.0     60.0  
   720x400        70.1  
DVI-I-1 disconnected (normal left inverted right x axis y axis)

Une fois que vous avez trouvé la bonne commande, affectez-lui un raccourci afin de pouvoir l'exécuter même lorsque l'écran est vide.

Avez-vous essayé la xrefreshcommande?

Dans GNOME 3 , AltF2renteractualise l'interface graphique. AltF2lance l' invite Exécuter la commande et la rcommande force une actualisation.

J'ai aussi ce problème (Debian Squeeze et Wheezy).

D'après mon expérience, cela se produit principalement lorsque la majeure partie de la mémoire est pleine et que le système utilise la mémoire d'échange.

Comme solution de contournement partielle: si je change les polices par défaut, la corruption disparaît. (Pas pour de bon cependant, je dois changer à nouveau lorsque la corruption réapparaîtra.)

(Sur Debian Wheezy, cela se fait par gnome-tweak-tool.)

Mettre à niveau vers le noyau 3.19. - J'ai utilisé les paquets du noyau Ubuntu mainline , qui peuvent être trouvés ici:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-vivid/ (fonctionne également sur Ubuntu 14.04 trusty)

Le commentaire de rapport de bogue suivant l'a mentionné

https://bugs.freedesktop.org/show_bug.cgi?id=45092#c37

... et retrouvé la validation avec le message suivant:

https://github.com/torvalds/linux/commit/656bfa3afc14e45e2d9e1624bf60d79b3beb12f2

"... puisque nous n'avons vu cela que sur gm45 et i965gm."

J'ai ce chipset mobile Intel GM45 avec des graphiques intégrés. L'ordinateur portable Acer de l'OP a également été vendu avec ce chipset (mais pas tous).

(Cela n'avait rien à voir avec la suspension.)

Si un pilote ne parvient pas à reprendre correctement un périphérique, je pense que la seule solution que vous trouverez sera de déboguer et d'identifier où est le problème afin que vous puissiez décider quoi faire à partir de là. Par exemple, je ne vois pas comment vous pouvez actualiser si la carte vidéo n'est pas réinitialisée.

ACPI gère la suspension / reprise et l'affichage. Par exemple, le problème ACPI suivant qui se produit sur certains ThinkPad peut résoudre les symptômes que vous décrivez:

Lors de la reprise de la suspension au ram, les affichages de la console de texte peuvent afficher des déchets au lieu du texte réel. Sinon, la machine est toujours réactive et X s'affiche correctement. Si tout cela est vrai, l'ajout de l'option du noyau acpi_sleep = s3_bios, s3_mode dans votre menu.lst ou lilo.conf peut résoudre le problème.

Problèmes avec ACPI suspend-to-ram - ThinkWiki

Si vous utilisez le thinkpad_acpimodule que la citation ci-dessus adresse, cela pourrait être tout ce dont vous avez besoin. Pour plus d'informations sur cette solution, voir Suspend2Ram - Powersave Documentation

Tout d'abord, il existe plusieurs paramètres du noyau, qui peuvent être essayés. Ajoutez-les simplement à votre ligne "kernel" dans /boot/grub/menu.lst . Vous trouverez plus d'informations à ce sujet dans /usr/src/linux/Documentation/power/video.txt .

Depuis video.txt:

Lors de la reprise de S3, le matériel doit être réinitialisé. Pour la plupart des périphériques, c'est facile et le pilote du noyau sait comment le faire. Malheureusement, il existe une exception: la carte vidéo. Celles-ci sont généralement initialisées par le BIOS et le noyau n'a pas suffisamment d'informations pour démarrer la carte vidéo. (Le noyau ne contient généralement même pas de pilote de carte vidéo - vesafb et vgacon sont largement utilisés).

Plus sur video.txt Reportez-vous au tableau ici pour voir si un connu acpi_sleep=<hack>est répertorié pour votre modèle de carte vidéo.

Debian Suspend et KMS Le wiki Debian suggère de désactiver KMS pour un problème de "vidéo corrompue lors de la reprise". 1

Un problème très courant trouvé après la reprise de l'ordinateur est une vidéo corrompue (ou un écran noir ou aucun rétroéclairage LCD). La première étape consiste à vérifier si le système fonctionne toujours, ce qui peut être fait simplement en appuyant sur le bouton Capslock et vérifier si le voyant Capslock change en conséquence. Si le système fonctionne toujours, dans la plupart des cas, nous devons ajouter une bizarrerie vidéo pour votre carte vidéo.

Debian a désormais le paramètre de mode noyau (KMS) activé par défaut pour la plupart des cartes vidéo Intel, nVidia et ATI. Mais la bizarrerie vidéo de pm-utils ne prend pas encore en charge KMS. Donc, dans la plupart des cas, vous devez d'abord essayer de désactiver KMS. Les étapes détaillées de votre carte vidéo spécifique peuvent être trouvées sur la page KernelModesetting.

Après avoir désactivé KMS, si la vidéo après la reprise corrompt toujours, vous pouvez essayer de suspendre le système en utilisant des bizarreries vidéo. Lisez la page de manuel du programme pm-suspend pour une explication très détaillée de toutes les bizarreries disponibles, et essayez leurs combinaisons depuis la ligne de commande. Si vous trouvez avec succès une combinaison de bizarreries qui fonctionne pour votre système, vous pouvez les ajouter dans / usr / lib / pm-utils / video-quirks pour les rendre permanents. Dans le même temps, veuillez aider à déposer un bogue contre le paquet pm-utils avec un correctif sur vos modifications afin qu'il puisse bénéficier à la masse.

Un problème courant rencontré lors de la mise à niveau de systèmes à partir d'anciennes versions de Debian est l'activation de quirk-s3-bios gèle le système pendant la suspension. Si votre système se bloque pendant la suspension, vérifiez attentivement le pm-suspend.log après avoir activé le débogage et assurez-vous que quirk-s3-bios n'est pas utilisé.

Si vous pensez que cela est lié à votre problème, vous pouvez essayer de désactiver KMS comme suggéré. Pour les instructions pour votre carte, voir KernelModesetting - Debian Wiki

Débogage Suspendre

Le journal des processus de suspension et de reprise se trouve dans le fichier /var/log/pm-suspend.log. Il contient des informations modérément verbeuses par défaut. Plus d'informations peuvent être activées pour le débogage en insérant l' exportation de ligne PM_DEBUG = true au début du fichier / usr / lib / pm-utils / pm-functions .

Pour en savoir plus, consultez également les informations sur la fonction de test du noyau mentionnées dans Suspend - Debian Wiki . Cela peut vous aider à déboguer et à isoler le problème.

Quelques exemples et des informations de débogage plus approfondies qui peuvent vous aider «les pilotes qui ne parviennent pas à suspendre ou à reprendre leurs appareils» sont disponibles sur https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt

Quelques idées de débogage supplémentaires pour pm-utilsà pm-utils - ArchWiki et /unix//a/29090/87728

Voici une liste complète des paramètres du noyau dont beaucoup concernent l'acpi et la suspension.

Bonne chance.

Cela semble être un bug signalé, vérifiez le lien qui suit.

En cas d' Ubuntu, vérifiez ce lien

Dans le cas de Debian, lisez cet autre lien spécialement la correction de la vidéo corrompue sur la partie de reprise

Dans le cas où le problème se situe dans une console texte: avez-vous essayé d'actualiser le cache des polices?

fc-cache -f -v

C'est presque certainement parce que le pilote graphique a des bogues pour le périphérique d'affichage. Peu importe probablement ce que c'est, car de toute façon ce n'est pas quelque chose que vous pouvez probablement résoudre. Mais vous devez déposer un bogue sur le pilote du noyau pour le périphérique (une fois que vous avez compris de quoi il s'agit ( lspcipeut aider ici)).

Quelque chose que vous pourriez essayer, cependant, comme solution de contournement: lorsque vous sortez de la mise en veille prolongée, essayez d'appuyer sur "ctrl-alt-F4" pour basculer vers un autre terminal virtuel, puis de revenir en arrière (ce qui est probablement soit ctrl-alt-F1 ou ctrl- alt-F7 ou peut-être F8). Cela peut suffire à rafraîchir l'écran pour que l'affichage se rétablisse. Peut être.

Le Ctrl + Alt + F1… ne fonctionne pas

Eh bien… essayez ensuite d'émettre sudo chvt 1, puis revenez au vty de Xorg en utilisant Ctrl_Alt_Fn ou sudo chvt N(où N est généralement 7 ou 8). Dans le cas où chvtcela fonctionnerait, vous pouvez même essayer de l'écrire.

Essayez de faire pivoter ou de retourner votre écran avec xrandr, par exemple à l'envers, puis de revenir à la normale. Cela pourrait suffire à le refaire entièrement.

Essayez Crtlalt-alors Crtlalt+. Cela change la résolution d'écran d'avant en arrière.