4

Since around the middle of October 2020, my Arch Linux machines don't wake up the monitor anymore when I press any key in the Gnome login screen. However the machine itself is woken up, as I see my keypresses as password entries or am even locked if I press enter due to too many login attempts once I wake the monitor up by switching to another console via CTRL+ALT+Fx and back.

What has changed and how can I restore the original functionality?

Konrad Höffner
  • 996
  • 1
  • 16
  • 26
  • Same thing happened to me on Debian. I have xfce and had to change the settings for `xfce power manager`. Under settings, `Display`, turn off `Display Power Management`. The tooltip says "Let the power manager handle display power management (DPMS) instead of X11". – Eduardo Trápani Nov 12 '20 at 14:43

2 Answers2

4

I struggled with a similar problem on a desktop PC with Gnome 3.38 on Wayland for quite some time, the solution was to change the setting "IgnoreLid" to "true" in /etc/UPower/UPower.conf. Desktop PCs don't have a lid, so I think (at least in some cases) the Kernel reports garbage instead of reporting the lid as always open.

EDIT: I was too hasty to declare this as solved. Nope: in half of the cases, especially when sending the PC to suspend right after boot up, the monitor was still going to sleep after waking up for several seconds because of no video signal present.

Anyway, I've spend almost two days trying to find a clean solution, tried playing with DPMS and ACPI, but finally ended up with the following crude workaround: I've installed the ydotool and created a systemd service file /etc/systemd/system/resume_gnome_workaround.service with the following contents:

[Unit]
Description=Workaround for the monitor wakeup problem in Gnome 3.38
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

[Service]
Type=exec
ExecStartPre=sleep 1
ExecStart=ydotool mousemove 10000 10000

[Install]
WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

Then I enabled it with systemctl enable resume_gnome_workaround.service. It simply simulates a mouse movement one second after going from suspend. At least it works for me in 100% of the cases.

Efenstor
  • 41
  • 3
2

Nothing happens magically. Probably a software upgrade has introduced this weird behaviour. That's take a look to your pacman.log and try to downgrade inducted packages.

Instead, if you have changed any configuration option, try to login with a new user (this is the easier way to clean your $HOME/.config) to check if the issue still happens.

mattia.b89
  • 3,142
  • 2
  • 14
  • 39