I recently changed from AMD to NVidia for graphics and since then my desktop session doesn’t survive suspend. When waking my machine up after suspending overnight, I get a flashing cursor in the top left. My solution is to switch to a text-based virtual console (CTRL+ALT+F2) and I restart lightdm using,
$ sudo systemctl restart lightdm.service
This means that I don’t need to reboot my system, but I clearly lose all my desktop session state.
I suspend my machine using the following i3 binding,
bindsym s exec --no-startup-id i3exit suspend, mode "default"
which worked fine for a couple of years with the AMD graphics card.
It’s definitely worth noting that if I suspend for a short amount of time (1 minute), the system and desktop session come out of suspend without problem. As a result, it’s hard to test different solutions.
Thanks for the reply. I might try using systemctl suspend instead of the existing method I’m using to suspend and see if that makes a difference.
This part of the linked article would seem to be closes to what I’m experiencing,
Sometimes the screen goes black due to device initialization from within the initramfs. Removing any modules you might have in Mkinitcpio#MODULES and rebuilding the initramfs, can possibly solve this issue, specially graphics drivers for early KMS. Initializing such devices before resuming can cause inconsistencies that prevents the system resuming from hibernation. This does not affect resuming from RAM. Also, check the blog article best practices to debug suspend issues.
I’ve looked a bit deeper into how I’m normally suspending my machine. I call i3exit suspend, which is actually calling systemctl suspend behind the scenes. However, i3exit suspend also calls blurlock, which calls i3lock using a blurred screenshot of the desktop. So calling systemctl suspend on its own would be simpler.
I’m not able to replicate the problem directly, instead I seem to need to leave the machine suspended for some time (like overnight) to replicate. I’ve replaced i3exit suspend with systemctl suspend, i.e. removed the call to blurlock.
Failing that, I will try calling systemctl suspend after a fresh boot.
@bogdancovaciu Yes, you’re right - i3exit does lock before suspend and it calls systemctl suspend behind the scenes.
Last night, I
logged out of my i3 session
logged back in to a fresh i3 session
started a terminal (alacritty) and ran systemctl suspend, i.e. I didn’t use i3exit
This morning I was able to wake up from suspend back into my i3 session . Again I did have to unlock my screen, so something is implicitly locking my screen between running systemctl suspend and me waking my machine up 12hrs later.
Obviously, the goal is to be able to call i3exit suspend in the middle of an i3 session and then be able to wake the machine up some time later an recover that same i3 session. Any tips on what I should try next?