search for: hidparser

[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 > > Notes: - avoid cpp style comment > > - I don't see the difference as we return when > > the driver unbind has been done. You'...

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 bit) variable isn't

Good Evening, I recently purchased an EPYC quantum UPS. I installed NUT on the home assistant by connecting the UPS via USB and tried all the various drivers in the list, the only one that seems to work is: usbhid-ups with this log: s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service base-addon-banner: starting

...ue: 0" would show the actual number. Does it look like drivers/libhid.o got rebuilt? > > Yes, at first I thought the same (that I did something wrong), but > everything seems ok: My apologies, you did say the numbers looked different. Here's how the numbers get interpreted: In hidparser.c:GetValue(), the bits get extracted from the report (example: "Report[buf]: (5 bytes) => 05 51 00 48 00"). For ConfigVoltage, the offset is 16 bits, and we skip the first 8 (the report ID; 05 in this case). The size is 16 bits, so that is "48 00" -> "0048", whic...

...some failed hunks when trying to apply the cvs patches to the stable tree). I hope you can use these! Let me know if you have any question. -- Peter (selinger@users.sourceforge.net) 1) nut-cvs-patch-PARSER-2005-08-24 ---------------------------------------- This patch fixes a critical bug in the HIDParser. According to the USB HID specification, when parsing the report descriptor, local tags (such as "usage") are only supposed to apply to the next main item, not any subsequent items. Concretely, when parsing the report descriptor of my APC UPS, there were some redundant "usage" i...

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:

...ot;rtd-hid.h" to dist_noinst_HEADERS in drivers/Makefile.am + I executed ./configure --with-usb --with-dev --etc --etc I execute make, and I get an error: /bin/sh ../libtool --tag=CC --mode=link gcc -I../include -g -O2 -Wall -Wsign-compare -o usbhid-ups usbhid-ups.o libhid.o libusb.o hidparser.o usb-common.o apc-hid.o belkin-hid.o cps-hid.o explore-hid.o liebert-hid.o mge-hid.o powercom-hid.o tripplite-hid.o idowell-hid.o openups-hid.o ../common/libcommon.la ../common/libparseconf.la main.o dstate.o -lusb -lpthread libtool: link: gcc -I../include -g -O2 -Wall -Wsign-compare -o usbhid-u...

...es, You seem to be the author of the drivers/Doxyfile. Is this file still used somewhere, or is just slowly rotting in the tree? The 'hid-usb.h' file mentioned in it was renamed to 'libusb.h' more than two years ago and meanwhile, tripplite_usb doesn't depend/use libhid and the hidparser anymore either. Time for an update I suppose... :-) Best regards, Arjen

...Just adding it to the list may not work if we don't already use this combination for another device. In any case, I would to see the report descriptor and initial variable dump, to see what level of support we can expect from it (I 'collect' report descriptors for verifying the hidparser and libhid code). Best regards, Arjen -- Please keep list traffic on the list

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

...g) that reports for which the HID path ends in 0x00000000 are placeholders only. I agree with the rest of your logic about complexity, but they are less like placeholders, and more like bugs in the parser. A common idiom in HID report descriptors is to have an array of bytes or bitstrings, and the hidparser code tends to show the first array element properly, then it prints several duplicates of the first element with 0x00000000 instead of the last usage ID. -- - Charles Lepple

Charles Lepple wrote: > > would you mind forwarding (to either me, or the list) the .txt file > showing the hidparser bug? I am trying to revamp libhid's hidparser, > and it would be helpful to have the descriptor. The text file is contained in the tarball on the patch tracker, at https://alioth.debian.org/tracker/index.php?func=detail&aid=302101&group_id=30602&atid=411544 ("Download&quo...

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

..._noinst_HEADERS in drivers/Makefile.am I executed ./configure > + --with-usb --with-dev --etc --etc > > I execute make, and I get an error: > /bin/sh ../libtool --tag=CC --mode=link gcc -I../include -g -O2 -Wall - > Wsign-compare -o usbhid-ups usbhid-ups.o libhid.o libusb.o hidparser.o > usb-common.o apc-hid.o belkin-hid.o cps-hid.o explore-hid.o liebert-hid.o > mge-hid.o powercom-hid.o tripplite-hid.o idowell-hid.o openups-hid.o > ../common/libcommon.la ../common/libparseconf.la main.o dstate.o -lusb - > lpthread > libtool: link: gcc -I../include -g -O2 -Wall -...

Peter, I have been doing some more testing and I find that if I modify the libusb.c file to set a report size in libusb_get_report to 16 the error messages go away. This is the code as it currently stands: static int libusb_get_report(usb_dev_handle *udev, int ReportId, unsigned char *raw_buf, int ReportSize ) { int ReportSize_test = 16; unsigned char raw_buf_test[ReportSize_test +

...libusb.o libusb.c mv -f .deps/libusb.Tpo .deps/libusb.Po gcc -DHAVE_CONFIG_H -I. -I../include -I../include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -O -Wall -Wsign-compare -MT hidparser.o -MD -MP -MF .deps/hidparser.Tpo -c -o hidparser.o hidparser.c mv -f .deps/hidparser.Tpo .deps/hidparser.Po gcc -DHAVE_CONFIG_H -I. -I../include -I../include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib6...

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,

.../include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DINET6 -O2 -D_REENTRANT -DNETSNMP_USE_INLINE -Wall -Dlinux -I. -I/usr/include -I/usr/include/neon -O2 -Wall -Wsign-compare -s -o hald-addon-usbhid-ups usbhid-ups.o libhid.o libusb.o hidparser.o apc-hid.o belkin-hid.o cps-hid.o explore-hid.o liebert-hid.o mge-hid.o tripplite-hid.o ../common/libcommon.a libnuthalmain.a -L/usr/lib /usr/lib/libusb.so /usr/lib/libhal.so -ldbus-glib-1 /usr/lib/libglib-2.0.so -ldbus-1 -lrt > libnuthalmain.a(main-hal.o): In function `main': > main-ha...

Hi all, greetings and a happy new year! I am writing as a user, rather than as an ex-developer. Usbhid-ups contains a fatal bug that was apparently introduced in r1210 (I did a binary search to find the exact revision). Arjen, you wrote "correct me if I'm wrong", so it seems that's what I am doing. ------------------------------------------------------------------------ r1210

...ewhidups" driver but I can't get it to compile: [root@mypbx drivers]# make newhidups gcc -I../include -O -Wall -Wsign-compare -o newhidups newhidups.o main.o dstate.o \ ../common/state.o ../common/upsconf.o ../common/parseconf.o \ ../common/common.o libhid.o libusb.o hidparser.o libusb.o(.text+0x1c): In function `libusb_open': : undefined reference to `usb_init' libusb.o(.text+0x21): In function `libusb_open': : undefined reference to `usb_find_busses' libusb.o(.text+0x26): In function `libusb_open': : undefined reference to `usb_find_devices' lib...