search for: hidgetev

Thomas, The none (-22) message in your log is an errno from the libusb_get_interrupt() call in HIDGetEvents() in libhid.c. It indicates an invalid ioctl type. In HIDGetEvents() there is a comment with that call: /* needs libusb-0.1.8 to work => use ifdef and autoconf */ You may want to make sure your libusb is up-to-date. Hope this helps, AG -- ----------------------------------------------...

Hi, I have a customer who just bought an APC Back-UPS XS 1300 LCD and I thought I'd try the latest NUT with it (on an old-ish FreeBSD 6.x system). It sees the UPS but I can't actually query it for data, in the usbhid-ups debug output I see.. 30.840512 HIDGetEvents: failed to buffer report: Result too large 30.840600 Got -34 HID objects... 30.840681 Quick update... upsc gives.. downie:~>upsc ups1 at localhost ups.status: WAIT downie:~>upsc ups1 at localhost Error: Data stale I have attached the output from the following sudo /usr/local...

...est that the timeout in libhid.c be significantly reduced (50 ms would affect even a pollinterval of 1 by at most 5 %). Unfortunately this change does not address a UPS that burps at more than one message per pollinterval. I have been able to improve things further in my case by repeating the HIDGetEvents() calls in newhidups.c (i.e. changing the if around the HIDGetEvents() call into a while) to some extent (i.e. I can now run with a pollinterval of 2 without loosing any burps from my UPS). BTW, with both fixes I start loosing messages with a pollinterval of 3 (and it is status messages that...

...the -22 error appears in a line "none (-22)" of the output as: ---------- upsdrv_updateinfo... Waiting for notifications... none (-22) entering string_to_path() parsing UPS Looking up UPS ---------- The function calls in userspace are: [newhidups.c] upsdrv_updateinfo() [libhid.c] HIDGetEvents() [libusb.c] libusb_get_interrupt() [libusb] usb_interrupt_read() [libusb] usb_urb_transfer() In the usb_urb_transfer() function one can find that ---------- urb.number_of_packets = 0; /* don't do isochronous yet */ urb.usercontext = NULL; ret = io...

Below is an excerpt from the debug output for a Tripplite UPS: HIDGetEvents: too many events (truncated) Got 16 HID objects... Report[get]: (4 bytes) => 32 00 00 09 Path: UPS.PowerSummary.PresentStatus.00000000, Type: Input, ReportID: 0x32, Offset: 0, Size: 1, Value: 0.000000 NUT doesn't use this HID object The 'Path' reported here looks like this (one...

...0 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 HIDGetEvents: failed to buffer report: Numerical result out of range Got -34 HID objects... Quick update... dstate_init: sock /var/run/nut/usbhid-ups-UPS open on fd 5 upsdrv_updateinfo... file_report_buffer: expected 0 bytes, but got 128! Report[err]: (128 bytes) => 01 00 00 00 00 00 00 00 01 00 00 00 00...

Since reports received over the interrupt pipeline are a recurring problem for various types of UPS'es, I propose to simply ignore the data we receive there and only flush the respective report buffer. By doing so, at the time the interrupt reports are processed the first variable that is retreived will trigger a poll for the corresponding feature report and we should be fine. The impact on

Peter, Apparently, some Belkin UPSes still have problems with this. When we receive this report through the interrupt pipeline it is ignored (the special case in usbhid-ups.c) and even after that it looks like there are still some problems with it: http://lists.alioth.debian.org/pipermail/nut-upsuser/2007-July/003014.html Wouldn't it be an option to just to ignore this completely and

...werSummary.PresentStatus.BelowRemainingCapacityLimit UPS.PowerSummary.PresentStatus.ShutdownImminent UPS.PowerSummary.PresentStatus.RemainingTimeLimitExpired UPS.PowerSummary.PresentStatus.NeedReplacement UPS.PowerSummary.PresentStatus.OverLoad Note that these are all events that appear through HIDGetEvents() in upsdrv_updateinfo(), and all relevant elements are updated there. Here is my puzzlement: If I run with the default poll_interval (which first applies to dstate_poll_fds(), but indirectly also controls the upsdrv_updateinfo() frequency), there are updates roughly every 2 sec, as expecte...

...finition has no type or storage class libhid.c: In function 'HIDGetItemString': libhid.c:258: warning: pointer targets in passing argument 2 of 'libusb_get_string' differ in signedness libhid.c:259: warning: pointer targets in return differ in signedness libhid.c: In function 'HIDGetEvents': libhid.c:368: warning: implicit declaration of function 'malloc' libhid.c:368: warning: incompatible implicit declaration of built-in function 'malloc' libhid.c: In function 'hid_lookup_usage': libhid.c:715: warning: implicit declaration of function 'atoi'...