Danneggiamento dello schermo dopo l'ibernazione: esiste un altro modo per aggiornare il display X11?

Quando ripristino da ibernazione lo schermo è spesso corrotto. Sospetto che la memoria grafica non venga salvata. In caso contrario, Suspend-to-ram funziona bene.

Sembra anche che la cache dei caratteri sia corrotta, poiché tutte le lettere sono corrotte in modo coerente. L'effetto sembra indirizzare un carattere a una dimensione specifica. Ad esempio, se viene colpita la finestra del mio terminale, la modifica del carattere e / o della dimensione del carattere lo risolverà, a meno che quel carattere con quella dimensione non sia già danneggiato.

Se il carattere viene utilizzato altrove (altre app, gestore di finestre, ecc.), Il problema è presente anche lì. A volte il carattere utilizzato per i titoli delle finestre viene colpito, quindi tutti i titoli delle finestre mostrano le stesse lettere danneggiate.

Disconnettersi e riconnettersi risolve il problema , ma non voglio farlo. Ho effettuato il logout e poi il letargo, ma questo è uno sforzo maggiore ed elimina gran parte del beneficio del letargo.

C'è un altro modo per aggiornare il display X11? Il Ctrl+ Alt+ F1... non significa risolve neanche. Cambia terminale ma non ridisegna nulla: mostra solo il vecchio schermo danneggiato.

Sto usando Debian 6.

In questa occasione il titolo della finestra è errato:

Contenuto del terminale non valido, ma il titolo è (ancora) corretto:

Ho avuto una situazione simile con il mio laptop. Lo schermo restava spesso nero quando si svegliava dalla sospensione. La mia soluzione era quella di utilizzare xrandrper ripristinare i miei display. Devi trovare il xrandrcomando che imposta il layout ed eseguirlo. Ad esempio, sul mio sistema, avevo due schermi e questo lo configurava come lo desideravo:

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

Se hai una sola schermata, puoi provare a spegnerla e riaccenderla:

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

Puoi vedere i nomi delle tue schermate eseguendo xrandrsenza argomenti. Sul sistema che sto usando ora (uno schermo VGA), ottengo:

$ 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)

Una volta trovato il comando giusto, assegnagli un collegamento in modo da poterlo eseguire anche quando lo schermo è vuoto.

Hai provato il xrefreshcomando?

In GNOME 3 , AltF2renteraggiorna la GUI. AltF2avvia il prompt dei comandi Esegui e il rcomando forza un aggiornamento.

Sto riscontrando anche questo problema (Debian Squeeze e Wheezy).

Nella mia esperienza, succede principalmente quando la maggior parte della memoria è piena e il sistema utilizza la memoria di swap.

Come soluzione parziale: se cambio i caratteri predefiniti, la corruzione scompare. (Non per sempre, devo cambiare di nuovo quando ricompare la corruzione.)

(Su Debian Wheezy questo viene fatto da gnome-tweak-tool.)

Aggiornamento al kernel 3.19. - Ho usato i pacchetti del kernel mainline di Ubuntu , che possono essere trovati qui:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-vivid/ (funziona anche su Ubuntu 14.04 fidato)

Il seguente commento di segnalazione bug lo menzionava

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

... e rintracciato il commit con il seguente messaggio:

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

"... da quando l'abbiamo visto solo su gm45 e i965gm."

Ho quel chipset mobile Intel GM45 con grafica integrata. Anche il laptop Acer dell'OP è stato venduto con quel chipset (non tutti però).

(Non aveva nulla a che fare con la sospensione.)

Se un driver non riesce a riprendere correttamente un dispositivo, credo che l'unica soluzione che troverai sarà il debug e l'identificazione di dove si trova il problema in modo da poter decidere cosa fare da lì. Ad esempio, non vedo come è possibile aggiornare se la scheda video non viene reinizializzata.

ACPI gestisce la sospensione / ripresa e la visualizzazione. Ad esempio, il seguente problema ACPI che si verifica su alcuni ThinkPad può risolvere i sintomi che stai descrivendo:

Quando si riprende da suspend-to-ram, i display della console di testo potrebbero mostrare immondizia anziché testo effettivo. In caso contrario, la macchina è ancora reattiva e X viene visualizzato correttamente. Se tutto ciò è vero, l'aggiunta dell'opzione kernel acpi_sleep = s3_bios, s3_mode nel menu.lst o lilo.conf potrebbe risolvere il problema.

Problemi con ACPI suspend-to-ram - ThinkWiki

Se stai utilizzando il thinkpad_acpimodulo a cui si rivolge la citazione sopra, potrebbe essere tutto ciò di cui hai bisogno. Per ulteriori informazioni su questa soluzione, consultare Suspend2Ram - Documentazione Powersave

Innanzitutto, ci sono diversi parametri del kernel che possono essere provati. Aggiungili al tuo "kernel" -line in /boot/grub/menu.lst . Maggiori informazioni su questi sono disponibili in /usr/src/linux/Documentation/power/video.txt .

Da video.txt:

Durante il ripristino di S3, è necessario reinizializzare l'hardware. Per la maggior parte dei dispositivi, questo è semplice e il driver del kernel sa come farlo. Sfortunatamente c'è un'eccezione: la scheda video. Questi sono generalmente inizializzati dal BIOS e il kernel non ha abbastanza informazioni per l'avvio della scheda video. (Il kernel di solito non contiene nemmeno il driver della scheda video: vesafb e vgacon sono ampiamente utilizzati).

Altro su video.txt Fare riferimento alla tabella qui per vedere se un noto acpi_sleep=<hack>è elencato per il modello della scheda video.

Debian Suspend e KMS Il wiki di Debian suggerisce di disabilitare KMS per un problema di "video danneggiato al riavvio". 1

Un problema molto comune riscontrato dopo il riavvio del computer è il video danneggiato (o schermo nero o nessuna retroilluminazione LCD). Il primo passo è verificare se il sistema è ancora in esecuzione, cosa che può essere fatta semplicemente premendo il pulsante Capslock e controllare se il LED Capslock sta cambiando di conseguenza. Se il sistema è ancora in esecuzione, nella maggior parte dei casi è necessario aggiungere una stranezza video per la scheda video.

Debian ora ha l'impostazione della modalità kernel (KMS) abilitata di default per la maggior parte delle schede video Intel, nVidia e ATI. Ma la stranezza video di pm-utils [non] supporta ancora KMS. Quindi nella maggior parte dei casi dovresti provare prima a disabilitare KMS. I passaggi dettagliati per la tua scheda video specifica sono disponibili nella pagina KernelModesetting.

Dopo aver disabilitato KMS, se il video dopo il ripristino continua a corrompersi, puoi provare a sospendere il sistema utilizzando alcune stranezze video. Leggi la manpage del programma pm-suspend per una spiegazione molto dettagliata di tutte le stranezze disponibili e prova le loro combinazioni dalla riga di comando. Se trovi correttamente una combinazione di stranezze che funziona per il tuo sistema, puoi aggiungerle in / usr / lib / pm-utils / video-quirks per renderle permanenti. Allo stesso tempo, ti preghiamo di aiutare a presentare un bug sul pacchetto pm-utils con una patch sulle tue modifiche in modo che possa essere utile alla massa.

Un problema comune riscontrato nell'aggiornamento dei sistemi dalle vecchie versioni di Debian è l'abilitazione di quirk-s3-bios che blocca il sistema durante la sospensione. Se il sistema si blocca durante la sospensione, controllare attentamente pm-suspend.log dopo aver abilitato il debug e assicurarsi che quirk-s3-bios non venga utilizzato.

Se ritieni che ciò sia correlato al tuo problema, puoi provare a disabilitare KMS come suggerito. Per istruzioni sulla tua carta, vedi KernelModesetting - Debian Wiki

Sospensione del debug

Il registro dei processi di sospensione e ripresa si trova nel file /var/log/pm-suspend.log. Contiene informazioni moderatamente dettagliate per impostazione predefinita. Ulteriori informazioni possono essere abilitate per il debug inserendo la riga export PM_DEBUG = true all'inizio delle funzioni file / usr / lib / pm-utils / pm- .

Per di più, controlla anche le informazioni sulla funzione di test del kernel menzionata su Suspend - Debian Wiki . Questo può aiutarti a eseguire il debug e isolare il problema.

Alcuni esempi e informazioni di debug più approfondite che potrebbero aiutarti a "driver che non riescono a sospendere o riprendere i loro dispositivi" sono disponibili su https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt

Altre idee di debug per pm-utilsat -pms - ArchWiki e /unix//a/29090/87728

Ecco un elenco completo dei parametri del kernel, molti dei quali sono rilevanti per acpi e suspend.

In bocca al lupo.

Questo sembra essere un bug segnalato, controlla il link che segue.

In caso di Ubuntu controlla questo link

Nel caso di Debian leggi questo altro link specialmente il video Fixing corrotto sulla parte di ripresa

Nel caso in cui il problema si trovi in ​​una console di testo: hai provato ad aggiornare la cache dei caratteri?

fc-cache -f -v

Questo è quasi certamente perché il driver grafico ha dei bug per il dispositivo di visualizzazione. Probabilmente non importa molto quale sia, perché in entrambi i casi non è qualcosa che puoi probabilmente risolvere. Ma dovresti presentare un bug sul driver del kernel per il dispositivo (una volta che hai capito di cosa si tratta ( lspcipuò essere d'aiuto qui)).

Qualcosa che potresti provare, tuttavia, come soluzione: quando esci dal letargo, prova a premere "ctrl-alt-F4" per passare a un altro terminale virtuale e poi tornare indietro (che è probabilmente ctrl-alt-F1 o ctrl- alt-F7 o forse F8). Questo potrebbe fare abbastanza per un aggiornamento dello schermo da far ripristinare il display. Può essere.

Ctrl + Alt + F1 ... non funziona

Bene ... quindi prova a rilasciare sudo chvt 1, quindi torna alla Vty di Xorg usando Ctrl_Alt_Fn o sudo chvt N(dove N è di solito 7 o 8). Nel caso in cui chvtfunzionasse, puoi anche provare a copiarlo.

Prova a ruotare o capovolgere lo schermo con xrandr, ad esempio capovolto e poi tornare alla normalità. Questo potrebbe essere sufficiente per ridisegnarlo completamente.

Prova Crtlalt-allora Crtlalt+. Ciò cambia la risoluzione dello schermo avanti e indietro.