[Nut-upsdev] NUT and libhid

[Arjen de Korte]

> This would all take a lot more effort than I originally imagined. But
> it's good information for me to keep in the back of my mind as I
> update libhid.

If you have the time available, can I ask for a badly needed feature? We
badly need a call to clear the reportbuffer. Currently, both the instcmd()
and setvar() functions in usbhid-ups are broken (yes, in the stable
nut-2.2.0 as well).

Both functions call HIDSetItemValue, which first of all checks if the
variable/command is valid by calling HIDGetItemLogical. This in turn
causes the old value of the variable/command to be stored in the report
buffer. So far, so good. However, we run into problems for items that have
the HU_FLAGS_SEMI_STATIC set (which is valid for basically all variables
and commands, unfortunately). In order to get the new value from the UPS,
a flag will be set (data_has_changed) which causes that these will be read
once, the next time upsdrv_updateinfo() runs. If this happens within two
seconds after instcmd/setvar, this will return the old value from the
report buffer. It will stay that way, until the next time a user runs an
instcmd or changes a variable.

The workaround for this, is to issue all variable changes and instcmds
twice with at least two seconds between them, so that on the second
attempt, the report buffer will be refreshed.

There are two solutions to this problem:

1) Flush the report buffer in upsdrv_updateinfo() when data_has_changed is
set (only once) to make sure we get fresh data from the UPS.

2) Hang around in instcmd() and setvar() longer than MAX_TS seconds
(currently 2 seconds), so that the contents of the report buffer will be
past their 'use by' timestamp.

Solution 2 can be implemented quickly, however it will make the drivers
sluggish, since the delays in these functions will triple at least. Since
there is technically no reason to wait at all (even the 1 second delay we
have now is redundant), I have a strong preference for solution 1.

Best regards, Arjen