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.
It was only used in one function. The value should be kept in the
DisplayDevice instead, but we need to make sure that the UpDevice code
never changes the warning-level, only the daemon does.
This portion of up_daemon_startup() contains the exact same code as
up_daemon_update_warning_level(), so call
up_daemon_update_warning_level() instead.
No need to guard up_daemon_set_warning_level() with a check for the
value changing, up_daemon_set_warning_level() already checks for
that exact same equality.
The test test_critical_action_is_taken_repeatedly has two long sleeps
of UP_DAEMON_ACTION_DELAY, which is currently set in the tests to 20 seconds.
As the global timeout for meson tests is 50 seconds, failures are likely
to occur, specially in slow architectures. Increase the timeout to 60
seconds to avoid this problem.
Closes#171
At least for "change" events the device is most likely simply one that
we are not handling at all. For these, we will convert the event to
"add" and continue to ignore it later on.
Otherwise we flush out the data much more often than needed. With this
change, we'll also wait up to 5 seconds even on lower power. Loosing 5s
of data shouldn't be too bad, and it may prevent additional disk writes.
But, more importantly, we need to deferre writing the data to a later
main loop iteration. If we did not do this, then we have an
write-amplification scenario where the history is written at least 4
times instead of once.
Closes: #150
The changes from 37b6d4b039 ("linux: Fix Bluetooth tests for
python-dbusmock changes") require a not-yet-released dbusmock version.
Simply catch the error and fall back to adding the properties in order
to be compatible with both old and new dbusmock versions of the bluez
service.
The algorithm tries to use floating point timestamps. However, the
precision of floating point is too low for unix time, causing rounding
issues. This can cause extra points to be inserted (or too few) under
some conditions, creating a scenario where the test-suite fails
randomly.
Do this properly by using 64bit integers for the time. The 64bit integer
should have enough head-room even for very long histories.
Closes: #167
Prevents a spurious warning:
"did not recognise USB path /sys/devices/platform/USBC000:00/power_supply/ucsi-source-psy-USBC000:001, please report"
This does not actually change any functionality, as the heuristic for
the attribute "online" in up_device_supply_coldplug() would have
matches id, too.
Fixes#148
