similar to: Re: [nut-commits] svn commit r716 - in trunk: . drivers

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

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

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

On Feb 3, 2018, at 7:19 PM, Russell King wrote: > > 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. This one made me scratch my head a bit. I don't think it's unreasonable

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 +

Hi, I've been checking out NUT with an OpenUPS board over the last couple of weekends, and have noticed that it doesn't seem to report sensible values. This lead me to investigate usbhid-ups and delve into various issues. As mentioned in a github issue, one of the problems is with the report descriptor - dumping this from the usbhid-ups debug output and picking through it reveals that

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

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:

Hello, all. Some time ago I bought myself a UPS which was advertised as USB-HID. It was a surprise to learn that while it definitely is recognized as USB device, the HID descriptor has no UPS pages at all. The only software it came with was a windows program written in visual basic. Trying to research this topic I found a reference to energizer USB ups driver and learned about variety of

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: Feature, > ReportID: 0x05, Offset: 0, Size: 16, Value: 1 > 0.062336 Report[buf]: (5

2014-11-08 20:46 GMT-03:00 Charles Lepple <clepple at gmail.com>: > On Nov 7, 2014, at 7:30 AM, Marcelo Fernandez <marcelo.fidel.fernandez at gmail.com> wrote: > >> 2014-11-07 0:16 GMT-03:00 Charles Lepple <clepple at gmail.com>: >>> On Nov 6, 2014, at 5:56 PM, Marcelo Fernandez <marcelo.fidel.fernandez at gmail.com> wrote: >>> >>>>

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

I got sick & tired of constant power outages with no warning, so when I saw various UPSes at the store, I decided to get one, and the one I got was a model 200897 from Newpoint (a.k.a. Power Sentry). A couple of days later the power went out and I decided to use the opportunity to hook up the UPS. I added up the wattages of the equipment I would be connecting, and found that the only way I

Hi Charles, Sorry for the long email, I feel this deserves a fuller explanation. On Wed, Feb 14, 2018 at 10:30:18PM -0500, Charles Lepple wrote: > On Feb 3, 2018, at 7:19 PM, Russell King wrote: > > > > Input and Output reports are used for interrupt endpoints rather than > > control endpoints. HIDGetItemData() only ever requests feature > > report IDs, and

Hi Jon, your patches are malformed because (presumably) your email client wrapped this lines. Could you please send these as a unified diff ("diff -u"), and send them in attachments, rather than as a copy-and-paste? Thanks, -- Peter Jon Gough wrote: > > Peter, > Here are the files I have worked on. I hope I have diff'd them > correctly. I have not touched the

I'm testing a Powercom UPS (branded as Control System 2 STD80S: http://www.cs2.it/home.php?goto=prodotti&cat=0&idp=2&subid=0) with NUT. It is a USB HID device, with ID 0d9f:0004. I configured nut-server to use driver usbhid-ups and it works almost correctly: upsd communicates right with the device, upsmon catches its events... But when I try to perform a Forced Shutdown, UPS pauses

In a separate discussion, on 6/26/17 4:04 AM, Arnaud Quette wrote: > Hi > > If you're sure it's a HID device, add an entry in drivers/powercom-hid.c > { USB_DEVICE(POWERCOM_VENDORID, 0x0002), NULL }, > > Then autogen.sh + configure... > Please also report back so that I can update the code > > Cheers > Arno Thanks! I don't *know* whether or not

Hi! I've recently come into to the possesion of a couple of Belkin Omniguard 3200 UPS's. Given the horrible apache/java based software they come with, I decided to see if I cannot get them to work with NUT. To cut a long story short, they work out to be SEC -based, and extensively modifying the nut-1.4 driver code to come up with the attached two files. I've marked them