similar to: (no subject)

Joel Peshkin wrote: > > I hacked in the following additonal changes... > > Index: newhidups.c > =================================================================== > RCS file: /cvsroot/nut/nut/drivers/newhidups.c,v > retrieving revision 1.1.1.1.8.6.2.21 > diff -u -r1.1.1.1.8.6.2.21 newhidups.c > --- newhidups.c 7 Nov 2005 22:14:20 -0000 1.1.1.1.8.6.2.21 > +++

Hi I am running FC5 with nut coming from the fc5 extras repositories. I am trying to configure a Gamatronic D-Compact ups. The cable that came with the ups has a serial connector on one end and a usb on the other. cat /proc/bus/usb/devices produces T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=1.5 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P:

Hi all, I attached a driver for MiniBox openUPS device ( http://www.mini-box.com/OpenUPS) and a dump of the hid usages. I had the possibility to make a few adjustments to the device firmware for HID usages, and although I haven't managed to produce a good structure many issues from previous firmware were at least fixed and new information added. ATM the driver only shows pertaining

Ok, I tried this from scratch on a fresh 2.7.2 directory. I followed the web instructions, specifically: + I generated the new subdriver for my UPS (rtd-hid.*) based on PATH info. + I put them in the drivers subdir + I added the include line (#include rtd-hid.h) in usbhid-ups.c (specifically in the #ifndef SHUT_MODE section) + I added &rtd_subdriver, to the subdriver_list in usbhid-ups.c

Hi I'd like to know what you guys think to the following idea. Please be aware, C/C++ are not exactly my strongpoint (couldn't be much further from it actually..!), so I'm not sure whether this is all legal code. -- SYNOPSIS: Allow a newhidups subdriver to register that it can handle settings in ups.conf (and via -x on the command line), as per the normal serial drivers.

j T wrote: > >- allow the value to be NULL if a subdriver does not require > > initialization. > > Am I right in thinking that this is simply a case of doing: > > subdriver_t some_subdriver = { > /* ... */ > some_format_serial, > NULL, > } > > Rather than: > > subdriver_t belkin_subdriver = { > /* ... */ >

Hi, (please let me know if there is a better place to submit bugs) I run a FreeBSD box with stack-protector enabled, which raises a problem in the upsdrv_initups() function of the newhidups.c module; the regex_array variable is sized one item too small. Regards, Herve Masson <<<< void upsdrv_initups(void) { int i; #ifndef SHUT_MODE /*! * SHUT is only supported by

Well, having spent a decent amount of time trying to get my driver file added into the Makefile build system (and failing), I've decided that for now, simply adding that one line to the openups-hid.c file and recompiling is the best route to go. When I can no longer live with the limited nature of the openups-hid driver, I'll revisit writing our own. Thanks for the helps. Sincerely,

Sorry for the bad formatting of the previous message...I tried to use plus signs as bullet points, and that caused a problem somehow. Ok...I discovered that if I do the autoreconf after the first failed make (and the autoreconf still gives that error message), and then do make again...it builds. Conclusions: 1) Autoreconf *must* be run, and not ./configure? I had thought that putting in my *.c

On Mar 2, 2015, at 12:49 PM, Rob Groner <rgroner at RTD.com> wrote: > Well, having spent a decent amount of time trying to get my driver file added into the Makefile build system (and failing), I've decided that for now, simply adding that one line to the openups-hid.c file and recompiling is the best route to go. When I can no longer live with the limited nature of the openups-hid

I think I'm going to have the slightly rejigger the tripplite-hid.c driver to 'properly' support all of the data I know about it's outlets. A given UPS may have 'n' output loads. I could have 5, I could have 10, I won't know until I actually ask the UPS. But in order to use the hid to nut struct, I'm actually going to have to modify that struct dynamically, or

I Seem to have made some progress in getting nut-2.0.5 installed, but hidups still has a version number of 0.13. First is hidups 0.13 the correct version? if not how do I find the correct version. Second if my Geek Squad GS1285U UPS is not supported how do I proceed. I have been a programmer for 35 years(mostly high level computer aided design), written code in 20 some languages, am retired

Dear Daniele, I'm trying to create a subdriver for 'nutdrv_qx' instead of modifying the Blazer as you suggested, but i honestly don't understand how to integrate usb-serial devices (some of our UPSs have USB but serial protocol Q1). i understand the serial version but not the USB one. i also checked the "Claim" function, but i can't see drivers that uses the VID

Hi Charles and Jonathan, I am going through my over 300 unread NUT messages, and I just discovered this one from mid-December. At the time, I was trying to clean up the tripplite subdriver of newhidups, but never got the information I needed. I have enabled this driver now, but it is marked "experimental". The driver is still incomplete, in the sense that there are many unmapped device

aehm.. the innards of nutdrv_qx are not exactly well documented (and vars have somewhat confusing names) -- my fault, sorry. This is another thing that has been on my todo list for a while... Briefly, at the moment, in nutdrv_qx, there are actually two kinds of subdrivers: - 'protocols', which are communication-type-agnostic (i.e. they do not fiddle with serial or USB operations, and are

Hi, I've recently acquired a couple of Belkin F6H375-USB UPS units that use the Cypress Semiconductor interface (0665:5161), and they are not working with my etch servers. The usbhid driver sees them and takes possession but the nut software does not see anything. After exploration of the driver, running: % /lib/nut/usbhid-ups -DDDDDD -a belkin -x vendor=".*" -x

Some UPSes contain HID report descriptors that fail to correctly describe the contents of reports. For example, the OpenUPS descriptor fails to set the units, logical maximum and logical minimum before the corresponding `main item' as required by the HID specification. This commit allows an override HID report descriptor to be given to usbhid-ups which replaces the one produced by the UPS,

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

Hi On 10/03/2014 03:42 PM, Charles Lepple wrote:> On Oct 3, 2014, at 7:50 AM, paul.chavent at fnac.net wrote: > > > This is what I was referring to (from the belkin-hid log): > >???? 1.325782??? Report[buf]: (5 bytes) => 05 53 00 48 00 >???? 1.325799??? Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x05, Offset: 16, Size: 16, Value: 0 >????

Hi Jonathan and Charles, yes, the Tripp-Lite HID subdriver was under development. I started it based on the debug output posted by somebody on this list a few weeks ago, but then I either didn't get the information I needed, or got too busy to act on it. That driver is still incomplete, in the sense that there are many unmapped device variables. Jonathan, if you run this driver, could you