search for: libhid

...and the > changes are prone to introducing subtle bugs, this is not high on my > list anyway at the moment. I haven't brought this up recently because I don't have time to commit to this sort of redesign at the moment, but it could be useful to merge some of the HID code in NUT with libhid. Accessing PDC HID UPSes was the original target application of libhid, but Arnaud ended up pulling some old libhid code into NUT before it was a proper library. One of the libhid goals was to make the backend modular, so that we don't have as much of a mess when switching between USB and SHUT...

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

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

...page http://www.vttoth.com/ER-OF800.htm about the Linux kernel not registering as an hiddev a device that is recognized as an input device is back in recent kernel release and I can't afford compiling my kernel with CONFIG_HID_USBINPUT off as I use a USB mouse. That's why I decided to use libhid. So here are my questions: 1. The libhid.c and libhid.h files in the Nut CVS are completely different from the original libhid svn files. Then what would be the correct way to use libhid from the libhid project for my non-standard UPS ? (inclusion in NUT or package dependancy) 2. Using libhid ma...

While trying to compile newhidups, I get this error... carlos@rhea:~/dev/nut/svn/trunk$ make usb make[1]: Entering directory `/home/carlos/dev/nut/svn/trunk/drivers' gcc -I../include -O -Wall -Wsign-compare -c newhidups.c In file included from newhidups.c:25: libhid.h:46: error: syntax error before "u_int16_t" libhid.h:46: warning: useless keyword or type name in empty declaration libhid.h:46: warning: empty declaration libhid.h:50: error: syntax error before "u_int8_t" libhid.h:50: warning: useless keyword or type name in empty declaration...

...I'm trying to compile it. I'm using this configure line: ./configure --with-user=nut --with-drivers=newhidups but make gets me this: make[1]: Entering directory `/usr/src/nut-2.0.4/drivers' gcc -I../include -O -Wall -Wsign-compare -c newhidups.c In file included from newhidups.c:25: libhid.h:37:17: error: usb.h: Filen eller katalogen finns inte In file included from newhidups.c:25: libhid.h:159: error: syntax error before '*' token libhid.h:169: error: syntax error before '*' token libhid.h:174: error: syntax error before '*' token libhid.h:179: error: syntax...

...know for sure. In NUT 2.4.1 the driver starts up OK, and upsc client gives me values for 39 variables/parameters. In NUT 2.4.3 and 2.6.0, level 1 debug from the driver shows lots of errors and upsc client gives me only 22 variables/parameters. I narrowed the problem down to one function call in libhid.c: r = comm_driver->get_report(udev, id, buf, sizeof(buf)); Below is the patch that fixes the problem. With this change, I get no errors in the level 1 driver debug output, and upsd and all the clients seem to work properly. Once I found that this fixed my problems, I didn't look into it...

...know for sure. In NUT 2.4.1 the driver starts up OK, and upsc client gives me values for 39 variables/parameters. In NUT 2.4.3 and 2.6.0, level 1 debug from the driver shows lots of errors and upsc client gives me only 22 variables/parameters. I narrowed the problem down to one function call in libhid.c: r = comm_driver->get_report(udev, id, buf, sizeof(buf)); Below is the patch that fixes the problem. With this change, I get no errors in the level 1 driver debug output, and upsd and all the clients seem to work properly. Once I found that this fixed my problems, I didn't look into it...

..." hidups.c: In function 'upsdrv_initups': hidups.c:558: warning: implicit declaration of function 'HIDIOCGNAME' hidups.c:562: error: 'HIDIOCINITREPORT' undeclared (first use in this function) make[1]: *** [hidups.o] Error 1 gcc -I../include -O -Wall -Wsign-compare -o libhid.o -c libhid.c In file included from libhid.c:39: hid-usb.h:2:30: error: usb.h: No such file or directory In file included from libhid.c:39: hid-usb.h:7: error: parse error before '*' token hid-usb.h:7: warning: type defaults to 'int' in declaration of 'udev' hid-usb.h:7: war...

Hello, I've rewritten the energizer ups to use libhid like tripplite_usb does and to add support for my Unitek UPS. This driver needs hotplug scripts to set permission to the nut group with idVendor : 0x0F03 and idProduct : 0x0001 This is my first _real_ participation in an Open Source project, I hope I'm doing things the right way. Any idea...

...suring that the same device is reopened, > in case someone has more than one device attached. right. Note that I've an evolution/todo for newhidups with the mfr,prod,serial params to get the right unit when there are multiple. These can be used for the same purpose... (part of the switch to libhid) > > - nut-cvs-patch-DEP-2005-08-24: > > not applied. I'd like to have something more generic, along > > with the gendb system, that will declare some base deps > > (ie "main.h dstate.h serial.h" for serial drivers), and a @.h > > one (need to have a .h...

...ath: UPS.PowerSummary.ConfigVoltage, Type: Feature, > ReportID: 0x05, Offset: 16, Size: 16, Value: 0 > 0.062379 ConfigVoltage = 0 -> assuming correction factor = 1e+08 Strange, I would have thought that the "Value: 0" would show the actual number. Does it look like drivers/libhid.o got rebuilt? Can you retry with debug level 5 (-DDDDD) just once? Thanks for your patience. -- Charles Lepple clepple at gmail

...is instance, but I have not checked it. Perhaps it would be good to add a comment in the source code as a caution. -- Peter Arnaud Quette wrote: > > Author: aquette > Date: Mon Jan 8 10:52:18 2007 > New Revision: 716 > > Modified: > trunk/ChangeLog > trunk/drivers/libhid.c > Log: > HIDDumpTree() also prints the data ReportID, Offset and Size > > Modified: trunk/ChangeLog > ============================================================================== > --- trunk/ChangeLog (original) > +++ trunk/ChangeLog Mon Jan 8 10:52:18 2007 > @@ -1,3 +...

Input and Output reports are used for interrupt endpoints rather than control endpoints. HIDGetItemData() only ever requests feature report IDs, and requesting non-feature report IDs as feature IDs may lead to undesirable results and errors. --- drivers/libhid.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/libhid.c b/drivers/libhid.c index f6ec644..1cec74a 100644 --- a/drivers/libhid.c +++ b/drivers/libhid.c @@ -301,6 +301,13 @@ void HIDDumpTree(hid_dev_handle_t udev, usage_tables_t *utab) continue; } #else + /* Skip non-fe...

2007/3/8, Charles Lepple <clepple-guest@alioth.debian.org>: > Author: clepple-guest > Date: Thu Mar 8 04:15:51 2007 > New Revision: 848 > > Modified: > branches/tl_usb_fbsd/drivers/Makefile.am > branches/tl_usb_fbsd/drivers/libhid-uhid.c > Log: > Work-in-progress... maybe I need to look at how the SHUT subdriver works. > ... simply use the same interface as in libusb.c and the rest is managed at compile time. it's the same idea as the original multi backends of the libHID... btw, are making a uhid backend for...

...e ---------- > 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 libusb objects loose from libhid. If no HID > functions are used (megatec_usb, tripplite_usb), you no longer need to > include libhid anymore. The USB matcher functions (which were not > really HID specific functions) are now within...

...mary.ConfigVoltage, Type: Feature, >> ReportID: 0x05, Offset: 16, Size: 16, Value: 0 >> 0.062379 ConfigVoltage = 0 -> assuming correction factor = 1e+08 > > Strange, I would have thought that the "Value: 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: root at nut:/home/marcelo/nut-2.7.2.5/drivers# ls libhid* -lh -rw-r--r-- 1 marcelo marcelo 28K nov 9 08:52 libhid.c -rw-r--r-- 1 marcelo marcelo 5,1K nov 6 11:08 libhid.h -rw-rw-r-- 1 marcelo...

...ming correction factor = 1e+08 > > The Voltage of 0x51 (81 V) and ConfigVoltage of 0x48 (72 V) seem reasonable, but somewhere else in the HID Report Descriptor, the voltages are getting scaled to a "Logical" range of 0-1. > > Can you temporarily comment out line 383 in drivers/libhid.c and rebuild? It currently looks like this: > > *Value = logical_to_physical(hiddata, hValue); > > If that works, we can add a flag to ignore logical-to-physical mappings. > Hello Charles, Now it seems I'm getting the same values but formatted differently in the output: ro...

Ladies and Gentlemen, I have been trying to sort out a nasty kernel oops for which I would like to ask for some advice. I don't actually think that this is a nut problem, although it is triggered by upsdrvctl or usbhid-ups. I rather suspect the USB library or the associated kernel code. Here is the configuration information: * system: Centos-5.5 * kernel: 2.6.18-194.32.1.el5, latest vanilla

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