Bug 35797 - Add sleep type information to Sleeping signal
Summary: Add sleep type information to Sleeping signal
Status: RESOLVED WONTFIX
Alias: None
Product: upower
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Richard Hughes
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-30 07:34 UTC by Michael Terry
Modified: 2013-10-12 22:52 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Adds signal arg (4.00 KB, patch)
2011-03-30 07:34 UTC, Michael Terry
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Terry 2011-03-30 07:34:48 UTC
Created attachment 45048 [details] [review]
Adds signal arg

In Ubuntu, we got a bug filed about how suspends initiated outside of gnome-power-manager were not locking the screen correctly.

This is because it handled locking as a result of internal methods, not as a response to the Sleeping signal from upower.  Ideally it would do that instead, but first, that signal needs to have enough information for a policy agent like gnome-power-manager to determine policy.

Which means it needs to tell listeners whether the sleep is a suspend or hibernate.

We received a patch for this by Phillip Susi (attached).  It simply adds an int argument to the signal.  Will existing dbus listeners be confused by the addition of a new argument?
Comment 1 Richard Hughes 2011-03-30 08:05:44 UTC
Yup, see http://lists.freedesktop.org/archives/devkit-devel/2011-March/001054.html

And yes, adding an argument will upset people.
Comment 2 Michael Terry 2011-03-30 08:12:38 UTC
Ah, sorry, searched bugs, but didn't think about the mailing list.

What about a second signal, named "SleepingFull" or something?
Comment 3 Richard Hughes 2011-03-30 10:14:13 UTC
SleepingFull might be best, I though perhaps Sleeping2, but both seem non-ideal. Got any better ideas?

Richard.
Comment 4 Michael Terry 2011-03-30 10:17:54 UTC
The only alternative to a second signal I can think of is a query method like GetCurrentSleepType(), but that's a whole 'nother round trip eating into the precious second before suspend (I don't know how much of a concern that is).
Comment 5 Michael Terry 2011-03-30 10:18:59 UTC
Oh, I think you meant naming ideas?  SleepingWithType?
Comment 6 Richard Hughes 2011-03-30 10:24:53 UTC
(In reply to comment #4)
> The only alternative to a second signal I can think of is a query method like
> GetCurrentSleepType(), but that's a whole 'nother round trip eating into the
> precious second before suspend (I don't know how much of a concern that is).

Eek. RTT is probably too high for that. Even setting a property might be racy, I'm not sure. A PropertyChanged signal in GDBus is run in a new thread, and I'm not sure how it works when we're using the clunky dbus-glib.

At the moment I'm erring for ::SleepingKind and ::ResumingKind as we call things kinds internally (rather than type, which upsets glib sometimes).
Comment 7 Bastien Nocera 2013-10-12 22:52:43 UTC
The Sleeping signal is deprecated, and removed in my branch. We won't get a new signal.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.