Bug 35797

Summary:	Add sleep type information to Sleeping signal
Product:	upower	Reporter:	Michael Terry <michael.terry>
Component:	general	Assignee:	Richard Hughes <richard>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
See Also:	https://launchpad.net/bugs/578542
Whiteboard:
i915 platform:		i915 features:
Attachments:	Adds signal arg

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.