[Nut-upsdev] USB HID - interrupt reports

[Arjen de Korte]

> But the problem there is not to manage variable change through the
> input pipe, but to see the real change that only happen through the
> input pipe.

In that case, we're toast already (with or without the changes I applied).
We can't handle Feature and Input reports that are telling two different
stories at the moment (see below). This is what initiated this change in
the first place.

> The beeper is a good example. The change are not visible through
> feature/output (so polled) requests but only through the
> notification...

It *might* work if the beeper has both a Feature report and an Input
report, but not at the moment. If said variables where to be updated
*only* by Input reports (after the initial creation of the variable
through a Feature report), they would need to have the HU_FLAG_STATIC
flag, instead of HU_FLAG_SEMI_STATIC it has now. Otherwise the next time a
variable changes, the change will be lost. This is not the case now and
would conflict with units that don't use Input reports for the same
variable. I don't know for which variables we can safely do this anyway.
So until that is resolved, there is no need for change.

> Moreover, the biggest advantage of notification (obviously when the
> hardware works) is to limit the computer usage.

This change doesn't prevent that! The only thing it does, is discarding
the data we receive in an Input report and reading it again through a
Feature report (once). This is triggered by the reception of the Input
report, so even if you would never run a quick or full update or would
flag the variables HU_FLAG_STATIC (see below), they would still be
updated. I'm afraid that you have not fully understood the change I made.

> Having a full
> asynchronous chain would allow me to launch the green nut project one
> day (I'd like to audit this and check what can be improved to reduce
> nut footprints in general, and its impact on the energy consumption in
> particular. Check Green Linux, PowerTop and the like)

That's an interesting concept, although I very much doubt that we should
try to attempt to integrate this in the 'usbhid-ups' driver.

It would mean that we can no longer monitor values that are now updated by
the full update that runs periodically (voltages, frequency, temperature
and so on). If you want to see all the measurements that your whizbang UPS
supports (and people usually complain if we miss one, compared to the
bundled Windows drivers), you'll *have* to rely on polling the data
through Feature reports, since that's the only way how to adjust the flow
of measurements to a rate the application wants. At present, the only way
to do that is with a fixed interval, initiated by the driver.

It would be nice if clients where able to initiate a data poll, however
this is a *huge* change in NUT (you'd only poll for data, if someone is
asking for it). We'd need to modify the drivers for instance, so that they
no longer continuously poll all UPS variables, but only the ones that go
into 'ups.status' and the remaining variables upon request. There is no
doubt that there are benefits to do this, but I'm concerned about the
massive changes this means to the majority of the drivers.

> btw, I've not seen your change to usbhid-ups.c to limit this to non MGE
> units...

Since we're in the trunk, I fail to see the need to rush this. I think we
should handle this through a flag that is set by the subdrivers, by the
way. This obviously requires more effort and I don't want to spend that
until we have absolutely clear why this is needed (I'm not convinced that
we do at the moment).

Best regards, Arjen