[Nut-upsdev] belkin-hid:

[Arjen de Korte]

>> Personally, I feel that ignoring the faulty report in belkin-hid.c would
>> be the method of choice, provided that the low battery status is
>> available in 'UPS.BELKINStatus.BELKINBatteryStatus'.
> Yes, that would work. Except that I have never tested that
> UPS.BELKINStatus.BELKINBatteryStatus shows the status correctly, at
> least on the hardware that I have. I would need to generate a low
> battery event to test this.

Since these status bits are documented in belkin-hid.c, I (maybe wrongly)
assumed this was the result of reverse engineering the protocol used by
the Belkin software. So yes, since this is one of the most (if not the
most) critical parameter we need to read from the UPS, this would be a
requirement. If we not already know this works on all Belkin units, I
withdraw my statement that ignoring the faulty report at all times would
be the easiest solution. We certainly don't want to break installations
that previously worked.

> What I really want is a more general hook to work around
> vendor-specific bugs.
>
> For example, some, but not all, Tripp-Lite devices incorrectly
> multiply their battery voltage by 10. (Actually, the bug is in the
> report descriptor, which reports incorrect units for battery voltage
> for some devices. The actual reports are consistent across devices, I
> think).  I have worked around this by dividing the voltage by 10 for
> *all* Tripp-Lite devices, which now causes the value to be broken on
> devices that happen to be free of this bug.
>
> What I would like to do is to have a generic vendor_init hook in
> *-hid.c, which would detect vendor-specific bugs in a vendor-specific
> way, and compensate accordingly. This should be called just after the
> report descriptor has been obtained and parsed. The (unparsed raw)
> report descriptor can also be used to identify specific buggy devices,
> particularly where the bug has been fixed in some versions of
> otherwise identical devices.  In the Belkin case, one would compensate
> by simply removing the offending report from the report descriptor. In
> the Tripp-Lite case, the buggy physical unit could be replaced by the
> correct one.

+1. That would *much* better and provide the needed flexibility.

[...]

> Again, the suggestion is valid; however, with Belkin, there is no
> guarantee that all the advertised status bits are actually implemented
> correctly. Since their firmware is so crappy, one can only be
> reasonably sure that they tested the status bits that their own driver
> reads. So I will test this with my own hardware and report back which
> bits are working. I'll have to do this at work; not sure if I'll be
> able to do it today or this week.

No hurries here. I can imagine that you have other priorities right now...
:-)

Best regards, Arjen