Bug 217772

Summary: notification of system resume after suspends
Product: [Unmaintained] solid Reporter: Anders Lund <anderslund>
Component: powermanagement-daemonAssignee: Dario Freddi <drf>
Status: RESOLVED UNMAINTAINED    
Severity: wishlist CC: djarvie, oliver.henshaw
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Anders Lund 2009-12-07 22:04:14 UTC
Version:           ukendt (using 4.3.4 (KDE 4.3.4), Chakra KDE)
Compiler:          gcc
OS:                Linux (x86_64) release 2.6.31-ARCH

I think KDE needs a dbus signal that notifies interrested parties about system resume after suspend or hibernate.

Obvious users are plasmoids that updates in time intervals, such as clocks, scripted images etc. I know that kalarm is also a likely user.
Comment 1 Dario Freddi 2010-11-09 17:22:20 UTC
It is now implemented in 4.6 - will blog soon about it.
Comment 2 Anders Lund 2010-11-09 20:32:53 UTC
You are my hero of the week!
Now, plasmoid and application developers, go use it!
Comment 3 Dario Freddi 2010-11-11 17:41:21 UTC
Adding blog link as requested by David: http://drfav.wordpress.com/2010/11/10/updates-from-kde-power-management-land-for-users-and-developers/
Comment 4 David Jarvie 2010-11-12 15:36:46 UTC
This will be really useful. But your blog says that it's only available with the upower backend. In that case, applications need to be able to find out whether the signal is actually available on the system - is that currently possible? KAlarm for one won't actually be able to use the signal unless it can know that it is definitely available.
Comment 5 Dario Freddi 2010-11-12 16:04:27 UTC
(First of all: it will work on upower only because HAL does not support that)

Btw, I will soon add a method backend() on the DBus interface, so that you can check whether the backend will be "upower" or "HAL". Will CCBUG this bug when I'll do that.

P.S.: It is very unlikely that, on Linux, somebody will use HAL only with KDE 4.6.
Comment 6 David Jarvie 2010-11-12 22:14:26 UTC
Wouldn't it be better to provide a generalised function to query which features are available from the current backend? The benefits of this would be

1) Applications wouldn't need to know which backends provide which features.

2) Applications wouldn't have to be changed every time a new backend is implemented.

3) If a backend changes its feature set, there won't be the problem of applications having to know not only which backends provide which features, but also which versions of each backend provides which features.
Comment 7 David Jarvie 2011-05-13 13:26:18 UTC
Is there any progress on providing a way to discover programmatically whether the resume from suspend signal is available? I'd really like KAlarm to use the signal when available, but that still isn't an option without a discovery method. If the signal doesn't appear after a resume, KAlarm is likely to miss triggering alarms, and that's too important to take a chance on even if it will work on most systems.

Because the signal will only be usable for KAlarm when it can be 100% relied on, I'm reopening the issue.
Comment 8 Oliver Henshaw 2013-04-10 11:27:24 UTC
org.kde.Solid.PowerManagement.backendCapabilities was added by kde-workspace commit 715885499f15af5644ae7eff1232ceb219bf7d22 for 4.6

Is this good enough? I'm not sure why this wasn't mentioned here - maybe it was an oversight or maybe this isn't enough by itself. It certainly looks like it should meet your needs though.
Comment 9 Andrew Crouthamel 2018-09-04 15:43:35 UTC
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I am closing this bug. Please try again with the latest version and submit a new bug to frameworks-solid if your issue persists. Thank you!