upower "Resuming" signal is not emitted or seen

[Antoine Martin]

On 17/03/14 13:51, Bastien Nocera wrote:
> 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.
Understood, but the old interface was more useful. And more importantly,
widely used and supported.
What is gained by removing backwards compatibility?
>> 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.
Just to be clear, I am only talking about the "Resuming" and
"Suspending" events, nothing else.
Support for the event namespace that almost every application out there
uses.
>> 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.
Maybe my choice of example didn't help.
This is what the logind home page says: " This is a tiny daemon that
manages user logins and seats in various ways."
And this is what bothers me: in order to be able to receive power
events, I need to run a login/seats deamon. Odd.

I understand why logind would consume power events, and even present
them under a different namespace to applications that care about logins
and seats, I just don't see why it then becomes the source for those
power events. *Power Events*
One layer is the authentication / display manager level, the other one
much much lower. Merging the two is a bit strange, and since it breaks
compatibility even more so.

Antoine