On Wed, Sep 21, 2011 at 11:25 PM, Charles Lepple <[email protected]> wrote: > This is with usbhid-ups, right? (Older SMART2200RMXL2U models used > tripplite_usb, which is completely different code.)
Correct. The current models use the hid driver. > The sub-driver (drivers/tripplite-hid.c) was probably initially generated > from feeding the "explore" output to scripts/subdriver/path-to-subdriver.sh, > so you could try that route and compare to the current tripplite-hid.c. Yes, this is exactly what it did, and how it looks. > Or, if the HID usage paths indicated by "explore" look similar to the ones > listed after "#ifdef USBHID_UPS_TRIPPLITE_DEBUG", you could define that > preprocessor directive and see the output in upsc. > > There are a number of items under UPS.OutletSystem.Outlet, so the latter > method might be sufficient. Yes, what I'm doing is figuring out what some of the unknowns really are. I believe I've found several. Specifically: UPS.OutletSystem.Outlet.ffff0095 = bitmask available for control (i.e., in my case 7) 7 = 00000111 UPS.OutletSystem.Outlet.ffff0096 = Bitmask of which loads to be on/of (7 = All On, 0 = all off, 1 = Load 1 on, 2 & 3 off) UPS.OutletSystem.Outlet.ffff0098 = Bitmask of which loads are currently on/off I'll end up confirming some of the other unknown ones as well, but these are the 3 of the major ones I care about. The supporting load info would be nice if I can manage to figure it out. >> 0.077393 libusb_get_report: error sending control message: Broken >> pipe >> 0.077398 Can't retrieve Report 6b: Broken pipe > > Hmm, I don't see the code path to get that error. libusb_get_report() has an > explicit test for EPIPE, and returns zero. I noticed that, I'll see if I can't debug it further. I'm wondering if the ecode returned is different then EPIPE, but has a simular if not identical libusb error string. I suspect this is the case, as it is not only doing this unsupported requests, but for other requests as well. >> I'm currently using 2.6.0, as I need to be able to add these changes >> to a known debian package (get source, make patch, rebuild deb >> package). > I think the changes should be applicable to both 2.6.0 and later versions in > that series. The driver hasn't changed much from 2.4+, shouldn't be an issue. So as a matter of reporting, what is the best way to give information for inclusion in future releases? And better, who to give it to? The list as a whole, or specific driver maintainers? -- -- Thomas _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
