To save power, I have power settings setup to sleep my system after a few minutes, and to suspend on power button or lid close.
If I suspend the computer and bring it out of suspend, the screen comes back fine to the Ubuntu lock screen.
However, if the system goes to sleep because I walk away for a few minutes, or I hit Super+L to lock the screen manually, then I can’t get the screen to come back on by either moving the mouse, clicking the mouse button, or tapping a key on the keyboard as I would expect.
The one work-around I’ve found is that if I switch away from first virtual terminal, where wayland/gnome is running, to a text VT (usually with ctrl+alt+F3) and then back again, the display will be restored.
I’m not sure what logs might be helpful, but if someone can specify, I’m happy to provide logs.
System: Lenovo LOQ 15IAX9E
GPU: Hybrid Intel UHD for normal desktop + nVidia RTX 4050(with proprietary drivers installed by Ubuntu installer) for 3D.
Are you thinking it’s like something where the power settings blank/poweroff the screen before the screensaver timer would activate the screensaver? Or something along those lines?
I’m not clear what I might look for in the output of gsettings.
I ran “gsettings list-recursively | less” and there are a LOT of settings, so it’s a bit of a needle in the haytack problem. I guess I’ll focus on screensaver related settings to see if I can, I don’t know, disable the screensaver? Since it never really gets a chance to run because the screen gets shut off.
I raised the issue of Screensaver, because I didn’t know how long you walked away before coming back, as opposed to when you specifically chose Suspend.
If the Screensaver was triggered, maybe the Screensaver logic is “messing” with the recognized state of the display as determined by the “Sleep/Suspend/Hibernate” for following Resume actions.
Just to throw my own experience with a similar issue in the mix, I had very long delays upon wake-up from suspend with an AMD iGPU because of some driver issue.
journalctl -p warning --since=<time of suspend>
should show any warning after the system entered suspend mode. To get the timestamp, you can use journalctl -en2 -u sleep.target and copy the first timestamp of the two-line output.
Well, unfortunately the log didn’t find any results for sleep.target.
However, it seems the issue is related to the refresh rate. I had it set to variable rate in the range 48-89.93. I turned off variable rate and played with the different refresh rates, and the only time it seems to happen is either with the variable rate, OR if I used 89.93 as the fixed rate.
I don’t know how much value there is in variable refresh rate - I thought it might help save a little power usage, if the display can drop down to a lower rate when it’s not doing much, but then go up to a higher rate, e.g. during gaming, etc.
Still, I wonder, who would I even report this to? Gnome? LKML? Intel?
This screenshot shows the available rates. I tested all of them, and only 89.93 had the issue. Additionally, I switched variable rate back on, but limited it to 60hz as the top of the range, and it’s working fine.
I don’t understand the specific workings, but I will “theorize” what is happening.
The “good” freq is set at boot.
That information is saved somewhere for the suspend/restore.
The system is then suspended, and power “management” kicks in, triggering various harwared builtin responses (downgrade of display freq ???).
Then the system is the restored, but the system’s awareness of the hardware state is now out of sync with the actual monitor’s state, mismatched frequency.
System up with problematic state! Since it relates to video, you have no way to intervene software-wise, unless you happen to have a secondary independant terminal logged into the system.
Wait, what did you try? If you suspend the system, then journalctl -en2 -u sleep.targetdoes have entries, because it gets pulled in by {suspend,hibernate,hybrid-sleep}.target – two lines to be exact, because that’s what -en2 does. But those are only to get the timestamp to then use as --since= parameter; you’re not looking for warnings or errors insleep.target but for any entries that were logged after reaching it.
I hit Super+L which locks the screen and immediately blanks it, shutting off the display. I thought that put the laptop to sleep, too, but perhaps not right away? Maybe it shuts off the display without immediately going to sleep?
I then wait a few seconds and either jiggle the mouse or tap a key (usually shift on the keyboard because shift by itself doesn’t cause any “action” but does get detected and wake the screen usually, except for when I have the display frequency set to the “bad” value of 89.93.
