search for: libusb_open

...compile: [root@mypbx drivers]# make newhidups gcc -I../include -O -Wall -Wsign-compare -o newhidups newhidups.o main.o dstate.o \ ../common/state.o ../common/upsconf.o ../common/parseconf.o \ ../common/common.o libhid.o libusb.o hidparser.o libusb.o(.text+0x1c): In function `libusb_open': : undefined reference to `usb_init' libusb.o(.text+0x21): In function `libusb_open': : undefined reference to `usb_find_busses' libusb.o(.text+0x26): In function `libusb_open': : undefined reference to `usb_find_devices' libusb.o(.text+0x2b): In function `libusb_open':...

..../../drivers/libusb.c; \ then mv -f ".deps/libusb.Tpo" ".deps/libusb.Po"; else rm -f ".deps/libusb.Tpo"; exit 1; fi ../../drivers/libusb.c:93: error: expected declaration specifiers or '...' before 'HIDDevice_t' ../../drivers/libusb.c: In function 'libusb_open': ../../drivers/libusb.c:138: error: 'curDevice' undeclared (first use in this function) ../../drivers/libusb.c:138: error: (Each undeclared identifier is reported only once ../../drivers/libusb.c:138: error: for each function it appears in.) ../../drivers/libusb.c: At top level: ../../...

...problems. But since this includes changes in the shared files, I'd like to discuss them here. 1. Driver restart problem. When I start the driver for the first time, everything is ok. But when I want to restart it, problems begin. The driver fails to read Report descriptor for the second time (libusb_open is used to open the device). This is caused by my particular UPS model's allergy. I can read the Report descriptor only once and only before reading any "special" string descriptors. After that I can do everything else without troubles. But if I attempt to read it after reading string...

...low a significantly improved patch. The main difference is that all calls to usb_get_string_.. have been wrapped in a new function nut_usb_get_string()  that is implemented in libusb.c This was necessary in order to make the bufflen_fix available in libusb.c where usb_get_string() is called in libusb_open() This wrapper function mops up and hides all the work concerned with handling of langid and bufflen. The static vars langid_fix and buflen_fix are accordingly moved to libusb.c regards, Ian diff --git a/drivers/libusb.c b/drivers/libusb.c index 0eb054a7..42f1b93f 100644 --- a/drivers/libu...

I think having this logic buried within libhid/libusb (libusb:libusb_open(), line 179 to 206) is ultimately a mistake, albeit one that I am probably responsible for. Would it make sense to confine libhid to low-level operations, and leave the decision of trying to reopen vs. retrying to open to the high-level driver, in this case usbhid-ups? I envision that the code in...

...pr 16 18:29:40 | libusb_get_report: No error (and so on and so on) I found the location where this is happening and did the following patch: diff --git a/drivers/libusb.c b/drivers/libusb.c index 50bfc7f..3eae478 100644 --- a/drivers/libusb.c +++ b/drivers/libusb.c @@ -353,7 +353,7 @@ static int libusb_open(usb_dev_handle **udevp, USBDevice_t *curDevice, USBDevice */ static int libusb_strerror(const int ret, const char *desc) { - if (ret > 0) { + if (ret >= 0) { return ret; } I've been running that patched version since April 16th, monitoring two...

...nd /dev/usb4 > usb_os_find_devices: couldn't open device /dev/ugen0: Device busy > No appropriate HID device found > upsdrv_updateinfo... > Got to reconnect! Maybe FreeBSD requires that the existing connection to a USB device is closed before it can be opened again. Currently the libusb_open() function (in 'drivers/libusb.c') only closes an existing connection if SUN_LIBUSB is defined (lines 106-109) to work around a double free corruption in Linux if devices are detached (since the kernel will do this already). But it could very well be that this is required in FreeB...

...lite_usb.c,Makefile.am: > - Applied the change above. > > * drivers/usbhid.[ch]: > - The HIDOpenDevice() and HIDCloseDevice() functions no longer exist. > These are replaced by direct calls to the communication subdrivers. > - The driver now gets a callback from libshut_open() and libusb_open() > when a report descriptor has been retrieved from the USB/SHUT device > and parses it and then makes a descision on whether this device is > acceptable or not. If not, the next device that matches will be tried. > > Apologies for the *really* big update, but the above required &gt...

...Tue Sep 13 20:50:14 UTC 2005 / Peter Selinger <selinger@users.sourceforge.net> - newhidups: added Belkin support. Also added some new variables and instant commands (some of these were already used by other drivers); see new-names.txt. - newhidups: fixed return value bug in libusb.c:libusb_open() when no device was found. Please let me know if there's anything you don't like. Notes: * I documented the new variables and instant commands in new-names.txt. Some of them already existed in other drivers, but had not yet been documented. * One exception is the variable ups....

...will look for a device that matches the previous manufacturer, model, and serial number. Therefore, if there is more than one UPS attached, one is guaranteed to get the same one. Also, when I unplug and reattach my UPS, my operating system (Linux 2.6.4) attaches a kernel driver to it. The original libusb_open() function would return too early when reopening a device, and in particular, it would not try to detach any kernel drivers. With this patch, reopening is treated in the same way as opening (and works much better for me). Finally, calling usb_release_interface() often caused my driver process to g...

...int? serial.c: In function ?ser_send?: serial.c:289: warning: format ?%d? expects type ?int?, but argument 3 has type ?long unsigned int? serial.c: In function ?ser_comm_fail?: serial.c:511: warning: format ?%d? expects type ?int?, but argument 3 has type ?long unsigned int? libusb.c: In function ?libusb_open?: libusb.c:289: warning: format ?%d? expects type ?int?, but argument 4 has type ?long unsigned int? libusb.c: In function ?libusb_get_string?: libusb.c:376: warning: format ?%i? expects type ?int?, but argument 5 has type ?size_t? G Evans -------------- next part -------------- Network UPS Tools...