Odd Suspend to RAM Behavior
At home on my laptop I seldom need or want to use suspend to RAM (sleep). When I do suspend there is a curious behavior with Xfce and Screensaver after I press
Fn to awaken the system.
The Xscreensaver unlock dialog appears. I provide a password. The display returns. After a few seconds the system suspends.
The second time I press
Fn there is no Xscreensaver unlock dialog. The system again has to restore the network connection.
Long ago I created an ACPI
sleep-button event triggers that launched the same script. Basically the script executes
pm-suspend. That all succeeded as intended and as time went by I forgot about the script and event triggers.
Back then I was using MATE but I was not using the MATE power manager. After being revamped for GTK3 I got frustrated with MATE because as far as I know there is no way to disable tool tips. I hate tool tips. Therefore I spent a few days getting reacquainted and tweaking with Xfce.
No more obnoxious tool tips.
I still keep MATE installed as a second desktop and for testing.
The peculiar wake behavior with Xfce was annoying. MATE did not do this, but I'd rather use Xfce because of those tool tips.
I disabled the ACPI event triggers. Xfce behaved normally on wake. With or without Xscreensaver.
Sounds great but MATE stopped suspending altogether. One step forward and one step back.
I discovered almost everything in the MATE power manager was configured to
Do nothing. I configured the MATE power manager. Thereafter both MATE and Xfce suspended and awakened correctly.
I enabled the ACPI event triggers. The problem returned.
I wrote the event triggers long ago when I was not interested in or using any desktop power managers. Undetected until I started using Xfce, the event triggers conflict with the Xfce power manager. That conflict did not exist with MATE power manager because I had most everything configured to
I don’t want to abandon the ACPI event triggers because I am not always in a desktop environment and still need a way to suspend to RAM.
I revised my trigger script to test whether X and any power managers are running. In that condition the event triggers do not execute
pm-suspend because the desktop power manager is presumed to be handling the events.
On reflection I could return to my previous ways and stop using desktop power managers. That is tempting because the laptop battery is old and useful only for a few minutes. I'm too lazy to buy a new battery. The laptop is always on wall current. I really don’t need “power management.”
For now everything is working as expected.