Affected doesn't necessarily have a negative connotation, it can just mean "it will change something in the subject".
It breaks the D-Bus API, and both the ABI and API of the libupower-glib helper library, so it has a negative influence. It adds badly needed features, so will have a positive influence as well :)
17 October 2013 at 18:55
Anonymous said...
Hi, I am facing a problem with the "HybridSleep"-thing in UPower, so I set it to "Hibernate" in UPower.conf, but after reloading the upower-systemd.unit I still get critical-action: HybridSleep from upower -d . So I had a look into your code and didn't find a trace where this Parameter is read.
And now I want to say why I don't want HybridSleep as default. My Thinkpad X1 cannot do resume from sleep aka standby anymore (some kind of hardware problem). HybridSleep would be the best option, if my hardware would still function correctly, but I am forced to use hibernate only. For now this issue is not critical because I do not loose any data in the process. I can still resume from hibernate even if the UPower has used HybridSleep after I switch off the notebook while in sleep manually.
And yes, I know, the method up_backend_take_action(...) calls logind to do the actual sleeping and hibernating.
Besides all of this, I have a pretty standard Gnome 3.12 desktop on Gentoo. I apologize for reporting this here instead in a bugzilla of yours, because I am not sure, if I missed something in your code which makes my statements invalid. Any hints are welcome.
André K: it probably doesn't use Hibernate because systemd says your system cannot hibernate. It then falls back to the next best thing, which is HybridSleep.
You can try something like that: gdbus call --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanHibernate
8 August 2014 at 15:54
Anonymous said...
Oh, I thought, it is just the other way round:
# If HybridSleep isn't available, Hibernate will be used # If Hibernate isn't available, PowerOff will be used
The output is ('yes',) for "CanHibernate" and "CanHybridSleep".
Here is my bug report (o: https://bugs.freedesktop.org/show_bug.cgi?id=82925
22 August 2014 at 17:03
As is becoming common, we will have some more power management changes in GNOME 3.12, though those changes will also affect other desktops, whether they use UPower's D-Bus interface, or libupower-glib, the helper library.
The goals of the exercise were simple:
reduce wake-ups on the daemon and on the client side
reduce code duplication amongst desktop environments, and even within the same environment (composite battery, anyone?)
moving some policy actions to a lower level (one could not request hibernation or suspend when multiple users were logged in without interaction and passwords)
All those changes are now in UPower master ready for testing.
Out with the old
The deprecated interfaces for Suspend, Hibernate, etc. are finally removed, after being obsoleted by logind. We've also removed the QoS interface that nobody was using, and the out-dated battery recall support. It's not that batteries don't explode any more, it's that they don't all come from known-bad batches.
In with the new
We have 2 new properties on each of the devices.
WarningLevel which uses daemon-side configurations to tell you whether a device's battery level is low, critically low, or whether we're about to take action on that critical level.
We also have IconName, which replaces some cut'n'pasted code between desktop components. If your desktop environment has many more icons for all types of devices on low battery, for example, you can ignore this property and use the code you always have.
And finally, using that new combined DisplayDevice is the critical battery action policies. As mentioned above, multi-user systems could not hibernate without requiring the user to enter an administrator password, which is less than convenient when your machine is running out of UPS power fast. The configuration for that policy is now in the daemon itself, with sane defaults, and it will hibernate the machine for you.
And to the modernisation
libupower-glib now uses GDBus, even if the daemon doesn't. The daemon however sends PropertiesChanged signals which means that modern D-Bus bindings will automatically get the new values for properties, instead of polling the daemon. The DeviceChanged and Changed signals have thus been removed.
API changes
They are numerous, too many to mention here. I've posted to the device-kit mailing-list with a list of changes that were made, reply there if you have any questions regarding using UPower in your application or session daemons.
"More power management changes"
7 Comments -
Please excuse me if this is a stupid question but why would users of either the D-Bus interface or the glib abstraction library be affected?
Affected in such a context has a negative vibe attached to it. Like having to change their code.
17 October 2013 at 18:19
Affected doesn't necessarily have a negative connotation, it can just mean "it will change something in the subject".
It breaks the D-Bus API, and both the ABI and API of the libupower-glib helper library, so it has a negative influence. It adds badly needed features, so will have a positive influence as well :)
17 October 2013 at 18:55
Hi, I am facing a problem with the "HybridSleep"-thing in UPower, so I set it to "Hibernate" in UPower.conf, but after reloading the upower-systemd.unit I still get critical-action: HybridSleep from upower -d . So I had a look into your code and didn't find a trace where this Parameter is read.
And now I want to say why I don't want HybridSleep as default. My Thinkpad X1 cannot do resume from sleep aka standby anymore (some kind of hardware problem). HybridSleep would be the best option, if my hardware would still function correctly, but I am forced to use hibernate only. For now this issue is not critical because I do not loose any data in the process. I can still resume from hibernate even if the UPower has used HybridSleep after I switch off the notebook while in sleep manually.
And yes, I know, the method up_backend_take_action(...) calls logind to do the actual sleeping and hibernating.
Besides all of this, I have a pretty standard Gnome 3.12 desktop on Gentoo. I apologize for reporting this here instead in a bugzilla of yours, because I am not sure, if I missed something in your code which makes my statements invalid. Any hints are welcome.
8 August 2014 at 15:35
André K: it probably doesn't use Hibernate because systemd says your system cannot hibernate. It then falls back to the next best thing, which is HybridSleep.
You can try something like that:
gdbus call --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanHibernate
8 August 2014 at 15:54
Oh, I thought, it is just the other way round:
# If HybridSleep isn't available, Hibernate will be used
# If Hibernate isn't available, PowerOff will be used
The output is ('yes',) for "CanHibernate" and "CanHybridSleep".
8 August 2014 at 16:01
No idea. File a bug? :)
8 August 2014 at 16:11
Here is my bug report (o: https://bugs.freedesktop.org/show_bug.cgi?id=82925
22 August 2014 at 17:03