similar to: Changes to usbhid-ups driver

While working on the mge-hid subdriver, I wanted to add the 'beeper.mute' command. Unfortunately, the description I intended to use was used already by the 'beeper.off' instcmd: CMDDESC beeper.off "Temporarily mute the UPS beeper" Now of course we could add another instcmd 'beeper.reallyoff', but instead I would prefer to bite the buller and do the following:

while finishing some work on the HAL integration (I'm now mapping DBus method with NUT commands, to allow at least the final UPS poweroff), I was horrified to realize (and so late) the changes in usbhid-ups->upsdrv_shutdown(). We've lost a lot there, but making a generic code, instead of keeping the subdrivers delegation. For example, the shutdown.return command (which is or should be

To people with APC, CyberPower, Belkin and TrippLite UPS'es and using the 'usbhid-ups' driver. There are some concerns that the usbhid-ups driver is not acting as it is supposed to do. Could you run the following command (as root and with the mains plugged) and check if the UPS powers back on automatically? upsmon -c fsd I think we should *not* release nut-2.2.1 if we're not

I don't understand how the info_len element from the hid_info_t structure is used in usbhid-ups. It appears to me that the only use of this element is now to indicate the length of the string: > float info_len; /* if ST_FLAG_STRING: length of the string */ The above is clear, if the element is flagged as a string, the size of this string is put in this variable, so that we can use this in

> 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

Hi, I''ve modified the latest acts_as_ferret code (version 0.3.0) to integrate with the Globalize (http://www.globalize-rails.org/globalize/) plugin. Essentially, I''ve added the ability to use a separate index per locale (It basically adds the language code as a suffix to the index and switches between indexes when the active locale changes). Since this introduces an optional

On Mar 5, 2015, at 2:34 AM, Jakub <jakub.scepka at gmail.com> wrote: > Come on, it started to be interesting! Do you have one of these UPSes? If so, here was Dan's email about a branch to test: > If you still can't get it to work with nutdrv_atcl_usb, another > approach could be worth considering. > > Since this UPS seems to be supported by UPSmart2000I, it could

Arnaud, If memory serves, you're the one that 'invented' the upsdrv_info_t subdriver description structure. We seem to have an issue with this on Solaris. I suspect that we're introducing GCC specific behavior here. Technically the typedef here isn't possible in C89, since this suggests that sizeof(upsdrv_info_t) can be determined. This obvious is not the case, since

Hi, > Since NUT is guessing, is there a way to make it list likely drivers back to the user when they are a close match and check validity for each one until it gets a good connection? Part of auto select? What NUT currently does in `usbhid-ups` (some other drivers may handle similar stuff differently), is it goes through a list of subdrivers built into the binary and calls those

I suspect that the battery is failing on my Pulsar Evolution 500 (it is several years old now) but I can't seem to get a valid battery voltage from the UPS. The following tests were done using NUT 2.2.1, but I first noticed this with the trunk, and reproduced it with the current branches/Testing as well. The only two values I have seen for battery.voltage are 120.0 and 119.0, e.g.: $ upsc

It seems like it works (partially?) with NUT/driver you mentioned. I will test it more when I return home. root at Failure:/lib/nut# ./nutdrv_qx -a test -x subdriver=fuji -u root -x productid=0000 -x vendorid=0001 -DDDDDD Network UPS Tools - Generic Q* USB/Serial driver 0.13 (2.7.2.5) USB communication driver 0.32 0.000000 debug level is '6' 0.001247 upsdrv_initups...

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

I want to revive an old discussion. Should we use the contents of input reports or not? A while back, we decided not to use the contents of input reports, because there is no guarantee that input report 'n' has the same meaning as feature report 'n'. We have not seen any cases so far where this is not the case, but as far as we could see, there is nothing in the HID PDC

Hello, today I'm fighting with a Online Zinto 1000 (lsusb.txt) produced by Phoenixtec/Eaton ;-) http://www.eaton.com/EatonCom/OurCompany/NewsandEvents/NewsList/CT_141334 I have tested different drivers without success (please see attachments usbhid-ups.txt, bcmxcp_usb.txt, blazer_usb.txt) The help got unfortunately time outs (explore.txt)

I recently upgraded from nut-2.4.1 to 2.4.3 and my UPS stopped working. usbhid-ups now fails two communicate with the UPS: With 2.4.1: # /sbin/usbhid-ups -D -a auto Network UPS Tools - Generic HID driver 0.34 (2.4.1) USB communication driver 0.31 debug level is '1' upsdrv_initups... Using subdriver: Belkin HID 0.12 Path: UPS.BELKINConfig.BELKINConfigVoltage, Type: Feature, ReportID: 0x01,

Hi, recently I got a GE EP6000R UPS. At first I feared it's not supported at all, but after digging in I found out that it's supported by the 'blazer' driver. The UPS has both RS232 and USB connection. To use the RS232 connection, I had to use the 'cablepower = none' as the UPS is using only RX, TX and GND pins. So my 'usp.conf' was a bit like that: > [myups]

Hi Alexander, thanks for your good work on the megatec_usb driver. I have made a few more (cosmetic) changes. Is the driver now working stably for your device? In particular, do the instant commands (and particularly "upsdrvctl -k") work properly? In this case, we could hopefully mark the device as "supported" and merge the driver to the main branch. There is still the

On 07/06/16 at 11:18P, Cornelia Huck wrote: > On Mon, 27 Jun 2016 10:09:18 +0800 > Minfei Huang <mnghuan at gmail.com> wrote: > > > The error number -ENOENT or 0 will be returned, if we can not allocate > > more memory in function init_vq. If host can support multiple virtual > > queues, and we fails to allocate necessary memory structures for vq, > > kernel

On 07/06/16 at 11:18P, Cornelia Huck wrote: > On Mon, 27 Jun 2016 10:09:18 +0800 > Minfei Huang <mnghuan at gmail.com> wrote: > > > The error number -ENOENT or 0 will be returned, if we can not allocate > > more memory in function init_vq. If host can support multiple virtual > > queues, and we fails to allocate necessary memory structures for vq, > > kernel

Arjen de Korte wrote: > > Author: adkorte-guest > Date: Fri Aug 10 20:23:27 2007 > New Revision: 1041 > > Log: > * drivers/usbhid.[ch]: > - Moved the struct & data for ups.status processing to usbhid.c, since this is only used in there. Subdrivers report the status through text messages, they don't set the status bits directly. > - Rewrote (flattened) the