selinger at mathstat.dal.ca
Mon Aug 20 20:40:30 UTC 2007
thanks for today's changes to usbhid-ups. These are very sensible
changes and were long overdue. It was of course suboptimal to parse
the usage strings each time, rather than doing it once and putting
them in a data structure. I am beginning to believe that when you are
finished, usbhid-ups will actually be (gasp) elegant!
The difference between Features and Inputs has been on my list of
stuff to look into for a while. When I started hacking this driver, I
didn't understand the difference, that one is for polled data and the
other for interrupted data. The USB specification is not very crisply
written when it comes to this point. When I finally understood the
difference, I had no more energy to program.
If I remember correctly, the report buffer does not handle Features
and Inputs correctly. Technically, Inputs don't need to be buffered,
since they are never polled. However, if an input arrives, then a
later poll of the same variable should return the current value, not
the one from a previous Feature report. So interrupt Inputs are
currently stored in the report buffer, overwriting the corresponding
This is fine as long as Input and Feature reports are identical and
are numbered identically, which is the case for all UPS that I have
seen so far, but is perhaps not required by the USB standard.
A cleaner solution would be not to write interrupt transfers to the
buffer, but to mark the entire report buffer as expired after an
interrupt transfer occurs.
More information about the Nut-upsdev