upower "Resuming" signal is not emitted or seen
Bastien Nocera
hadess at hadess.net
Sun Mar 16 23:51:54 PDT 2014
On Mon, 2014-03-17 at 12:03 +0700, Antoine Martin wrote:
> On 16/03/14 22:36, Antoine Martin wrote:
> > On 16/03/14 22:30, Michael Biebl wrote:
> >> 2014-03-16 15:54 GMT+01:00 Antoine Martin <antoine at nagafix.co.uk>:
> >>> On 16/03/14 21:28, Michael Biebl wrote:
> >>>
> >>> Newer upower versions no longer emit that signal since this handled by
> >>> systemd.
> >>>
> >>> OK, I hope there a new signal I can listen for?
> >> http://www.freedesktop.org/wiki/Software/systemd/logind/
> >>
> (snip)
> >>
> >> Does that help?
> > It does!
> > I had seen that page like a dozen times, but somehow missed the
> > "PrepareForSleep with argument False" everytime.
> For reference, I am attaching a sample script which fires when the
> system suspends or resumes.
>
> Are there any reasons not to keep backwards compatibility here?
> By that, I mean keeping both the old "upower Resuming" signal as well as
> the new "login1 PrepareForSleep" interface.
> For one, the old interface is much nicer, widely used, and uses more
> sensible and meaningful names for signals.
The old interface was also deprecated.
> But more importantly, I don't see why system power events would belong
> in the "login manager" at all. A login manager may use power events, it
> should not own them.
It's a better place than a service that doesn't handle suspend/resume.
> For instance, I could be running graphical applications on a systemd
> enabled system without necessarily having a login manager installed or
> running. And I would still expect to receive power event notification.
You always have logind running on a systemd enabled system, it's part of
systemd. I think you're confused about what logind is.
More information about the devkit-devel
mailing list