similar to: Re: [nut-commits] svn commit r848 - branches/tl_usb_fbsd/drivers

I get the following error on r809 (but it looks like the code change happened here). Does HIDDevice_t need to be defined/changed in one of the headers? if gcc -DHAVE_CONFIG_H -I. -I../../drivers -I../include -I../../include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -DINET6 -O2 -D_REENTRANT -DNETSNMP_USE_INLINE -Wall -Dlinux -I.

I got FreeBSD up and running last night (many thanks to Charles Sprickman for a ton of useful suggestions along the way), and took a look at tripplite_usb on an OMNIVS1000. The tripplite_usb driver basically sends old-school Tripp Lite serial commands to the UPS via HID SetReport packets, and receives responses over the first Interrupt IN pipe. Later UPSes seem to be more deterministic in this

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 all, > Am 16.07.2019 um 15:33 schrieb Charles Lepple <clepple at gmail.com>: > There may be an issue with the uhid driver binding to the device. I can't remember which versions of FreeBSD this affects, though. Unloaded the kmod - did not change anything. But I will configure devd not to load uhid.ko ever, just to be sure. You are implying Ithe uhid driver should not be

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

Hi all, After some research I've found that this device should run with the blazer_usb driver. Jun 3 16:15:38 pegasus kernel: ugen0.4: <vendor 0x0001> at usbus0 Jun 3 16:15:38 pegasus kernel: uhid0: <vendor 0x0001 product 0x0000, class 0/0, rev 1.00/1.00, addr 4> on usbus0 However, even after shoehorning it; [crees at pegasus]/usr/local/libexec/nut% sudo ./blazer_usb -a zigor

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

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

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

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.org > Date: Fri, 16 Jun 2006 13:40:59 +0000

Hi all, I’m new to NUT and have some trouble getting my new UPS to work. Since the HCL listed Powercom UHID models as „green“ I thought buying a Roline (German rebranded Powercom) model would be a good idea. The OS is FreeBSD: FreeBSD freenas-pmh.local 11.2-STABLE FreeBSD 11.2-STABLE #0 r325575+6aad246318c(HEAD): Mon Jun 24 17:25:47 UTC 2019 root at

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

2010/12/22 Arjen de Korte <adkorte-guest at alioth.debian.org> > Author: adkorte-guest > Date: Wed Dec 22 20:31:42 2010 > New Revision: 2777 > URL: http://trac.networkupstools.org/projects/nut/changeset/2777 > > Log: > Don't version generated files > > Deleted: > trunk/scripts/hal/ups-nut-device.fdi.in > trunk/scripts/hotplug/libhid.usermap >

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

Citeren Arjen de Korte <adkorte-guest at alioth.debian.org>: > Author: adkorte-guest > Date: Thu Jan 15 20:02:22 2009 > New Revision: 1734 > > Log: > Freshly generated USB helper files > > Modified: > trunk/scripts/hal/ups-nut-device.fdi.in > trunk/scripts/hotplug/libhid.usermap > trunk/scripts/udev/nut-usbups.rules.in Questions is, should we try

Citeren Kjell Claesson <keyson-guest op alioth.debian.org>: > Author: keyson-guest > Date: Mon Mar 23 17:37:37 2009 > New Revision: 1817 > > Log: > data/driver.list, add Eaton Powerware 9130 compatibility with bcmxcp > and usbhid-ups. 1) Is this really true? I would have expected that this device would be supported through bcmxcp (serial) and bcmxcp_usb (USB), like

All: I am having a devil of a time getting nut to work on freebsd. Here is what I have done. I am trying to load the drivers, and here is my ups.conf file: [tripplite] driver=trippliteesu port=auto When I dmesg on freebsd 7.1 for my usb device: uhid0: <Tripp Lite TRIPP LITE UPS, class 0/0, rev 1.10/0.00, addr 2> on uhub0 using the usbdevs -v command: Controller /dev/usb0: addr 1:

On Jun 9, 2015, at 4:55 PM, Greg Hersch wrote: > (gdb) bt > #0 libusb_get_string (udev=0x43110, StringIdx=0, buf=0x40204 <buf> > "", buflen=20) at libusb.c:496 > #1 0x00015330 in HIDGetIndexString (udev=<optimized out>, > Index=<optimized out>, buf=0x40204 <buf> "", buflen=<optimized out>) > at libhid.c:407 > #2 0x00012e18

[I'm switching my dev address to @gmail.com instead of @mgeups... please, update your bookmark] Peter Selinger wrote: > > Arnaud Quette wrote: > > > > Here is the status of PSE (Peter Selinger) NUT patches > > for newhidups (hidparser, apc support, ...). > > > > - nut-cvs-patch-REOPEN-2005-08-24: > > approved and applied on Development tree > >