[Nut-upsdev] Introductions, questions

[Thomas Charron]

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
>> 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