The unref of the FD list for the inhibitor was missing which means that
the FD was leaked and the lock was never released. This means that for
each suspend/resume cycle a new inhibitor would be added.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Export approximate battery levels that devices can use, exported by
the kernel as POWER_SUPPLY_CAPACITY_LEVEL_* values.
This avoids bizarrely accurate values showing up in UIs when we only
have ok/warning levels of accuracy in some cases.
https://bugs.freedesktop.org/show_bug.cgi?id=100359
Those levels will not be used to cover warning levels, but approximate
battery levels that devices can use, exported by the kernel as
POWER_SUPPLY_CAPACITY_LEVEL_* values.
See linux/power_supply.h
https://bugs.freedesktop.org/show_bug.cgi?id=100359
Some devices, such as a number of wireless Logitech unifying devices
don't have a precise battery level reporting, and use the Linux
POWER_SUPPLY_CAPACITY_LEVEL_* values.
This minimal fix matches the levels against approximate percentage
values. This is good enough to make the Logitech T650 report battery
again when using the kernel HID++ battery support.
https://bugs.freedesktop.org/show_bug.cgi?id=100359
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
Paths supplied to testbed.add_device() are relative to /sys/devices
already and therefore must not start with /sys/devices.
This does not change the result of the test.
https://bugs.freedesktop.org/show_bug.cgi?id=100539
The NoPollbatteries option should disable battery polling. Create
a config file with 'NoPollBatteries=true' and ensure we don't get
polling setup for the virtual battery.
https://bugs.freedesktop.org/show_bug.cgi?id=99763
Use an inhibitor lock obtained via logind to make sure the polling
is paused before the system is put to sleep, rather than racing with
the suspension.
https://bugs.freedesktop.org/show_bug.cgi?id=99763
The battery levels might have changed drastically compared to
before sleep. Since we poll batteries at set intervals, it can
take quite some time for the new level to be picked up by the
polling code.
Listen to the "PrepareForSleep" signal emitted by logind, that
gets emitted on suspend and wake up. Pause polling globally on
suspend, and refresh all devices manually and resume polling when
waking up.
https://bugs.freedesktop.org/show_bug.cgi?id=99763
GUdev-CRITICAL **: g_udev_device_get_sysfs_path: assertion 'G_UDEV_IS_DEVICE (device)' failed
This is caused by looking for devices in a particular subsystem which
don't have parents. This can happen with virtual devices, such as the
ones created by test suites.
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.
Backlights, starting with kernel 4.11 [1] can have a
"brightness_hw_changed" sysfs attribute, which can be polled to detect
hardware initiated brightness changes, such as ones done through
firmware-handled keyboard backlight hotkeys, or firmware controlled
changes (eg. turn off backlight on low battery).
[1] https://patchwork.kernel.org/patch/9544111/https://bugs.freedesktop.org/show_bug.cgi?id=98404
Pass the fd to use to up_kbd_backlight_brightness_read() so that it can
be used with multiple fds. This will be used to support the
"brightness_hw_changed" sysfs attribute.
https://bugs.freedesktop.org/show_bug.cgi?id=98404
There are multiple possible causes for the keyboard brightness to change,
e.g. SetBrightness may get called, or the brightness may get changed
through a hotkey which is handled in firmware.
https://bugs.freedesktop.org/show_bug.cgi?id=98404
When starting up, we would try to connect to the iDevice repeatedly,
once a second. But the process takes between a quarter and half a
second, and is CPU heavy. Lower this timeout to once every 5 seconds to
reduce the initial CPU consumption.
