Yo llevo una semana tratando de resolver por qué chingados el Xorg se muere cada vez que mi laptop se despierta de la suspensión. Lo absurdo es que ocurre sólo cuando la suspensión se inicia al cerrar la tapa, pero si inicio la suspensión manualmente no. Hasta el momento mi mejor solución ha sido mapear una combinación de teclas para que haga un xrandr --auto y con eso se levanta el servidor gráfico, pero pues no es una solución real. Anyway, de todos modos me sigue siendo preferible a seguir con el Windows y sus mememces de Copilot y demás.
Si te refieres a los estados S, según yo sí son los mismos. En el gestor de energía de XFCE (uso Debian 12) tengo configurado que al cerrar la tapa se suspenda el sistema. En el logind.conf tengo las líneas relevantes comentadas (aunque también lo he configurado al revés, quitando lo del gestor y dejando sólo el logind). Mis particiones son LVM cifradas, por lo que tengo la hibernación desactivada, así que en teoría el sistema no está entrando ni a S4 (hibernación) ni a suspensión híbrida. Si uso systemctl suspend el sistema se suspende sin problema aparente y al reactivarlo puedo desbloquearlo correctamente. Si cierro la tapa, espero unos momentos y la abro, el sistema comienza a reactivarse y el Lightdm se muestra bien, pero al momento de poner mi contraseña y dar enter la pantalla se pone en negro y ni siquiera el cursor se ve. El sistema no se bloquea, porque puedo pasar a otra TTY, e incluso puedo reiniciar el Lightdm (aunque pierdo todo lo que tenga abierto, claro). Y como digo, lo mejor que he podido hacer es configurar un atajo para el xrandr --auto, con lo que puedo regresar al escritorio. He visto que a muchas otras personas les ha ocurrido, pero no he encontrado alguna explicación satisfactoria, ni parece haber información útil en el Xorg.log ni en el journalctl (o eso creo). Otra línea de acción que se me ocurre es que tenga que ver con el vídeo (mi laptop tiene graficas híbridas) y el Nvidia Optimus, pero no he tenido tiempo de explorar esa posibilidad.
Yo llevo una semana tratando de resolver por qué chingados el Xorg se muere cada vez que mi laptop se despierta de la suspensión. Lo absurdo es que ocurre sólo cuando la suspensión se inicia al cerrar la tapa, pero si inicio la suspensión manualmente no. Hasta el momento mi mejor solución ha sido mapear una combinación de teclas para que haga un
xrandr --autoy con eso se levanta el servidor gráfico, pero pues no es una solución real. Anyway, de todos modos me sigue siendo preferible a seguir con el Windows y sus mememces de Copilot y demás.Ya checaste si la suspensión iniciada por tapa tiene otro estado diferente al de la manual?
Si te refieres a los estados S, según yo sí son los mismos. En el gestor de energía de XFCE (uso Debian 12) tengo configurado que al cerrar la tapa se suspenda el sistema. En el
logind.conftengo las líneas relevantes comentadas (aunque también lo he configurado al revés, quitando lo del gestor y dejando sólo el logind). Mis particiones son LVM cifradas, por lo que tengo la hibernación desactivada, así que en teoría el sistema no está entrando ni a S4 (hibernación) ni a suspensión híbrida. Si usosystemctl suspendel sistema se suspende sin problema aparente y al reactivarlo puedo desbloquearlo correctamente. Si cierro la tapa, espero unos momentos y la abro, el sistema comienza a reactivarse y el Lightdm se muestra bien, pero al momento de poner mi contraseña y dar enter la pantalla se pone en negro y ni siquiera el cursor se ve. El sistema no se bloquea, porque puedo pasar a otra TTY, e incluso puedo reiniciar el Lightdm (aunque pierdo todo lo que tenga abierto, claro). Y como digo, lo mejor que he podido hacer es configurar un atajo para elxrandr --auto, con lo que puedo regresar al escritorio. He visto que a muchas otras personas les ha ocurrido, pero no he encontrado alguna explicación satisfactoria, ni parece haber información útil en el Xorg.log ni en eljournalctl(o eso creo). Otra línea de acción que se me ocurre es que tenga que ver con el vídeo (mi laptop tiene graficas híbridas) y el Nvidia Optimus, pero no he tenido tiempo de explorar esa posibilidad.