similar to: Non Standard USB HID UPS

Do you know some piece of code I could look at to see learn more about this ?

Do you know some piece of code I could look at to see learn more about this ?

Hello, I would like to know if there is a mean to prevent the driver to drop root privileges through config files ? I have seen the possibility of passing -u root to the driver command line. But I don't see how to use it with my rc-scripts without messing things badly. I have also seen the RUN_AS_USER variable but it seems to apply only to the upsmon client.

was: Re: [Nut-upsdev] usbhid-ups.h: hid_info_t structure On 8/2/07, Peter Selinger <selinger at mathstat.dal.ca> wrote: > All this needs to be replaced by a re-designed, cleaned-up data > structure. It's on my to-do list, but nothing on that list will get > done by me anytime soon. As nothing is technically broken, and the > changes are prone to introducing subtle bugs, this

While trying to compile newhidups, I get this error... carlos@rhea:~/dev/nut/svn/trunk$ make usb make[1]: Entering directory `/home/carlos/dev/nut/svn/trunk/drivers' gcc -I../include -O -Wall -Wsign-compare -c newhidups.c In file included from newhidups.c:25: libhid.h:46: error: syntax error before "u_int16_t" libhid.h:46: warning: useless keyword or type name in empty declaration

Hi! I've got a Mandrake 2006.0 machine and a APC Back-UPS Pro 500/1000/1500 (from lsusb). The Mandrake package version of nut is 2.0.1 and hidups actually detects the UPS, however I get loads of these: Sep 12 18:26:11 vader hidups[7658]: Ignoring x86 page event 0xff860080 (0) Sep 12 18:26:11 vader hidups[7658]: Unhandled event: 0x840058 (6) Sep 12 18:26:11 vader hidups[7658]: Unhandled

Hello, I would like to know if it's possible to use nut with a Unitek Alpha 650ip* and if it's possible which driver should I use ? Thanks.

Hi, I am wanting to use NUT to connect to an Eaton Powerware 5110 UPS using USB to connect. - I am using NUT 2.0.2 - I have compiled it with USB support - I can see that the UPS is registered as connecting in /var/log/messages eg usb 3-1: USB disconnect, address 3 usb 3-2: new low speed USB device using uhci_hcd and address 4 But I don't know how to progress from here.

2007/3/8, Charles Lepple <clepple-guest@alioth.debian.org>: > Author: clepple-guest > Date: Thu Mar 8 04:15:51 2007 > New Revision: 848 > > Modified: > branches/tl_usb_fbsd/drivers/Makefile.am > branches/tl_usb_fbsd/drivers/libhid-uhid.c > Log: > Work-in-progress... maybe I need to look at how the SHUT subdriver works. > ... simply use the same interface

2014-11-09 9:59 GMT-03:00 Charles Lepple <clepple at gmail.com>: > On Nov 9, 2014, at 6:58 AM, Marcelo Fernandez <marcelo.fidel.fernandez at gmail.com> wrote: > >> I'm attaching a new debug log with this modification, just in case, >> but I'm still seeing the lines you've pointed at: >> >> 0.062308 Path: UPS.PowerSummary.Voltage, Type:

On Nov 9, 2014, at 6:58 AM, Marcelo Fernandez <marcelo.fidel.fernandez at gmail.com> wrote: > I'm attaching a new debug log with this modification, just in case, > but I'm still seeing the lines you've pointed at: > > 0.062308 Path: UPS.PowerSummary.Voltage, Type: Feature, > ReportID: 0x05, Offset: 0, Size: 16, Value: 1 > 0.062336 Report[buf]: (5

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

Just a little tiny detail : ============================================================================== > --- trunk/scripts/hotplug/libhid.usermap (original) > +++ trunk/scripts/hotplug/libhid.usermap Fri Aug 25 19:18:19 2006 > @@ -21,5 +21,7 @@ > libhidups 0x0003 0x09ae 0x1003 0x0000 0x0000 0x00 0x00 0x00 0x00

Peter, attached is a proposed patch to fix compilation of generic-hid.c when libusb's usb.h is not in /usr/include (but the -I flag is provided by "libusb-config --cflags"). It fixes the build under OS X, where Fink installs libusb with --prefix=/sw. I changed "usb.h" to <usb.h> so that 'make depend' wouldn't generate a dependency on 'usb.h' with

Hello All- First, my apologies if this is not the correct place/procedure for reporting a bug. I have a Cyberpower 850AVRLCD ups, and I'm running NUT 2.6.0 (and also tried 2.4.1 and 2.4.3). I suspect that the problem I was having would affect anyone using the usbhid-ups driver, but since I have only the one UPS, I don't know for sure. In NUT 2.4.1 the driver starts up OK, and upsc

Hello All- First, my apologies if this is not the correct place/procedure for reporting a bug. I have a Cyberpower 850AVRLCD ups, and I'm running NUT 2.6.0 (and also tried 2.4.1 and 2.4.3). I suspect that the problem I was having would affect anyone using the usbhid-ups driver, but since I have only the one UPS, I don't know for sure. In NUT 2.4.1 the driver starts up OK, and upsc

* I committed into CVS the gendb patch that I sent to the mailing list on September 12. Arnaud, I hope you approve of this patch; it is more reliable than the previous method in tracking the correct dependencies. * This, together with some other minor recent changes on the Development branch, is between the "before_PSE_3" and "after_PSE_3" tags. Arnaud: if you

2014-11-08 20:46 GMT-03:00 Charles Lepple <clepple at gmail.com>: > On Nov 7, 2014, at 7:30 AM, Marcelo Fernandez <marcelo.fidel.fernandez at gmail.com> wrote: > >> 2014-11-07 0:16 GMT-03:00 Charles Lepple <clepple at gmail.com>: >>> On Nov 6, 2014, at 5:56 PM, Marcelo Fernandez <marcelo.fidel.fernandez at gmail.com> wrote: >>> >>>>

Input and Output reports are used for interrupt endpoints rather than control endpoints. HIDGetItemData() only ever requests feature report IDs, and requesting non-feature report IDs as feature IDs may lead to undesirable results and errors. --- drivers/libhid.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/libhid.c b/drivers/libhid.c index f6ec644..1cec74a 100644 ---

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