2012/8/15 Martyn Hill <[email protected]> > Hi Arnaud! >
Hi Martin > > On 14/08/2012 21:50, Arnaud Quette wrote: > > > > 2012/8/14 Martyn Hill <[email protected]> > >> On 11/08/2012 21:27, Arnaud Quette wrote: >> >> >> >> 2012/8/11 Martyn Hill <[email protected]> >> >>> On 11/08/2012 21:00, Chris Rees wrote: >>> >>>> On 11 August 2012 20:52, Martyn Hill <[email protected]> >>>> wrote: >>>> >>>>> On 11/08/2012 20:48, Chris Rees wrote: >>>>> >>>>>> On 11 August 2012 20:29, Martyn Hill <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> On 11/08/2012 20:24, Chris Rees wrote: >>>>>>> >>>>>>>> On 11 August 2012 19:14, Arnaud Quette <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> 2012/8/11 Chris Rees <[email protected]> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11 Aug 2012 13:03, "Martyn Hill" <[email protected] >>>>>>>>>> > >>>>>>>>>> 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...)
_______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
