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?
Yup, see http://lists.freedesktop.org/archives/devkit-devel/2011-March/001054.html And yes, adding an argument will upset people.
Ah, sorry, searched bugs, but didn't think about the mailing list. What about a second signal, named "SleepingFull" or something?
SleepingFull might be best, I though perhaps Sleeping2, but both seem non-ideal. Got any better ideas? Richard.
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).
Oh, I think you meant naming ideas? SleepingWithType?
(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).
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.