The take_action_timeout_cb() function returns G_SOURCE_REMOVE which
makes GLib destroy the timeout. However the action_timeout_id
stayed != 0 so when warning level turned to "action" again the daemon
assumed that the timeout is already set and did nothing.
(It only logged: "Not taking action, timeout id already set")
https://bugs.freedesktop.org/show_bug.cgi?id=87791
If the poll timeout is actually changed because the warning level
has changed, only reset the actual poll code, not the warning level
notifications and the booking structures.
https://bugs.freedesktop.org/show_bug.cgi?id=99862
When a device is refreshed because the poll timeout has been reached,
the warning-level change notification can also be fired, which then
will reset (i.e. disable, re-enable) polling. For batteries this can
happen three times in a row.
Now we reset polling only if the calculated timeout actually differs
from the current one.
https://bugs.freedesktop.org/show_bug.cgi?id=99862
A 5% battery level should already be in "critical", this matches the
configurable thresholds where the bounds of critical warnings are
inclusive. This also makes it easier to create fake percentages for the
Logitech devices with coarse battery level reporting.
https://bugs.freedesktop.org/show_bug.cgi?id=100359
When setting up polling for our devices, it's possible that the device
hasn't yet been exported on D-Bus, meaning that the object would be
unhelpfully empty.
Use the "native path" instead, so we don't get null in debug outputs, or
timeout names.
This makes it easier to find real memory leaks with valgrind. After
calling the up_backend_unplug functions, you cannot restart it with
up_backend_coldplug since the lists are cleared.
Tested with Linux only (not on *BSD; dummy compiles).
https://bugs.freedesktop.org/show_bug.cgi?id=82659
up_daemon_get_daemon takes a reference on UpDaemon, so it must be
properly dereferenced. Similar for up_daemon_get_devices_list which
references an UpDeviceList.
The display device was allocated in init, but never released either.
https://bugs.freedesktop.org/show_bug.cgi?id=82659
Whenever the daemon is polling on a device, a new signal is connected to
the object. This signal was not disconnected when polling stops which
resulted in a memory leak. Furthermore, whenever the "warning-level"
property is updated, the signal would result in an exponentially raising
call count (this happens when the battery percentage changes for
example).
https://bugs.freedesktop.org/show_bug.cgi?id=82659
Reported-by: Alexander Jesner <alexander@jesner.eu>
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Commit 5ddfe0d (all: Use g_get_real_time() when possible) replaced calls
to g_get_current_time() with g_get_real_time(), however, we also need to
convert the return value from microseconds to seconds.
Signed-off-by: Richard Hughes <richard@hughsie.com>
With the removal of the suspend/hibernate code, there's no longer
a need for upower to depend on polkit. This patch removes the old
polkit code.
Signed-off-by: Richard Hughes <richard@hughsie.com>
The IsDocked property has been incorrect for a number of laptops for a
while, as it thought that laptops with hybrid graphics cards were always
docked.
The alternative would have been to use the platform/dock_station
devices, but those are only exported for ACPI docking stations.
Instead, whether an external display is attached (which isn't really
docking) should be checked in the same place where the policy depending
on the value should be applied, such as gnome-settings-daemon.
https://bugs.freedesktop.org/show_bug.cgi?id=36818
On the Lenovo A600 all-in-one, there's a HCI/HID dual-mode Broadcom
device which will try to get the battery level of the supplied
mouse and keyboard, but will usually fail to do so.
So we have a battery of type "battery" (it's not either a mouse or
a keyboard, as it's supposed to handle both) but our display device
battery code doesn't check whether those batteries are power supplies
or not, using this "empty" (0% after the check timed out) battery in
the shutdown policy.
Check better for power supply devices, not all the "battery" types
are power supply batteries, they might be non-power supply ones
from unknown device types.
To be used by all polling backends. This changes the defaults
to poll every 120 seconds when a warning level isn't reached, and
switch automatically to 30 seconds poll when the battery level is low.
When the AC state changes, let the backends poll for battery changes.
They know better what's _really_ happening (whether the real state
is unknown even if they present a fully-charged battery), etc.
This is only possible because we fixed the Linux backend to poll
as it should always have.
If one battery is draining and the other one isn't, the time
to empty wouldn't be zero, but it would only match the time
to empty for the single battery.
Instead, ignore the accumulated time to empty/time to full
for multiple batteries and recalculate it.
https://bugzilla.gnome.org/show_bug.cgi?id=710344
Now that we send out PropertiesChanged signals (on the daemon side)
and "notify" signals (on the client side), there's no need for the
all encompassing DeviceChanged and Changed signals.
They would have woken up any client, even if they were not interested
in receiving the signals.
This is a hack that was in gnome-settings-daemon's power plugin.
We would check whether we were on AC before saying for certain
that batteries had a low-level, and raising the warning-level.
This allows desktop front-ends to get which action will
actually be taken when we hit critical battery.
This is not a property as availability of actions might
change over the course of the run of the system, and
we didn't want to make unnecessary D-Bus calls on startup.
