-
Sub-task
-
Resolution: Fixed
-
Normal
-
None
-
None
-
None
Both me and krish are experiencing this issue with GNOME 3.36 on certain hardware. Krish is experiencing it on a Thinkpad t440p with Intel graphics, and I am experiencing it on a Thinkpad P1 with dedicated graphics (and this is only a problem when I use NVIDIA graphics. It works fine with Intel Iris when BIOS is in 'hybrid mode' which results in xrandr --listproviders showing only the modesetting provider but still shows the NVIDIA card in lspci.
Caveat – intel iris graphics will power save/resume flawlessly as long as I perform the following step:
1) blacklist nvidia drivers so they don't load when I am in BIOS 'hybrid' mode. /etc/modprobe.d/nvidia-blacklist.conf:
blacklist drm blacklist nouveau blacklist nvidia blacklist nvidia_modeset blacklist nvidia_drm
Back to the problem..
What we experience is that allowing GNOME to put the system to sleep results in a system that, when it comes out of sleep, does not re-activate the display.
A workaround is to use a script, sleep.sh, which will bypass the GNOME elogind/inhibitor logic and simply locks the screen and then hits the kernel sleep functionality directly:
#!/bin/bash
dbus-send --type=method_call --dest=org.gnome.ScreenSaver /org/gnome/ScreenSaver org.gnome.ScreenSaver.Lock
sleep 0.5
sudo sh -c 'echo -n mem > /sys/power/state'
This gets your screen locked using the official animation and then puts your system into sleep. When waking after using this script (which will also not hit the elogind/inhibitor logic), the system comes back just fine. This indicates that there is some issue related to powering on the screen when coming out of sleep in GNOME, in some circumstances. If we just use the kernel functionality, the kernel does all the right stuff.
For affected hardware, this bug seems to ALWAYS happen – it's not intermittent.