It was added for some workloads, but ill-suited and never really
got traction. Using cgroups to manage the resources of particular
services (using systemd), or something separate like rtkit is
a better bet.
The recalls for that broken batch of Sony batteries dates back from
2006. All the batteries that could have been recalled have now
been recalled, and somebody particularly interested in supporting
them can match the batteries using the old rules file, in a
user session or a separate daemon.
If an unknown option was passed to the daemon, it might fail
to parse some of the passed options, and not take them into account.
For example: "upower -d --timed-exit" would fail to exit
Error out when an unknown option is passed.
db89e5a32b was incomplete and
"ret" was being used instead of prop_val to set some of those
properties. It's likely your laptop would have been seen as
docked for example.
In up_client_get_properties_sync(), don't set the passed GError** to NULL,
instead set the actual pointed-to GError* to NULL by default.
Fixes proper error reporting back to the client if something does fail.
We would error out when trying to get properties that are
disabled by default (deprecated). Ignore those properties
when building without the deprecations.
This is still broken if the library is built with the deprecations
enabled, but not the daemon isn't, but that's an edge case.
https://bugs.freedesktop.org/show_bug.cgi?id=70283
Signed-off-by: Martin Pitt <martinpitt@gnome.org>
If one of the properties is FALSE, we'll end up return FALSE
without setting an error (and making the caller crash if they
expect an error being filled in).
https://bugs.freedesktop.org/show_bug.cgi?id=70283
Signed-off-by: Martin Pitt <martinpitt@gnome.org>
The full native sysfs path of wireless HID battery devices contains a lot of
jitter like USB tree layout or sequence numbers which change after every resume
from auto-suspend. Plus, there are kernel bugs which don't give proper remove
events for those: http://bugzilla.kernel.org/show_bug.cgi?id=62041
As device names within the same subsystem must be unique anyway, and we only
use the device name for constructing the D-BUS object path, only consider the
device name for the device list native → upower object lookup table, i. e. in
up_native_get_native_path().
This fixes the "A handler is already registered for <battery>" assertion crash
if a bluetooth device comes back from auto-suspend. This fixes the
test_bluetooth_mouse_reconnect() test case, drop the expected failure.
https://launchpad.net/bugs/1112907
When these power down, we don't get remove uevents for the original
power_supply devices from the kernel, but instead we get new devices with a
different sequence number, but the same name:
UDEV [6408.025124] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:12/0005:0D62:0558.0001/power_supply/hid-00:0f:f6:6d:8e:c0-battery (power_supply)
UDEV [23785.90673] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:12/0005:0D62:0558.0002/power_supply/hid-00:0f:f6:6d:8e:c0-battery (power_supply)
This circumvents the existing "treating add as change" check (as the native
path is different) but breaks later on when building and registering the
(supposedly) new object:
ERROR **: Failed to register GObject with DBusConnection: org.freedesktop.DBus.Error.ObjectPathInUse A handler is already registered for /org/freedesktop/UPower/devices/mouse_hid_000ff66d8ec0_battery
This reproduces https://launchpad.net/bugs/1112907
Don't just cover the test upowerd by umockdev-wrapper, but the test suite
itself as well, so that we can send uevents.
Do this by re-execing the test suite under umockdev-wrapper if it's not already
running under it.
Check the input subdevices of the bluetooth parent device of a battery, if
present. If there is mouse* input child device, is a mouse battery; otherwise,
it is a keyboard battery. This also fixes the PowerSupply attribute for these
to be false, as the batteries of wireless input devices don't power the system.
https://launchpad.net/bugs/1153488
Signed-Off-By: Martin Pitt <martin.pitt@ubuntu.com>
These should be detected with their proper type (5/6, not 2) and not count as
powering the system, i. e. their PowerSupply property should be False.
This reproduces https://launchpad.net/bugs/1153488
(1) If the K800 keyboard is charging via the USB cable, it will report
itself as Charging, but with a discharge level of 0 (which means
"unknown". In this case, the previous known value (before
connecting the cable) is always a better approximation than using
zero.
(2) When the K800 has fully charged (but with the cable still plugged
in), it will still report 0 as discharge level. "Full" is 100% by
definition, so let's fallback to that value.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Signed-off-by: Martin Pitt <martinpitt@gnome.org>
I previously followed the model example for copying part of the string,
but there is a much simpler way to build the name string using
g_strdup_printf. Note that a simple strdup() is not sufficient for model
since it does not have to be NUL terminated.
Reported-by: Martin Pitt <martin.pitt@ubuntu.com>
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
