[Nut-upsdev] USB HID - interrupt reports
Arjen de Korte
nut+devel at de-korte.org
Wed Jan 2 14:33:13 UTC 2008
> I'm strongly opposed to that changes for *MGE* devices.
> We would end up in missing some setting changes that are only reported
> through the interrupt pipe (like when muting the beeper) and overload
> some old low end units (resulting in temporary DOS when OB).
There may be some merit in your first argument, although so far I have
never seen an input report that didn't also have a matching feature
report. Not having that, would mean that if one missed the input report
(for whatever reason), you'd never know about the change in state and also
could not poll for the actual status at will (there is no way to tell if
and when an input report will be sent).
If overloading old units is a concern, I'm afraid we're in trouble anyway
if we can create a DOS condition by doing exactly twice the number of
polls. Note that after the first (unbuffered) query for a feature report,
the subsequent polls for the same report will come from the report buffer
again.
In the way it is implemented in the trunk now, we use the input report to
tell us which feature report we should get from the UPS. Of course, this
only works if for each input report, there is a feature report with the
same report number. If this is not the case, I agree the solution is
flawed.
> The best would be to apply your change in libhid.c->HIDGetEvents() if
> udev->VendorID is different than MGE_VENDORID
I disagree here. We can easily do this in 'usbhid-ups.c', so this should
be handled there. I will make the necessary changes later today (or
tomorrow).
Best regards, Arjen
More information about the Nut-upsdev
mailing list