Bug 918

This was likely fixed with the transition to the TDE hardware library, which does not use HAL in favor of DBUS calls, in R14.0.0.  Can you confirm?

Thanks!

I'm afraid this might be still the case with preliminary stable builds for Debian Stretch.

Suspend/resume from Trinity does work, but evidently no pm scripts are being run.
At first I was sure that's somehow the systemd's fault (although I have just a shim installed), but /etc/pm/sleep.d scripts are being executed if I request sleep from KDE4 or call pm-suspend directly.

What is the current method for TDE to invoke suspend? Perhaps I might be able to trigger sleep scripts anyway by injecting something like

hooks=/etc/pm/sleep.d/*; for hook in $hooks; do bash $hook resume; done;

in the right place?

Can you try with the latest preliminary stable builds or R14.0.5 when released? Is the problem still happening?

I've gone through a few laptops since I reported this.

My current laptop is an MSI GE72MVR 7RG Apache Pro.
I voided the "Warranty sticker void if tampered" to open it up so I could swap out the HDD with an SSD.

I'm using
# Trinity preliminary stable builds
deb http://mirror.xcer.cz/trinity-sb/ stretch deps-r14 main-r14

Suspend to ram works.

I just tried hibernate and it came back to the desktop but the caps-lock and num-lock didn't respond and there was no mouse cursor.
After a couple of seconds the desktop crashed and returned me to the Trinity graphical login prompt.

I just noticed I've got updates from preliminary stable.
I'll install them, reboot and try hibernate/suspend-to-ram again.

When hibernate starts I hear a loud pop from the built-in speakers, even though I have earphones plugged in.
Hibernation is fast.
When resuming it takes 19 seconds from the time the desktop reappears for the mouse to appear.
Then, like before, the desktop crashes and I'm back to the Trinity login window.

Hi Philip,
thanks for testing and feedback. I have run into simialr issues sometimes, even using different distros that have nothing to do with TDE. In particular the loud bang from the speaker (even with headset in) after a desktop crash, terriibly loud :-(
I will keep the bug open and we will take a look for the R14.1.x series (although perhaps not for R14.1.0).

Yes, the problem is still there.

I believe there might be some misunderstooding. I believe the key problem isn't that the system won't suspend/hibernate. It does for me and other people.
But it doesn't go throught the pm-utils route at all. No pm scripts are being executed.

This is important, because said scripts can contain machine-specific
workarounds and convenience features (like reloading wifi module to
trigger immediate reconnect).
Also, some mission-critical tools put their own scripts that can
optionally inhibit sleep/hibernation if it's dangerous to do so.
For example, unattended-upgrades in Debian will deny sleep/hibernation
if it's in the middle of updating a package.

If sleep/hibernation is being performed through
pm-suspend/pm-hibernate, those script hooks are being correctly called.
If sleep/hibernation is being performed through kde4, those script
hooks are being correctly called.
If sleep/hibernation is being performed through tdepowersave, none of
the script hooks are executed.

Ok, thanks for the feedback Sergey. I will be in touch again when we look at this problem. It won't be very soon, though. This is currently planned for R14.1.x series, but not R14.1.0.

Glad to be of help.
Thanks for the attention to this issue.