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

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.

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()

> 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

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

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

Arnaud, you changed the "if" part, perhaps you'd like to change the "else" part, too? Changing the output format of HIDDumpTree() has the potential to break the functionality of scripts/subdriver/path-to-subdriver.sh; I don't think it does in this instance, but I have not checked it. Perhaps it would be good to add a comment in the source code as a caution. -- Peter

Hi Arjen, there is a small glitch with r1376: upsd.c: In function ?mainloop": upsd.c:857: warning: too few argument for the format 2008/3/18, Arjen de Korte <adkorte-guest at alioth.debian.org>: > Author: adkorte-guest > Date: Tue Mar 18 19:59:15 2008 > New Revision: 1376 > ... > + if (ret == 0) { > + upsdebugx(2, "%s: no data

> Author: adkorte-guest > Date: Mon Feb 25 20:40:41 2008 > New Revision: 1334 > > Log: > Allocate twice the maximum number of reports we expect (MAX_REPORTS), to > allow for bogus/duplicate reports. Retrospectively, this is gross hack at best and probably only good to fix the problem temporarily. I think I have a better solution available (in a similar way as r1210, that was

> ---------- Forwarded message ---------- > From: Arjen de Korte > To: nut-commits at lists.alioth.debian.org > Date: Mon, 27 Aug 2007 18:33:00 +0000 > Subject: svn commit r1076 - in trunk: . drivers > Author: adkorte-guest > Date: Mon Aug 27 18:33:00 2007 > New Revision: 1076 > > Log: > * drivers/libhid.[ch],libshut.[ch],libusb.[ch]: > - Cut the libshut and

> Author: adkorte-guest > Date: Mon Mar 10 10:08:08 2008 > New Revision: 1372 > > Log: > - allow subdrivers to override the 'shutdown.(return|stayoff)' commands > that are 'composed' in the driver > - add new 'load.(on|off).delay' commands to allow the above (will > implicitly define 'load.(on|off)' command with a delay value of

Citeren Arnaud Quette <aquette at alioth.debian.org>: > Author: aquette > Date: Mon May 18 12:14:54 2009 > New Revision: 1846 > > Log: > Enable timestamp on output messages (format "%H:%M:%S: msg") I think this should only be done for messages that are sent to stderr. In most cases, syslog will already prepend a timestamp, so this is probably redundant.

> - drivers/dstate-hal.[ch]: added sleep here, to limit the polling rate > (previously, the driver would completely ignore the poll interval and > would run upsdrv_updateinfo() without any delay in between) > > The changes to dstate-hal.[ch] should probably be backported to Testing > ASAP, since ignoring the poll_interval is not a good idea (you'll be > basically polling

Hi all, I posted originally here last week: https://alioth-lists.debian.net/pipermail/nut-upsuser/2023-October/013461.html Since then, I've been building and testing from source following the instructions a helpful reply in the above thread pointed out. The original problem is I've got one of these arduino HID power devices, as a project for a DIY UPS at home. This arduino is a composite

> Author: agordeev-guest > Date: Wed Oct 3 00:09:21 2007 > New Revision: 1136 > > Log: > - drivers/megatec_usb.c: added ability to do subdriver-specific > initialization, and moved some shared code to agiler init function > since krauler doesn't need it. [...] I'm not very thrilled about this patch: 1) Down at the subdriver level, one shouldn't use

Thank you for the investigation! I've thought about this in vague terms, i.e. that numbers like this should be configurable, but did not have time to read into USB-related libraries and specs to make any more specific sense of it (and the libusb code is not mine except the recent layers of cleanup). I guess I did not even realize that there is more than the regularly mentioned "interface

> I see. For IP4 addresses, will ups@192.168.0.1:3493 still work as > expected? -- Peter Yes. Whatever is between '@' and the optional ':<portnumber>' is passed as hostname. Brackets (in case of domain literals) are removed. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57

> * are you sure you want to use fprintf(stderr, ...) in a library? > This doesn't seem like a good idea to me. Wouldn't it be more > consistent to extend upscli_errlist[] ? Errorcodes are passed in 'ups->upserror' (and 'ups->syserrno'). Uh oh, we don't have a connection to an UPS yet when we call upscli_splitname() or upscli_splitaddr(). The

> I see. For IP4 addresses, will ups@192.168.0.1:3493 still work as expected? -- Peter Yes. Whatever is between '@' and the optional ':<portnumber>' is passed as hostname. Brackets (in case of domain literals) are removed. One thing to note, in the released versions the use of IPv4 addresses for a hostname (in upsclient.c) is not guaranteed to work (according to POSIX):

> Author: adkorte-guest > Date: Mon Jun 25 19:26:09 2007 > New Revision: 988 > > Log: > Update to reflect changes in the way we deal with dstate_dataok() and > dstate_datastale(). > > Historically it was needed to call dstate_dataok() regularly, to prevent > staleness warnings. This is no longer needed, now the server will PING > drivers it has not heard of

> Author: adkorte-guest > Date: Fri Feb 8 07:09:51 2008 > New Revision: 1285 > > Log: > Cleanup and change the arguments to the upsdebug_hex() function so that it > no longer requires casting to an unsigned char. > > Modified: > trunk/ChangeLog > trunk/common/common.c > trunk/include/common.h > > Modified: trunk/ChangeLog I would like to do