search for: usb_timeout

...0; /* 0 or USBD_SHORT_XFER_OK */ if (ioctl(endpoint_fd, USB_SET_SHORT_XFER, &i) < 0) { i = 50; if (ioctl(endpoint_fd, USB_SET_TIMEOUT, &i) < 0) { later, writes to the endpoint go fine, but a read() on the endpoint_fd returns immediately with ETIMEDOUT if the USB_TIMEOUT is non-0. I've started following this through the ugen code, but get totally lost in kernel intricacies. Mostly I need a good way to dump debug info to the console while running though this code. Is kprintf() the right way to go? Will (over)using it cause timing problems in the ugen code?...

...c = usb_control_msg(udev, USB_ENDPOINT_IN + USB_TYPE_CLASS + USB_RECIP_INTERFACE, 0x01, /* HID_REPORT_GET */ ReportId+(0x03<<8), /* HID_REPORT_TYPE_FEATURE */ 0, raw_buf_test, ReportSize_test, USB_TIMEOUT); p_raw_buf_test = raw_buf_test + (ReportSize_test - ReportSize); memcpy(raw_buf, p_raw_buf_test, ReportSize); return rc; } else return 0; } From this I now get Detected a UPS: UIS Ablerex/Able...

On 1/23/07, Henning Brauer <hb-nut@bsws.de> wrote: > good new first: the megatec driverin 2.0.5 now works with the Online > Xanto S3000R here - well, for the very basics. > > the UPS has NO way ofidentifying itself. It also does not respond to > the power ratings query ("F"). I previously used a hacked up fentonups > driver. This means the driver cannot figure out

...39;t see any difference between drivers startup process at boot time or later on, WRT to the mentioned context. the only point I also see would be some noise (interferences) tied to other processes looking at USB devices. Beside from Charles requested test, I would advise you to try increasing the USB_TIMEOUT value (in usb-common.h) to see if it's just an transient lack of responsiveness due to some kind of race to access USB devices... cheers Arno -- Eaton Data Center Automation - Opensource Leader NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://w...

...devices). libusb_get_report() has: ret = usb_control_msg(udev, USB_ENDPOINT_IN + USB_TYPE_CLASS + USB_RECIP_INTERFACE, 0x01, /* HID_REPORT_GET */ ReportId+(0x03<<8), /* HID_REPORT_TYPE_FEATURE */ 0, raw_buf, ReportSize, USB_TIMEOUT); Hence, libusb_get_report() always requests the report ID as a feature report, and never uses the report type that was stored. This means that when HIDDumpTree() iterates over all reports that were gathered from in the USB report descriptor, it tries to obtain their values irrespective of whethe...

...#39;t see any difference between drivers startup process at boot time or later on, WRT to the mentioned context. the only point I also see would be some noise (interferences) tied to other processes looking at USB devices. Beside from Charles requested test, I would advise you to try increasing the USB_TIMEOUT value (in usb-common.h) to see if it's just an transient lack of responsiveness due to some kind of race to access USB devices... cheers Arno -- Eaton Data Center Automation - Opensource Leader NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://ww...

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

That worked out just fine. What I am currently running into are conditions where I am getting the following error that I figured I would share. Error: libusb_get_interrupt() returned 0 instead of 8 while sending 3a 4d b2 0d 00 00 00 00 '.M......' Conditions: upsdrvctl start via Init Script at Boottime. If I run the init script after boot, I do not receive this error. Eric Cobb ekcobb