Under certain conditions lockdownd_client_free was called
twice for same client. This caused SIGSEGV.
This patch addresses this issue
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
Signed-off-by: Richard Hughes <richard@hughsie.com>
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>
Cppcheck found it as a logical conjunction always evaluates to
false: EXPR < 32 && EXPR > 126. Change the expression to an Or.
https://bugs.freedesktop.org/show_bug.cgi?id=71066
Signed-off-by: Richard Hughes <richard@hughsie.com>
This is better design to catching regressions and problems in a more
pin-pointed fashion. This also avoids having to restart the umockdev testbed
due to changing the environment variables with stop/start_daemon().
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
This has 2 effects:
- we never stop polling (we used to stop polling when the
battery was marked as fully-charged, but that can happen when
the battery is discharging too)
- when in an unknown state, we will poll through the daemon,
and through our unknown poll. This isn't a problem as there'll
another 115 seconds of wait until we get to poll through the
daemon again.
For system integrators. If your firmware is helpful to user space
and automatically sends out uevent when the battery level changes
(rather than just the battery state) as on most machines,
you can enable "NoPollBatteries" in the configuration option,
and reduce power consumption from UPower and its listeners.
Some batteries report energy > energy_full and a percentage ("capacity"
attribute) > 100%. Clamp these within 0 and 100% for both plausibility as well
as to avoid setting an out-of-range property which would then become 0%.
https://launchpad.net/bugs/1240673
I don't think the kernel exports any numbers with a decimal
portion, but if they did, they would get the wrong values because
some locales use "," as the decimal separator, and not "." as the
kernel/C locale would.
Update the expected warning levels to match, and add a big
fat FIXME for the test case itself. That's not how UPSes work,
or how UPower is expected to work.
When switching off Bluetooth devices, and before they timeout,
we won't be able to read the battery percentage, so don't
overwrite the previous value with "0%", but set the state to
unknown instead.
https://bugs.freedesktop.org/show_bug.cgi?id=70325
When refreshing the state of device batteries, no need
to get data that won't be there anyway, such as voltage, temperature,
or consumption rate.
This avoids warnings about voltage being unknown for devices, and
cuts down on the properties churn.
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.
