search for: libshut

Arnaud, this commit refers to files called libshut.c and libshut.h, yet no such file has been added to SVN. Perhaps take this opportunity to run "svn status" and check for other files that might be missing from SVN. -- Peter > ---------- Forwarded message ---------- > From: Arnaud Quette > To: nut-commits@lists.alioth.debian.o...

...> 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 libusb objects loose from libhid. If no HID > functions are used (megatec_usb, tripplite_usb), you no longer need to > include libhid anymore. The USB matcher functions (which were not > really HID specific functions) are now within libusb. >...

...d from r1505, /branches/Testing/packaging/debian/po/ > branches/trunk-make-package/scripts/ > - copied from r1510, /trunk/scripts/ > Modified: > branches/trunk-make-package/Makefile.am > branches/trunk-make-package/docs/macros.txt > branches/trunk-make-package/drivers/libshut.c > branches/trunk-make-package/packaging/Makefile.am > branches/trunk-make-package/packaging/debian/Makefile.am > > Modified: branches/trunk-make-package/Makefile.am > > ============================================================================== > --- /trunk/Makefile.am...

Hi Michal 2012/1/10 Michal Hlavinka <mihl-guest at alioth.debian.org> > Author: mihl-guest > Date: Tue Jan 10 09:10:04 2012 > New Revision: 3383 > URL: http://trac.networkupstools.org/projects/nut/changeset/3383 > > Log: > Creating a branch for Coverity reported problems > I'm very interested there! Have you been able to get NUT part of the Coverity Scan

...ec/nut/mge-shut -DD -a ups-filesrv01 Network UPS Tools - Generic HID driver 0.38 (2.7.2) SHUT communication driver 0.84 Warning: This is an experimental driver. Some features may not function correctly. 0.000000 debug level is '2' 0.000901 upsdrv_initups... 0.000911 libshut_open: using port /dev/cuau0 0.001034 entering shut_synchronise() 0.037281 Communication with UPS established 0.037289 entering shut_get_descriptor(n 01, 18) 0.120208 shut_wait_ack(): ACK received 0.371873 shut_wait_ack(): ACK received 9.504230 shut_wa...

...dnesday=0, thursday=0, friday=0, saturday=0; + int sunday=0, monday=0, tuesday=0, wednesday=0, thursday=0, friday=0, saturday=0; unsigned char dweek; - iw = weekn; + /* int iw; iw = weekn; */ printf( UPS_DATE, Year, Month, Day ); printf( SYS_DATE, anon, mesn, dian, seman ); Index: b/drivers/libshut.c =================================================================== --- a/drivers/libshut.c 2011-05-31 13:36:49.000000000 +0300 +++ b/drivers/libshut.c 2011-08-17 00:23:22.000000000 +0300 @@ -678,7 +678,6 @@ int shut_packet_recv(int upsfd, u_char * u_short Pos=0; u_char Retry=0; int recv...

...> Network UPS Tools - Generic HID driver 0.38 (2.7.2) > SHUT communication driver 0.84 > Warning: This is an experimental driver. > Some features may not function correctly. > > 0.000000 debug level is '2' > 0.000901 upsdrv_initups... > 0.000911 libshut_open: using port /dev/cuau0 > 0.001034 entering shut_synchronise() > 0.037281 Communication with UPS established > 0.037289 entering shut_get_descriptor(n 01, 18) > 0.120208 shut_wait_ack(): ACK received > 0.371873 shut_wait_ack(): ACK received >...

FWIW, there is precedent with libusb{1,0}, libshut and libhid which abstract NUT operations from a "backend lib" to build against; similar for serial.c used by many drivers. Take care to not conflict by filenames with "real" third-party libs used by the build - especially to avoid mixups for headers and in docs/discussion. Jim...

...Again, the only diff I see is the one pointed previously (setline...). > So, it would be great if you could test this patch (through some > reboots) and report back. > > Then, I don't think it's an issue with the device. > There is a long run TODO (mentioned in the header of libshut.c) that > is the baudrate negotiation. > The driver still communicates at 2400bauds, which is not that much for > such verbose units. We could go at least for 9600 on these units, > which is 4 times faster already. > This may cause some slowness and behavior issues as you're...

...- Generic HID driver 0.38 (2.7.2) > SHUT communication driver 0.84 > Warning: This is an experimental driver. > Some features may not function correctly. > > 0.000000 debug level is '2' > 0.000901 upsdrv_initups... > 0.000911 libshut_open: using port /dev/cuau0 > 0.001034 entering shut_synchronise() > 0.037281 Communication with UPS established > 0.037289 entering shut_get_descriptor(n 01, 18) > 0.120208 shut_wait_ack(): ACK received > 0.371873 shut_wait_ack(...

...device curDevice: { Try regex match, stop if it succeeds. } I think moving this logic up into usbhid-ups would simplify things greatly. Arjen de Korte wrote: > > Author: adkorte-guest > Date: Thu Aug 23 19:43:41 2007 > New Revision: 1073 > > Log: > * drivers/libhid.[ch],libshut.c,libusb.c: > - The 'mode' variable for HIDOpenDevice is now passed as pointer. If a device can't be re-opened (because we can't get an exact match), this will be modified to MODE_OPEN and treated as such. > - Cleaned up matcher functions. > > * drivers/usbhid-ups.[ch]:...

...t; @@ -1,3 +1,7 @@ > +Thu Feb 15 21:30:13 UTC 2007 / Peter Selinger <selinger@users.sourceforge.net> > + > + - libusb.c: fixed small memory leak, reported by Jacob Schmier. > + > Mon Feb 5 05:30:24 UTC 2007 / Peter Selinger <selinger@users.sourceforge.net> > > - libshut.c: fixed uninitialized variable > > Modified: trunk/drivers/libusb.c > ============================================================================== > --- trunk/drivers/libusb.c (original) > +++ trunk/drivers/libusb.c Thu Feb 15 22:37:04 2007 > @@ -87,8 +87,10 @@ >...

Hello Arno, > Question: have you also tested oldmge-shut? > Otherwise, that might be interesting to do so and send back the > results of these tests... Yes, I've tried this as well with worse results unfortunately. This driver seems to be even more unstable. When it gets able to set communication with the UPS (which is not always the case), it usually lost it again after a while.

...eceive size - message corrupted */ +        if (ret != buf[0]) { +            upsdebugx(1, "size mismatch: %d / %d", ret, buf[0]); +            return 0; +        } + +        /* Simple unicode -> ASCII inplace conversion +            * FIXME: this code is at least shared with mge-shut/libshut +            * Create a common function? */ +        unsigned int    di, si, size = buf[0]; +        for (di = 0, si = 2; si < size; si += 2) { + +            if (di >= (buflen - 1)) +                break; + +            if (buf[si + 1])    /* high byte */ +                buf[di++] = '?...

Did refactoring to better split library specifics, now see open/close/read lines that any library should support. Need to split into 2 files, may to go for library? On 2/22/23 20:17, Greg Troxel wrote: > Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes: > >> Nearby there's also a `generic_modbus" name. Wondering if the new driver >>

...between 2.7.1 and 2.7.2. Again, the only diff I see is the one pointed previously (setline...). So, it would be great if you could test this patch (through some reboots) and report back. Then, I don't think it's an issue with the device. There is a long run TODO (mentioned in the header of libshut.c) that is the baudrate negotiation. The driver still communicates at 2400bauds, which is not that much for such verbose units. We could go at least for 9600 on these units, which is 4 times faster already. This may cause some slowness and behavior issues as you're experiencing, under some circ...

...ain, the only diff I see is the one pointed previously (setline...). > So, it would be great if you could test this patch (through some > reboots) and report back. > > Then, I don't think it's an issue with the device. > There is a long run TODO (mentioned in the header of libshut.c) that is > the baudrate negotiation. > The driver still communicates at 2400bauds, which is not that much for > such verbose units. We could go at least for 9600 on these units, which is > 4 times faster already. > This may cause some slowness and behavior issues as you're ex...

...eviously >> (setline...). >> So, it would be great if you could test this patch (through some >> reboots) and report back. >> >> Then, I don't think it's an issue with the device. >> There is a long run TODO (mentioned in the header of libshut.c) >> that is the baudrate negotiation. >> The driver still communicates at 2400bauds, which is not that >> much for such verbose units. We could go at least for 9600 on >> these units, which is 4 times faster already. >> This may cause some slownes...

On 1/23/07, Henning Brauer <hb-nut@bsws.de> wrote: > good new first: the megatec driverin 2.0.5 now works with the Online > Xanto S3000R here - well, for the very basics. > > the UPS has NO way ofidentifying itself. It also does not respond to > the power ratings query ("F"). I previously used a hacked up fentonups > driver. This means the driver cannot figure out

...(AM_CFLAGS) $(LIBUSB_CFLAGS) bcmxcp_usb_LDADD = $(LDADD_DRIVERS) $(LIBUSB_LIBS) +megatec_usb_SOURCES = megatec.c megatec_usb.c libusb.c +megatec_usb_CFLAGS = $(AM_CFLAGS) $(LIBUSB_CFLAGS) +megatec_usb_LDADD = $(LDADD_DRIVERS) $(LIBUSB_LIBS) + # USB-over-serial newmge_shut_SOURCES = newhidups.c libshut.c libhid.c hidparser.c mge-hid.c newmge_shut_CFLAGS = $(AM_CFLAGS) -DSHUT_MODE diff -Naur drivers_orig/megatec.c drivers/megatec.c --- drivers_orig/megatec.c 2006-12-04 13:08:58.000000000 +0300 +++ drivers/megatec.c 2006-12-03 16:02:35.000000000 +0300 @@ -23,7 +23,6 @@ #include "main.h&q...