There is no need to refresh batteries if we just re-read the status of a
line power supply without actually seeing a change ("online" vs.
"update-time" property).
Fixes: #184
Setting the property will create a notification, which in turn causes
the daemon code to trigger a battery refresh. As such, avoid actually
setting the property if it still has the same value.
Note that we shouldn't usually get spurious notifications, but it is
good to be safe here in case e.g. a bad firmware just sends out
notifications when the battery capacity changes.
Related: #184
The class kept track of the power-supply property internally. However,
the value is static, and it is only needed to be queried in very few
cases.
Move the property setting to an earlier time and stop touching it when
it is not needed.
The USB device type for power supplies are always USB ports of the
system. As such, we should be able to assume that they are power
supplies.
Fixes: #183
When a change on a line power occurs, then re-poll all batteries
aggressively for a while. It is very common for batteries to take about
a second to refresh their state and many will not send appropriate
notifications in this case.
Closes: #179, #159
Instead of just killing upower, try to send SIGTERM for a clean
shut-down. Kill the process if it doesn't quit within two seconds, and
check that the service exits cleanly.
While not needed currently, there is a discussion to ignore the "hid"
subsystem parents when searching for siblings. Add in appropriate
parents to the tests so that such a change will not result in a failure.
Commit b78a2ab980 ("daemon: Stop passing UpDevice reference to the
daemon") fixed the fact that the signal passed a reference to the
daemon. This fix also implied that the UpDaemon object does not own a
reference to the device itself, instead relying on the UpDeviceList to
keep it alive.
With this change, there is no need to drop the extra reference when
clearing the device list, remove the code accordingly.
Reported-by: Alberts Muktupāvels <alberts.muktupavels@gmail.com>
This causes an add that we ignore, after that we should still see
updates from the device (and the add itself should trigger an update).
Verify that this works by setting the capacity to 20.
The device list class now assumes that contained objects are UpDevice
and we cannot store UpInput objects inside it anymore. Switch the lid
switch to be stored in the linux backend directly rather than allocating
a UpDeviceList just for that.
This fixes commit ddc739f38b ("device-list: Remove unnecessary native
argument")
As these are triggered by property changes, they may happen numerous
times for a single update. Avoid executing these (potentially expensive)
updates multiple times by pushing them into the next main loop
iteration.
The startup polling just creates the idevice_t. It is trivial to detect
that, so move it into the refresh handler and set the initial polling to
the shorter period, increasing the poll interval later on.
This uses a GSource and a simple looping approach to trigger device
refresh when needed. We don't use the g_timeout_add_seconds rounding
again to synchronize with other applications, but we will eventually
poll everything at the same time. Also, we will not do wakeups if an
update happens regularily enough due to e.g. a uevent.
Add last-refresh and poll-timeout properties. Update the last-refresh
property automatically from the internal refresh method. Note that it is
fine if we miss (some) updates for now, as the polling code which uses
the property will update it.
There are two users, and both simply force a device refresh. We also
simply force-refresh devices after resume, which ties into
pausing/resuming polling.
The reason of a refresh may be interesting to special case certain
situation (e.g. discontinuity of charge after wakeup, polling again
after an event). As such, add an enum parameter that signals the reason
for the refresh.
There are only a few cases where we separate construction and coldplug.
Porting to GInitable is relatively natural here and makes the code a
little nicer overall. In the case that immediate coldplug/initialization
is not desired, we can still split the operations.
We can just assume that a device with a NULL native device is the
display device. Using this, we can special case the naming and rely on
the normal internal up_device_register_device function to register the
display device.
FD 0 is valid in principle, as such, we shouldn't use it as the default
for knowing whether the FD has been open'ed. Instead, use -2 so that -1
can still be used after open failed.
The Refresh D-Bus method could be used by clients to force re-reading
the state of batteries in the upower backends. This is not needed as
all the backends should be sending events when their states changes,
removing the need for an explicit refresh.
This is also a potential security problem if applications keep on
refreshing their data.
We now only allow access to the Refresh() method if the daemon was
started in debugging mode. This should make it clearer that it is a
debug tool.
Also remove a mention of the never implemented refresh-power-source
polkit authorisation.
Guard platform specific code and add in a few extra definitions so that
the backends can at least be partially compiled on linux. This is for
testing purposes, if we could build against a proper image that would
also be acceptable.
