similar to: Passing hid_rep_index to libusb_get_config_descriptor is wrong?

Thank you for the investigation! I've thought about this in vague terms, i.e. that numbers like this should be configurable, but did not have time to read into USB-related libraries and specs to make any more specific sense of it (and the libusb code is not mine except the recent layers of cleanup). I guess I did not even realize that there is more than the regularly mentioned "interface

Thanks for the quick reply! Ya, I'm new to all this so I didn't know this either, I was vaguely aware of USB composite devices from other projects, but never how it was all enumerated. I dug a bit more on this and I'm convinced the relationship is this: Device ??? Configuration 1 ??? Interface 1 ? ??? Endpoint 1 ? ??? Endpoint 2 ? ??? ... ??? Interface 2

@jimklimov: Looking at the code that uses hid_rep_index, hid_desc_index, and hid_ep_in|out in usb_subdriver (all in nut_libusb.h) I don't see any use of the addvars mechanism. If I follow the examples that set and use those struct members, it looks like everything relies on them being initialized to 0 by default, then only set in subdrivers or situations that need something different. If I

On 12/03/2016 08:03 AM, Charles Lepple wrote: > On Dec 2, 2016, at 10:23 PM, Jack McGee <jack at greendesk.net> wrote: >> This is new install on Ubuntu 16.04, using packages from Synaptic, >> Network UPS Tools upsd 2.7.2 >> >> I am getting these messages in the terminal: >> Broadcast message from nut at amethi (somewhere) (Fri Dec 2 12:33:03 2016): >>

On Sep 12, 2014, at 5:15 PM, Stan Gammons <sg063015 at gmail.com> wrote: > On 09/11/14 22:34, Charles Lepple wrote: >> On Sep 11, 2014, at 11:04 PM, Stan Gammons <sg063015 at gmail.com> wrote: >> >>> I see a libusb_get_interrupt message in the log. Could that be the problem? >> Yes, it seems related. >> >> 1.126896 upsdrv_initinfo...

On 09/11/14 22:34, Charles Lepple wrote: > On Sep 11, 2014, at 11:04 PM, Stan Gammons <sg063015 at gmail.com> wrote: > >> I see a libusb_get_interrupt message in the log. Could that be the problem? > Yes, it seems related. > > 1.126896 upsdrv_initinfo... > 1.126906 upsdrv_updateinfo... > 1.127023 libusb_get_interrupt: Function not implemented >

On 09/17/14 22:31, Charles Lepple wrote: > On Sep 12, 2014, at 5:15 PM, Stan Gammons <sg063015 at gmail.com> wrote: > >> On 09/11/14 22:34, Charles Lepple wrote: >>> On Sep 11, 2014, at 11:04 PM, Stan Gammons <sg063015 at gmail.com> wrote: >>> >>>> I see a libusb_get_interrupt message in the log. Could that be the problem? >>> Yes, it

On up-to-date f36, with latest kernel 6.1.7-100.fc36.x86_64. After receiving a few of these messages Broadcast message from nut at e7.eyal.emu.id.au (somewhere) UPS ups at ups is unavailable I noticed and ran sudo systemctl restart nut-driver at ups.service which triggered Broadcast message from nut at e7.eyal.emu.id.au (somewhere) Communications with UPS ups at ups established I now added

Running NUT version 2.8.2 on Fedora 40. NUT installed from the Fedora package. CyberPower CP1000AVRLCD connected by USB. I updated the system yesterday with all the latest Fedora packages. Now NUT will not run. Chasing the issue through the layers, I come to this: ===================== [root at mythtv rules.d]# upsc cyberpower Error: Driver not connected [root at mythtv rules.d]#

Did the upgrade by chance install/alter any udev rules causing the UPS devices to now have incorrect permissions? And what user is nut running as? On November 9, 2024 9:58:57 AM EST, Bill Gee <bgee at campercaver.net> wrote: >Running NUT version 2.8.2 on Fedora 40. NUT installed from the Fedora package. CyberPower CP1000AVRLCD connected by USB. > >I updated the system yesterday

Nut should be running as user nut. As far as I can tell, the udev rules have not changed. And the system IS seeing the UPS at a low level. I looked through /dev/ but did not see a device that jumps out as the UPS. ===================== [root at mythtv rules.d]# dmesg | grep -i 0764 [ 2.021485] usb 1-1.8: New USB device found, idVendor=0764, idProduct=0501, bcdDevice= 0.01 [ 2.049515]

Check /dev/hidraw6, as noted in your dmesg output (and any other *hid* devices under /dev). User nut has almost zero privs to devices unless a udev rule changes the perms on the dev for nut . . . On November 9, 2024 1:25:29 PM EST, Bill Gee <bgee at campercaver.net> wrote: >Nut should be running as user nut. As far as I can tell, the udev rules have not changed. And the system IS

On Sep 18, 2014, at 10:09 PM, Stan Gammons <sg063015 at gmail.com> wrote: > > On 09/17/14 22:31, Charles Lepple wrote: >> Can you rebuild the libusb1 pkg as a port, with the DEBUG flag turned on? > > > Is --enable-debug the way one turns it on? I modified the Makefile as shown below, then did a make and make install. I am not sure how to tell OpenBSD to use that

On Sun, Dec 14, 2014 at 07:22:01PM -0500, Mark LaPierre wrote: > On 12/14/14 07:29, ken wrote: > > uname -r; rpm -q libusb > > CentOS 6.6 says: > [mlapier at mushroom ~]$ uname -r; rpm -q libusb > 2.6.32-504.1.3.el6.i686 > libusb-0.1.12-23.el6.i686 CentOS 5 has: libusb-0.1.12 CentOS 6 has: libusb-0.1.12 libusb1-1.0.9 CentOS 7 has: libusb-0.1.4 libusbx-1.0.15

CentOS Errata and Bugfix Advisory 2013:0310 Upstream details at : https://rhn.redhat.com/errata/RHBA-2013-0310.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 1d57304c587c4aa3d5e39f322bc3d421a81c5621bdb771b05b0f06746950f880 libusb1-1.0.9-0.6.rc1.el6.i686.rpm

Stefan Schumacher via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> writes: > Thanks for the info. Nut runs on bare metal, there is no > virtualization layer. I will have a look at the github post after > writing this post. I have compiled and installed nut 2.8.2 as > suggested. But now I am confused: Where is the usb-hid driver, which I > used in Nut 2.8.0? Does one

On Jun 16, 2017, at 6:12 AM, Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote: > > running autogen.sh was triggered automatically. but even if I do it explicitly, I still get: > + autoreconf -i > configure.ac:887: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body

Sounds like some other program is holding the port. Have you stopped other NUT drivers for the device (e.g. via auto-resuscitating services) before starting this one? Does udev, ugen or similar facility have the configuration to hand off this device to NUT run-time user? (BTW, if you are now testing a custom build - was it configured to use same accounts as pre-packaged variant)? On Fri, Mar 24,

On 06/18/2017 05:42 PM, Charles Lepple wrote: > On Jun 16, 2017, at 6:12 AM, Manuel Wolfshant > <wolfy at nobugconsulting.ro <mailto:wolfy at nobugconsulting.ro>> wrote: >> >> running autogen.sh was triggered automatically. but even if I do it >> explicitly, I still get: >> + autoreconf -i >> configure.ac:887: warning: AC_LANG_CONFTEST: no

Apologies for the long post. I'm trying to include what I hope are the relevant bits (output of lsusb -v and usbhid-ups) Long term goal: I've got a DIY UPS that I would like to get working with my QNAP NAS (which uses Linux and NUT underneath the hood) Immediate short-term problem: I can't get past running usbhid-ups on Ubuntu 23.10 with an Arduino Leonardo. I have an Arduino Micro