similar to: [nut-commits] svn commit r971 - in trunk: . drivers

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

On 6/21/07, Arjen de Korte <nut+devel at de-korte.org> wrote: > Charles, > > The same remarks as for the reconnect_ups() patch for usbhid-ups.c go for > the function with the same name in tripplite_usb.c. This is also blocking > and thereby locking up the communication between driver and server. I > don't think this is intentional, since the MAX_RECONNECT_TRIES in >

The tripplite driver was developed on a machine with a reliable serial connection, and inherited the assumption that the serial line connection would not drop, reorder, or fail character read and writes. This patch adds significantly improved failure mode handling and also does basic checks of data validity. There's also a few minor cleanups/beautification. I've tested this code on my

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.

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

I doesn't fix any problems but I think it is nicer code. :-) I don't think we want to call usb_detach_kernel_driver_np unless we claimed the device. $ diff -uw libusb.c.bak libusb.c.new --- libusb.c.bak 2010-05-11 09:35:39.000000000 -0400 +++ libusb.c.new 2010-05-11 09:32:44.000000000 -0400 @@ -206,18 +206,21 @@ upsdebugx(2, "failed to

Hi All, I've finally found solutions for my previous 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).

2011/2/15 Lupe Christoph > On Monday, 2011-02-14 at 21:54:20 -0000, Arnaud Quette wrote: > > I definitely need more info! > > please reply to ALL: > > > - what is the exact model and date of manufacturing? > > SmartUPS 300I NET. I have the serial number (GS9809283199) but no date. > it seems to be a recent model. > - are you sure this unit is ok? > >

2011/2/15 Lupe Christoph > On Monday, 2011-02-14 at 21:54:20 -0000, Arnaud Quette wrote: > > I definitely need more info! > > please reply to ALL: > > > - what is the exact model and date of manufacturing? > > SmartUPS 300I NET. I have the serial number (GS9809283199) but no date. > it seems to be a recent model. > - are you sure this unit is ok? > >

Hi all, i've read a thread about this UPS from Peter van Valderen. He tried to develop a driver for this specific type of UPS. I've downloaded nut-2.2.2 and tried to apply the patches (lakeview.patch & lakeview.v2.patch) but both resulted in rejected chunks. I've tried to ./configure with type lakeview and then a make, but the make command fails. Does anybody has any

Thank you for the rapid response. I will try and investigate getting answers to some of your points but I'm a little new to Solaris so I'll need some time. Glancing at the configure output, it looks like it built against v0.1.7 of libusb (yes i think that is derived from the one you mention), checking for libusb version via pkg-config... 0.1.7 found checking for libusb cflags... checking

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

I am having an issue running NUT and using an TrippLite OMNI900LCD. When I run ./upsdrvctl start I get : [player@V0002-S002 bin]$./upsdrvctl start Network UPS Tools - UPS driver controller 2.1.0 Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.1.0) Detected a UPS: Tripp Lite /TRIPP LITE UPS Using subdriver: TrippLite HID 0.1 (experimental) dstate_setflags: base variable

Hello, Problem: When I migrated from a DG965WH -> DP55KG motherboard, there were quite a bit of issues, host still does not reboot without special flags, e.g. reboot=a, the NIC driver is broken with the in-kernel version (the one on e1000.sourceforge) fixes that and finally my UPS USB has driver stale problems, with two issues already relating to the HW/drivers themselves it would not be

Hi, I have an MGE Ellipse UPS connected to a FreeBSD 7.0 system and it works OK to begin with but after an hour or so it dies, eg.. Starts out OK.. debug level is '2' upsdrv_initups... Checking device (0463/FFFF) (/dev/usb2//dev/ugen0) - VendorID: 0463 - ProductID: ffff - Manufacturer: MGE UPS SYSTEMS - Product: ELLIPSE - Serial Number: 000000000 - Bus: /dev/usb2 Trying to match device

Hello again! Sorry for not being able to test this before. Ulisses, please apply the patch to fix typo in my e-mail address. I've compiled it against nut-2.6.5 about 10 hours ago. It was everything fine until now. I'm seeing CHRG but the ups led wasn't blinking at all. Vendor software was strangely showing charging also. I am assuming this is expected behavior. I've set the

Hi again, On 5/22/23 18:31, Willcox David via Nut-upsuser wrote: > Hmm. Is there maybe something there already that will do this? Maybe > kind of back-handed. > > In drivers/dstate.c, I see: > > 1. In status_init(), if ?driver.flag.ignorelb? is set in the driver > state, the ?ignorelb? flag is set. > 2. In status_set(), if ignorelb is set, and the status being set

Arjen de Korte wrote: > - HIDOpenDevice() will now handle closing the device on reload if > needed, so that HIDCloseDevice() can now really close it and free > the allocated memory for report buffer and parsed report descriptor. If I remember correctly, the old behavior on "reopen" was to keep the previous report descriptor, and try to find a device that matches the previously

Hi, I have two ups (Turbo-X 1000SD, Turbo-X 1500SD). The both report themselves as # lsusb Bus 008 Device 002: ID 0001:0000 Fry's Electronics The are produced by MEC and report MEC0002 as product (although the working one report it in dmesg but not in lsusb) The 1000 (bcdUSB 1.00) works with blazer_usb while the 1500 (bcdUSB 1.10) doesn't. I am attaching lsusb and blazer_urb output