[Nut-upsuser] Zigor Ebro 650 compatibility

[Arnaud Quette]

2012/8/15 Martyn Hill <martyn.joseph.hill at gmail.com>

>  Hi Arnaud!
>

Hi Martin


>
> On 14/08/2012 21:50, Arnaud Quette wrote:
>
>
>
> 2012/8/14 Martyn Hill <martyn.joseph.hill at gmail.com>
>
>>   On 11/08/2012 21:27, Arnaud Quette wrote:
>>
>>
>>
>> 2012/8/11 Martyn Hill <martyn.joseph.hill at gmail.com>
>>
>>>  On 11/08/2012 21:00, Chris Rees wrote:
>>>
>>>> On 11 August 2012 20:52, Martyn Hill <martyn.joseph.hill at gmail.com>
>>>> wrote:
>>>>
>>>>> On 11/08/2012 20:48, Chris Rees wrote:
>>>>>
>>>>>> On 11 August 2012 20:29, Martyn Hill <martyn.joseph.hill at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On 11/08/2012 20:24, Chris Rees wrote:
>>>>>>>
>>>>>>>> On 11 August 2012 19:14, Arnaud Quette <aquette.dev at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2012/8/11 Chris Rees <utisoft at gmail.com>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11 Aug 2012 13:03, "Martyn Hill" <martyn.joseph.hill at gmail.com
>>>>>>>>>> >
>>>>>>>>>> wrote:
>>>>>>>>>> (...)
>>>>>>>>>>
>>>>>>>>>>  My FreeBSD 8 appears to be running/linking against libusb20 - the
>>>>>>>>>>> 'new'
>>>>>>>>>>> one...
>>>>>>>>>>>
>>>>>>>>>> We killed the old one a long time ago ;)
>>>>>>>>>>
>>>>>>>>> not sure of what you exactly mean here!
>>>>>>>>> libusb 0.1 is still avail in FBSD 9:
>>>>>>>>> http://www.freebsd.org/cgi/ports.cgi?query=libusb&stype=all
>>>>>>>>>
>>>>>>>>> Update: while reading the comment on  libusb1.0 website [1], I now
>>>>>>>>> understand why you're using "2.0"!
>>>>>>>>>
>>>>>>>>> "FreeBSD 8 and above include a FreeBSD-specific reimplementation
>>>>>>>>> of the
>>>>>>>>> libusb-1.0 API, so your applications will probably work there too.
>>>>>>>>> The
>>>>>>>>> source code for this library can be found:
>>>>>>>>> http://svnweb.freebsd.org/base/head/lib/libusb/"
>>>>>>>>>
>>>>>>>>> but still, your "killing" comment leave me in a doubtful state ;)
>>>>>>>>>
>>>>>>>>>  Oops, haha, sorry, that's right; we didn't kill it, just switched
>>>>>>>> default, and loads of ports needed modification over it.
>>>>>>>>
>>>>>>>
>>>>>>> Do we know how to 'use' the legacy libusb 0.1 in FreeBSD?
>>>>>>>
>>>>>> As Arnaud pointed out, they're still there; including usb.h uses the
>>>>>> libusb 0.1 compat layer.
>>>>>>
>>>>>
>>>>> So, does that mean I would need to recompile nut, but link it against
>>>>> libusb
>>>>> 0.1 compat layer?
>>>>>
>>>>> If so, how would I go about that?
>>>>>
>>>> My understanding is that you shouldn't need to be concerned with
>>>> that-- NUT uses libusb-0.1, which is emulated in FreeBSD with
>>>> libusb20.  Thus changing the version to link with makes no sense.
>>>>
>>>> Chris
>>>>
>>>
>>>  OK, so back to square one... I guess testing the UPS on a currently
>>> supported is the next most sensible step, then - at least to determine if
>>> the driver really works with the Zigor...
>>
>>
>> the good is that it's a HID device, as you've guessed, supported by
>> usbhid-ups.
>> though the device has a bad/buggy implementation:
>> - vendorid/productid,
>> - and the main "UPS", coded as 00860004 instead of 00840004.
>> I'll have to create a fix for this one.
>>
>>
>>  I patched your drivers/libhid.c and recompiled, which atleast allowed
>> the incorrect code to be recognised as 'UPS'. Obviously, not enough to get
>> things working...
>>
>>
>>
>> the bad news is the I/O errors: until it's fixed, we're stuck!
>> you should still be able to force compilation/link against the actual
>> libusb 0.1 (ie not 2.0 compat), and should really do it.
>>
>>
>>  Can't figure out how to do this and, in the light of Chris's comments
>> previously, not sure it's supposed to be necessary...
>>
>>  a 2nd thing to check is uhid. iirc, you should either unload it or
>> blacklist the dev or something like that...
>>
>>
>>  I recompiled my FreeBSD kernel without uhid.ko and can succesfully
>> load/unload uhid as a module now.
>>
>>
>> cheers,
>> Arno
>>
>>
>> So, stalled for now, until I can figure how to link against libusb01 on
>> FreeBSD... Not giving up hope yet, but no amount of googling is shinng a
>> light on this point. :-(
>>
>> Thanks for your help thus far.
>>
>
> send in your configure log and config.log (compressed) to see what gets
> detected at compile time.
>
>
> config.log attached... Not sure what you mean by my 'configure log' that
> is distinct from config.log - could you please clarify?
>
>
perfect, thanks.
"configure log" was referring to "configure output", which is just a user
version of config.log (less details, more readable for an overview)
it's a laziness from me, using this for a first "5 seconds" check, to see
if there's a need to go in depth...

 I'd also like to see the output of 'pkg-config --list-all',
> Attached...
>

I see no libusb out there, so we are using the fallback CFLAGS / LIBS values


>
>  and still the ldd output (you never sent it iirc)
>
>   Oh yes - ldd against blazer_usb:
>
> KRISHNA# ldd /usr/local/libexec/nut/blazer_usb
> /usr/local/libexec/nut/blazer_usb:
>         libusb.so.2 => /usr/lib/libusb.so.2 (0x2809a000)
>         libm.so.5 => /lib/libm.so.5 (0x280a8000)
>         libthr.so.3 => /lib/libthr.so.3 (0x280c2000)
>         libc.so.7 => /lib/libc.so.7 (0x280d7000)
>
> and usbhid-ups:
>
> KRISHNA# ldd /usr/local/libexec/nut/usbhid-ups
> /usr/local/libexec/nut/usbhid-ups:
>         libusb.so.2 => /usr/lib/libusb.so.2 (0x280a2000)
>         libthr.so.3 => /lib/libthr.so.3 (0x280b0000)
>         libc.so.7 => /lib/libc.so.7 (0x280c5000)
>
> Is that what you needed?
>

yup, thanks.
I interpret this as "libusb 2 reimplementation on BSD also includes a
libusb 0.1 compat, beside of the 1.0 one".
as an example, on a Linux system:

$ ldd drivers/usbhid-ups
    linux-gate.so.1 =>  (0xb77b5000)
    libusb-0.1.so.4 => /lib/libusb-0.1.so.4 (0xb778b000)
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7770000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75f1000)
    /lib/ld-linux.so.2 (0xb77b6000)

beside of the recompilation with libusb 0.1, I'm still interested in seeing
a verbose USB log from the current driver.
so if "export USB_DEBUG=3" doesn't work, there should be another way to do
the same thing.

cheers,
Arno (on holidays for 3 weeks, as of now...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20120817/7deec36e/attachment-0001.html>