similar to: possible code change to drivers/libusb.c

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 usbhid-ups:reconnect_ups()

Sorry about the noise guys. Below 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

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

> next_device: > + free(curDevice->Vendor); > + free(curDevice->Product); > + free(curDevice->Serial); > + free(curDevice->Bus); > usb_close(udev); > udev = NULL; > } Wouldn't it be necessary to check whether there is anything to free or not? Vendor, Product and Serial are set conditionally. In the lines upsdebugx(2, "-

Description: Fix warning: variable set but not used [-Wunused-but-set-variable]. bugs.debian.org/633756. Related drivers were not tested. Last-Update: Sat, 13 Aug 2011 14:04:48 +0300 Index: b/drivers/belkinunv.c =================================================================== --- a/drivers/belkinunv.c 2011-05-31 13:36:49.000000000 +0300 +++ b/drivers/belkinunv.c

I recently installed NUT 2.4.3 and found that the USB drivers were logging an insane amount of data to syslog: usbhid-ups | daemon debug | Apr 16 18:29:40 | libusb_get_report: No error usbhid-ups | daemon debug | Apr 16 18:29:40 | libusb_get_report: No error usbhid-ups | daemon debug | Apr 16 18:29:40 | libusb_get_report: No error usbhid-ups | daemon debug | Apr 16 18:29:40 |

> Author: aquette > Date: Thu Jun 21 07:43:46 2007 > New Revision: 971 > > Log: > fix communication lost status handling > > Modified: > trunk/ChangeLog > trunk/drivers/usbhid-ups.c > > Modified: trunk/ChangeLog > ============================================================================== > --- trunk/ChangeLog (original) > +++ trunk/ChangeLog

Earlier this year, I added a patch to my local NUT tree to additionally print the value of usb_strerror() if usb_clear_halt() failed. (Ignore the commented-out goto.) Since these messages are at the LOG_ERR level, should we add usb_strerror() to all of the calls in nut_usb.c? diff --git a/drivers/nut_usb.c b/drivers/nut_usb.c index 494a1fa..4ca2691 100644 --- a/drivers/nut_usb.c +++

Hi, I'm having a hard time configuring a Mustek Powermust 600VA ups to work via USB with nut. I read somewhere that nut works OK via the rs232 cable, but unfortunately I don't have a COM port in my computer. The kernel detects the ups as an Xbox pad :) and loads the xpad module. I tried running /lib/nut/megatec with different /dev/ttySx but it displays megatec protocol UPS was not

Joel Peshkin wrote: > > I hacked in the following additonal changes... > > Index: newhidups.c > =================================================================== > RCS file: /cvsroot/nut/nut/drivers/newhidups.c,v > retrieving revision 1.1.1.1.8.6.2.21 > diff -u -r1.1.1.1.8.6.2.21 newhidups.c > --- newhidups.c 7 Nov 2005 22:14:20 -0000 1.1.1.1.8.6.2.21 > +++

Hello, I have been trying to get a TrippLite Internet Office 750 UPS to talk to my Linux PBX for a couple of evenings now and I'm getting nowhere... I tried searching the list archives before posting here (I'm sure I'm not the first one to try to get this going) but they seem to be offline... The UPS is unfortunately USB based but I thought I'd give it a try anyway. Here is

Description: Replace many usleep and some sleep calls with nanosleep. usleep is stated in its manual page as removed by POSIX. Contrary to its predecessors, nanosleep semantics is well defined. The replacement, which is mostly in drivers, is untested. Supplements http://bugs.debian.org/633791. Last-Update: Sat, 13 Aug 2011 14:04:48 +0300 Index:

I get the following error on r809 (but it looks like the code change happened here). Does HIDDevice_t need to be defined/changed in one of the headers? if gcc -DHAVE_CONFIG_H -I. -I../../drivers -I../include -I../../include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -DINET6 -O2 -D_REENTRANT -DNETSNMP_USE_INLINE -Wall -Dlinux -I.

Hi! I've recently come into to the possesion of a couple of Belkin Omniguard 3200 UPS's. Given the horrible apache/java based software they come with, I decided to see if I cannot get them to work with NUT. To cut a long story short, they work out to be SEC -based, and extensively modifying the nut-1.4 driver code to come up with the attached two files. I've marked them

Oi, quando abri a minha caixa adsl e vi o famoso Octal, assustei-me logo, no entanto, depois de ler o teu artigo, fiquei descansado, mas os problemas vieram a seguir... segui o howto por completo, instalei tudo, mas quando vou compilar o amedyn é reportado o seguinte erro : [root@portatil paulo]# cd amedyn [root@portatil amedyn]# make cd init && make clean make[1]: Entering directory

I got sick & tired of constant power outages with no warning, so when I saw various UPSes at the store, I decided to get one, and the one I got was a model 200897 from Newpoint (a.k.a. Power Sentry). A couple of days later the power went out and I decided to use the opportunity to hook up the UPS. I added up the wattages of the equipment I would be connecting, and found that the only way I

Hello again all. I am trying to use USB functions (non-HID) and I get a linker error for functions that are in the included usb-common.h file. Specifically, at the start, these functions: - warn_if_bad_usb_port_filename - nutusb_open - is_usb_device_supported Clearly the headers are there or I don't think the driver would compile. Can someone point me in the right direction please? Thank

On Sep 15, 2015, at 9:31 PM, Charles Lepple <clepple at gmail.com> wrote: > >> Trying to track down the source of the problem, I checked Yast to make sure I had at least 0.1.8 version for libusb. I saw this (attached photo). Is it then actually using ?compat instead of the ?real? libusb? And is that a problem? > > You're right, both the -compat and real libusb