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

Citeren Arnaud Quette <aquette op alioth.debian.org>: > +.SS "Repetitive timeout and staleness" > + > +Some models tends to be unresponsive with the default polling frequency. > +The result is that your system log will have lots of messages like: > +.nf > + usb 2-1: control timeout on ep0in > + usb 2-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq

Citeren Arnaud Quette <aquette.dev at gmail.com>: > Author: keyson-guest > Date: Wed Feb 4 15:03:36 2009 > New Revision: 1765 > > Log: > - Added mocrodowell.c/h into drivers/. add man/microdowell.8. Adjusted > drivers/Makefile.am and man/makefile.am. Adjusted the code for 2.4.0 in the > microdowell.c. Besides the things already mentioned by others and the obvious

> 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

Gentlemen, I think this question is mainly for Arnaud again: When I run my UPS directly with newhidups -D -D -D, with no data changes, and I then observe the interaction with my UPS (still Back-UPS ES 650 FW:818.w1.D USB FW:w1), I see the updateinfo cycle through 3 different forms: (1) a (2 bytes) => 06 08 notification that provides one item: UPS.PowerSummary.APCStatusFlag Note that

Citeren Michal Soltys <msoltyspl-guest at alioth.debian.org>: > @@ -417,10 +414,12 @@ > if (flags & SER_CC) { > iset = IGN_CCCHARS; > aset = ""; > + sec = 6; usec = 0; > } > if (flags & SER_CS) { > iset = IGN_CSCHARS; > aset = ""; > + sec = 6; usec = 0; > } > > memset(buf, '\0', buflen);

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

On 5/23/07, Kjell Claesson <keyson-guest at alioth.debian.org> wrote: > Author: keyson-guest > Date: Wed May 23 21:12:51 2007 > New Revision: 915 > > Log: > - Enabled requested Alarm function in bcmxcp.c > > Modified: > trunk/ChangeLog > trunk/drivers/bcmxcp.c Looks like this breaks when HAL is enabled. At the end of:

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

This is 2nd version of the earlier patch featuring a few new features and fixes to the apcsmart driver, following the remarks in: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02294.html Major changes from v1: - handle battery.charge and battery.runtime checks at main.c level - handle "immutable but writable" conflict gracefully at driver level -

Hmm. Is there maybe something there already that will do this? Maybe kind of back-handed. In drivers/dstate.c, I see: In status_init(), if ?driver.flag.ignorelb? is set in the driver state, the ?ignorelb? flag is set. In status_set(), if ignorelb is set, and the status being set (presumably from the UPS) is LB, it?s ignored. In other words, LB reported by the UPS is ignored. In status_commit(),

Hi again, I've succeeded in compiling the svn trunk with the automake tools and wish to say thank you to Charles Lepple for his help. After fixing some parameters in the hotplug script I can now get access to the UPS on /dev/usb/hiddev0 (I added productid and vendorid of my ups to the usermap). I've decided to try the newhidups driver with -x generic parameter and got this response :

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

Citeren Arjen de Korte <adkorte-guest at alioth.debian.org>: > Author: adkorte-guest > Date: Sun Nov 16 13:00:30 2008 > New Revision: 1560 > > Log: > Generated by libtool and should not be versioned. > > Modified: > trunk/ (props changed) Right, that didn't work out quite the way I intended. Can someone please set the svn:ignore property on

Citeren Arnaud Quette <aquette op alioth.debian.org>: > Author: aquette > Date: Sat Dec 11 12:31:21 2010 > New Revision: 2731 > URL: http://trac.networkupstools.org/projects/nut/changeset/2731 > > Log: > Complete the list of Subversion ignored files, with AsciiDoc > generated contents (no functional changes) Is there a particular reason for having both the man/

Citeren Arjen de Korte <adkorte-guest op alioth.debian.org>: > Log: > Use the 'nss_compat_ossl' compatibility layer to use the Mozilla NSS > library instead of OpenSSL (we might want to include native support > in the future, but this will at least allow a quick migration for > testing purposes) I don't recall that we ever discussed the possibility of

Citeren Arjen de Korte <adkorte-guest at alioth.debian.org>: > Author: adkorte-guest > Date: Thu Jan 15 11:54:05 2009 > New Revision: 1728 > > Log: > Another stab at this. > > Modified: > trunk/tools/Makefile.am And failing miserably... :-( Can someone more fluent in 'autotoolish' fix this problem? Currently the BuildBot is broken by update r1718

Hello gents, while getting rid of gettimeofday, I've spotted something I'd like to discuss in implementation of socket polling in driver/main.c::main and driver/dstate.c::dstate_poll_fds My observations follow: 1/ I'm not very happy with the poll mechanism design as whole. I mean, typically, you implement the poll as { poll(); process(); }* loop; in pseudo-code: shut_down = false;

Citeren Arnaud Quette <aquette.dev at gmail.com>: > Author: aquette > Date: Sat Nov 15 22:47:26 2008 > New Revision: 1557 > > Log: > GNU libtool update > > Modified: > trunk/ChangeLog > trunk/configure.in > trunk/ltmain.sh I think 'ltmain.sh' is a generated file (at least, I hope it is), this change severely broke compilation here. I had to

Arjen de Korte wrote: > Author: adkorte-guest > Date: Mon Jun 18 09:03:18 2007 > New Revision: 964 > > Log: > additional debug info in case commands fail > > Modified: > trunk/ChangeLog > trunk/drivers/megatec.c > > Modified: trunk/ChangeLog Arnaud, Carlos, I'd like to backport this change to Testing as well. Intermittent startup problems for

Citeren Arjen de Korte <adkorte-guest op alioth.debian.org>: > Author: adkorte-guest > Date: Sat Jan 23 10:06:51 2010 > New Revision: 2260 > > Log: > Need to define _XOPEN_SOURCE for strptime() prototype in glibc2 > > Modified: > ? ? trunk/drivers/mge-hid.c Arnaud, Apparently this solves the problem for the strptime() function, but now breaks the snprintf()