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.
The BSD backends are still compiled in linux, and platform specific code
is mostly disabled using a special define. However, this way we can at
least compile tests code refactorings.
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.
Rather than this weird situation where they are immediately passed in
through the "coldplug" method. Doing this is the first step to make
UpDevice into an initable object (removing the "coldplug" method).
The refresh functions only ever returned whether data was successfully
fetched or not. The failure return code was unused and the corresponding
code can be removed.
The hiddev driver has been in the "usbmisc" subsystem since kernel 3.7.0
or so. As such, we can simply drop the "usb" subsystem from our matches
at this point.
This makes rule matching more efficient. We just need to copy the
variables over into the hiddev device so that there is no need to change
the C code to match the parent USB device. That said, the change in C
wouldn't be that hard either.
See https://github.com/networkupstools/nut/pull/1342
The API relied on /proc/timer_stats which has been removed from the
kernel in 2017. Since then, the API has been non-functional (yet
incorrectly reporting support because the support test was buggy).
Just remove it completely. The debian codesearch does not uncover any
API users. Also, I doubt that any new API (based on tracing scheduler
events as perf would do) would map well to what exists now. i.e. if
something like this is re-implemented in UPower or elsewhere, then the
API should likely look different.
And, realistically, if this does need root privileges (i.e. can't be
moved to use BPF programs or so on user units), then we can also create
a new small daemon that is launched on-demand just for that.
Also add an assert that the FD is -1 when we are about to grab the
inhibitor. Previously, we would just set the value early enough before
trying to close the FD, overwriting the incorrect initialization.
The open() call needs to check against the FD being <0 for error
detection. Also, add a missing close in one of the error paths and
change the code to let the input stream close the FD when it is not
needed anymore.
We still open() it manually just because we need to do an ioctl once.
