Check that external devices which show up as "battery" types have their
capacity_level correctly read, and that the device's type will be
correctly read after an input node is attached.
This check is supposed to start a poll for 1) batteries embedded in
external devices 2) batteries when battery polling is not disabled.
Make sure to start the poll for all batteries embedded in devices even
the ones that are just detected as "battery".
On some devices the power_supply node will show up before a related node
such as "input", making it impossible to know which type of device we're
attached to without waiting. Try to detect the device type again if the
device type is still "battery".
This fixes some Logitech devices appearing as "Battery" instead of their
respective device type, such as "mouse".
Use the correct refresh function for device batteries which aren't of a
known type. This fixes battery information not getting updated on many
Logitech wireless devices.
Reproducer:
- Unplug Logitech receiver
- Replug Logitech receiver
- Press button on Logitech keyboard
- Move mouse/touchpad
The touchpad battery would be stuck in "unknown" and with a "type" of
battery. This commit forces the correct refresh function to be used, one
that reads the capacity_level on those devices, and will update the
overall battery level.
Closes: #72
G_TYPE_INSTANCE_GET_PRIVATE has been deprecated since glib version
2.58 and should be replaced with the xxx_get_instance_private (obj)
which is generated by G_ADD_PRIVATE.
Use G_DEFINE_TYPE_WITH_CODE (..., G_PRIVATE_ADD (...)) instead of
the (deprecated since glib 2.58) function g_type_class_add_private
to add a private structure for a type.
Bump the minimal required version of glib to 2.38.0, the version
where G_PRIVATE_ADD was added.
Some devices report "Not charging" when the battery is full and AC power
is connected. In this situation we should report fully-charged instead
of pending-charge.
Closes: #86.
Currently up_device_supply_refresh_battery sets out_state before the
state value is definitive, so the wrong state value is returned to the
caller. Luckily the only caller does not make use of this value at the
moment, so there are no user-visible consequences. Nonetheless this is a
bug, so this commit fixes it.
Test relaying the pending-charge state to the DisplayDevice. This commit
adds three tests: only one battery pending-charge, one battery
pending-charge and another one discharging, and one battery
pending-charge and another one charging.
Pull the 2 previous changes together to refresh the battery status for a
couple of seconds after receiving an event on the power line. This fixes
charge status being inaccurate for up to 120 seconds (the normal poll
timeout on MacBooks).
https://gitlab.freedesktop.org/upower/upower/issues/56
When an event happens on the power line, and we are using a particular
device (in this case a MacBook or MacBookAir), we might need to poll
more aggressively after the event.
This adds a function to detect and export this.
Fix double-close on exit. If we created a GIOChannel from the file
descriptor, then g_io_channel_shutdown() will close that file descriptor
as well. Close the channel first, so that the file descriptor is only
closed manually if we didn't manage to create a GIOChannel from it.
https://gitlab.freedesktop.org/upower/upower/issues/60
Don't leave the history files installed when running "make uninstall".
Those files will likely have been created by the test suite when running
"make distcheck"
sysfs_get_double_with_error() used to return -1.0 for errors, but in
some cases, we might want -1.0 to be a valid value, such as for negative
discharge rates. Return FALSE on error instead.
The current power_supply support in the kernel will advertise an unknown
capacity when a device is being charged. This tests this state as well
as the expected behaviour when the device is fully charged.
https://bugs.freedesktop.org/show_bug.cgi?id=97484
Rather than leaving the percentage untouched, set the battery level at
50.0 as a "middle-ground".
This percentage is supposed to be ignored if a BatteryLevel is set so
this is better than showing "0%" which makes it look like a bug.
https://bugs.freedesktop.org/show_bug.cgi?id=97484
Newer kernels emit bind/unbind uevents that are not of interest to
powerd. To avoid littering logs with scary messages, let's lower their
severity to "debug".
https://bugs.freedesktop.org/show_bug.cgi?id=106018
This adds an extra check to query if the iOS device has a
battery at all before actually trying to retrieve the battery
status. Should still work for older iOS versions which do not
provide this key.
https://bugzilla.freedesktop.org/show_bug.cgi?id=105625
As Apple TVs do not have a battery and do not provide the
"BatteryIsCharging" lockdown key, upower would crash due to a
missing check whether the retrieved node is actually valid.
https://bugzilla.freedesktop.org/show_bug.cgi?id=105625
As exported through BlueZ's org.bluez.Battery1 D-Bus interface. This
interface is only used for device where the battery information cannot
be processed in the kernel.
This is the first UpDevice type that doesn't use UdevDevice for the
Linux backend, and it is also the first that does not poll() status at
all.
https://bugs.freedesktop.org/show_bug.cgi?id=92370
Since libimobiledevice 5a8449a, LOCKDOWN_E_NOT_ENOUGH_DATA was renamed
to LOCKDOWN_E_RECEIVE_TIMEOUT. We'll use "-7" to avoid having to use
build glue.
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
The initial "refresh" for devices would fail if there was no data to
read. Instead, we should set the level to unknown, so that the device
appears in the Power panel, and in the "upower -d" output.
The "model_name" and "serial_number" information that upower exports for
batteries that supply a laptop or UPS are supposed to be that of the
battery. But that's very unlikely to happen for devices, such as
wireless mice, keyboards or joysticks.
Look for a sibling input device if a device battery does not contain
model information so as to avoid generic names in UIs.
https://bugs.freedesktop.org/show_bug.cgi?id=102493
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
