Corrupción de pantalla después de hibernar: ¿hay alguna otra forma de actualizar la pantalla X11?

Cuando restauro de hibernar, la pantalla a menudo está dañada. Sospecho que la memoria de gráficos no se está guardando. Suspender a ram funciona bien de lo contrario.

También parece que el caché de fuentes está dañado, ya que todas las letras están dañadas de manera consistente. El efecto parece apuntar a una fuente de un tamaño específico. Por ejemplo, si se golpea la ventana de mi terminal, cambiar la fuente y / o el tamaño de la fuente lo solucionará, a menos que esa fuente con ese tamaño ya esté dañada.

Si la fuente se usa en otro lugar (otras aplicaciones, administrador de ventanas, etc.), entonces el problema también está ahí. A veces se golpea la fuente utilizada para los títulos de las ventanas, luego todos los títulos de las ventanas muestran las mismas letras corruptas.

Cerrar sesión y volver a iniciarla lo corrige , pero no quiero tener que hacer eso. He estado cerrando sesión y luego hibernando, pero esto es más esfuerzo y elimina la mayor parte del beneficio de hibernar.

¿Hay otra forma de actualizar la pantalla X11? El Ctrl+ Alt+ F1... tampoco lo arregla. Cambia de terminal pero no vuelve a dibujar nada: solo muestra la pantalla dañada antigua.

Estoy usando Debian 6.

En esta ocasión el título de la ventana es malo:

Contenido del terminal incorrecto, pero el título está (aún) bien:

Tuve una situación similar con mi computadora portátil. La pantalla a menudo permanecería negra cuando despertara de la suspensión. Mi solución fue usar xrandrpara restablecer mis pantallas. Necesita encontrar el xrandrcomando que configura su diseño y ejecutarlo. Por ejemplo, en mi sistema, tenía dos pantallas y esto lo configuró como lo quería:

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

Si solo tiene una sola pantalla, puede intentar apagarla y volverla a encender:

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

Puede ver los nombres de sus pantallas ejecutando xrandrsin argumentos. En el sistema que estoy usando ahora (una pantalla VGA), obtengo:

$ 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 vez que encuentre el comando correcto, asígnele un acceso directo para que pueda ejecutarlo incluso cuando la pantalla esté en blanco.

¿Intentaste el xrefreshcomando?

En GNOME 3 , AltF2renteractualiza la GUI. AltF2inicia el símbolo del sistema Ejecutar comando y el rcomando fuerza una actualización.

También tengo este problema (Debian Squeeze y Wheezy).

En mi experiencia, ocurre principalmente cuando la mayor parte de la memoria está llena y el sistema está utilizando la memoria de intercambio.

Como solución parcial: si cambio las fuentes predeterminadas, la corrupción desaparece. (Sin embargo, no para bien, tengo que cambiar de nuevo cuando reaparezca la corrupción).

(En Debian Wheezy, esto se hace mediante gnome-tweak-tool).

Actualice a Kernel 3.19. - Utilicé los paquetes del núcleo de Ubuntu mainline , que se pueden encontrar aquí:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-vivid/ (también se ejecuta en Ubuntu 14.04 de confianza)

El siguiente comentario de informe de error lo mencionó

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

... y rastreó la confirmación con el siguiente mensaje:

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

"... ya que solo hemos visto esto en gm45 e i965gm".

Tengo ese chipset móvil Intel GM45 con gráficos integrados. La computadora portátil Acer del OP también se vendió con ese chipset (aunque no todos).

(No tenía nada que ver con suspender).

Si un controlador no puede reanudar un dispositivo correctamente, creo que la única solución que encontrará será depurar e identificar dónde está el problema para que pueda decidir qué hacer desde allí. Por ejemplo, no veo cómo puede actualizar si la tarjeta de video no se reinicia.

ACPI maneja suspender / reanudar y mostrar. Por ejemplo, el siguiente problema de ACPI que ocurre en algunos ThinkPads puede abordar los síntomas que está describiendo:

Al reanudar desde suspender a ram, las pantallas de la consola de texto pueden mostrar basura en lugar de texto real. De lo contrario, la máquina aún responde y X se muestra bien. Si todo esto es cierto, entonces agregar la opción de kernel acpi_sleep = s3_bios, s3_mode en su menu.lst o lilo.conf puede resolver el problema.

Problemas con ACPI suspend-to-ram - ThinkWiki

Si está utilizando el thinkpad_acpimódulo al que se refiere la cita anterior, eso podría ser todo lo que necesita. Para obtener más información sobre esta solución, consulte Suspend2Ram - Documentación de Powersave

Primero, hay varios parámetros del núcleo que se pueden probar. Simplemente agréguelos a su línea "kernel" en /boot/grub/menu.lst . Se puede encontrar más información sobre estos en /usr/src/linux/Documentation/power/video.txt .

De video.txt:

Durante la reanudación de S3, el hardware debe reinicializarse. Para la mayoría de los dispositivos, esto es fácil, y el controlador del núcleo sabe cómo hacerlo. Lamentablemente, hay una excepción: la tarjeta de video. Por lo general, estos son inicializados por el BIOS, y el kernel no tiene suficiente información para iniciar la tarjeta de video. (Kernel generalmente ni siquiera contiene un controlador de tarjeta de video; vesafb y vgacon se usan ampliamente).

Más información en video.txt Consulte la tabla aquí para ver si hay un conocido acpi_sleep=<hack>para su modelo de tarjeta de video.

Debian Suspend y KMS La wiki de Debian sugiere desactivar KMS para un problema de "video corrupto en el currículum". 1

Un problema muy común que se encuentra después de que la computadora se reanuda es el video dañado (o la pantalla en negro, o sin luz de fondo de la pantalla LCD). El primer paso es verificar si el sistema aún se está ejecutando, lo que se puede hacer simplemente presionando el botón Capslock y verificar si el LED Capslock está cambiando en consecuencia. Si el sistema aún se está ejecutando, en la mayoría de los casos necesitamos agregar una peculiaridad de video para su tarjeta de video.

Debian ahora tiene la configuración de modo de kernel (KMS) habilitada por defecto para la mayoría de las tarjetas de video Intel, nVidia y ATI. Pero la peculiaridad de video de pm-utils [no] todavía admite KMS. Entonces, en la mayoría de los casos, primero debe intentar deshabilitar KMS. Los pasos detallados para su tarjeta de video específica se pueden encontrar en la página KernelModesetting.

Después de deshabilitar KMS, si el video después de la reanudación aún se corrompe, puede intentar suspender el sistema utilizando algunas peculiaridades de video. Lea la página de manual del programa pm-suspend para obtener una explicación muy detallada de todas las peculiaridades disponibles, y pruebe las combinaciones de ellas desde la línea de comandos. Si encuentra con éxito una combinación de peculiaridades que funcione para su sistema, puede agregarlas a / usr / lib / pm-utils / video-quirks para hacerlas permanentes. Al mismo tiempo, ayude a presentar un error en el paquete pm-utils con un parche sobre sus cambios para que pueda beneficiar a la masa.

Un problema común que se encuentra en la actualización de sistemas de versiones anteriores de Debian es la habilitación de quirk-s3-bios congela el sistema durante la suspensión. Si su sistema se congela durante la suspensión, revise cuidadosamente pm-suspend.log después de habilitar la depuración y asegúrese de que no se use quirk-s3-bios.

Si cree que esto está relacionado con su problema, puede intentar deshabilitar KMS como se sugiere. Para obtener instrucciones para su tarjeta, consulte KernelModesetting - Debian Wiki

Suspender depuración

El registro de los procesos de suspensión y reanudación se encuentra en el archivo /var/log/pm-suspend.log. Contiene información moderadamente detallada por defecto. Se puede habilitar más información para la depuración insertando la línea de exportación PM_DEBUG = true al comienzo del archivo / usr / lib / pm-utils / pm-functions .

Para obtener más información, consulte la información sobre las instalaciones de prueba de Kernel mencionadas en Suspend - Debian Wiki . Esto puede ayudarlo a depurar y aislar el problema.

Algunos ejemplos y más información de depuración en profundidad que puede ayudarlo a "controladores que no pueden suspender o reanudar sus dispositivos" está disponible en https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt, encontrará

Algunas ideas más para depurar pm-utilsen pm-utils - ArchWiki y /unix//a/29090/87728

Aquí hay una lista completa de los parámetros del kernel muchos de los cuales son relevantes para acpi y suspend.

Buena suerte.

Esto parece ser un error reportado, verifique el siguiente enlace.

En caso de verificación de Ubuntu este enlace

En el caso de Debian, lea este otro enlace, especialmente el video Corregido dañado en la parte de reanudar

En caso de que el problema esté en una consola de texto: ¿Has intentado actualizar la caché de fuentes?

fc-cache -f -v

Esto es casi seguro porque el controlador de gráficos tiene errores para el dispositivo de visualización. Probablemente no importará demasiado lo que es, porque de cualquier manera no es algo que probablemente pueda solucionar. Pero debe presentar un error sobre el controlador del kernel para el dispositivo (una vez que descubra qué es (lspci puede ayudar aquí)).

Sin embargo, hay algo que puede probar como solución: cuando salga de la hibernación, intente presionar "ctrl-alt-F4" para cambiar a otro terminal virtual y luego volver a cambiar (que probablemente sea ctrl-alt-F1 o ctrl- alt-F7 o tal vez F8). Esto puede hacer una actualización suficiente de la pantalla que hará que la pantalla se recupere. Tal vez.

Ctrl + Alt + F1 ... no funciona

Bueno ... entonces intente emitir sudo chvt 1, luego vuelva a vty de Xorg usando Ctrl_Alt_Fn o sudo chvt N(donde N suele ser 7 u 8). En caso de chvtque funcione, incluso puede intentar crear una secuencia de comandos.

Intente girar o voltear la pantalla xrandr, por ejemplo, al revés y luego volver a la normalidad. Esto podría ser suficiente para volver a dibujarlo completamente.

Intenta Crtlalt-entonces Crtlalt+. Eso cambia la resolución de la pantalla de un lado a otro.