[Nut-upsdev] Introductions, questions
twaffle at gmail.com
Thu Sep 22 16:49:03 UTC 2011
On Wed, Sep 21, 2011 at 11:25 PM, Charles Lepple <clepple at gmail.com> 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
>> 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
>> 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
> 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?
More information about the Nut-upsdev