From: <alf...@ad...> - 2009-06-27 06:58:25
|
Hi, I'm having a weird problem with libusb-1.0. I have a fresh install of Fedora 11. I'm trying to control a USB HID device (own development) and I want to offer Linux support via libusb. Writing to the device is not a problem and works without any problem. The problems starts when I want to read from the device. Under Windows everything works without a problem. Via lsusb -v I get this information: Bus 003 Device 013: ID 16c0:0552 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x16c0 idProduct 0x0552 bcdDevice 1.00 iManufacturer 1 Advantronix iProduct 2 USB-IO16-II iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 41 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 300mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.01 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 34 Report Descriptor: (length is 34) Item(Global): Usage Page, data= [ 0xa0 0xff ] 65440 (null) Item(Local ): Usage, data= [ 0x01 ] 1 (null) Item(Main ): Collection, data= [ 0x01 ] 1 Application Item(Local ): Usage, data= [ 0x03 ] 3 (null) Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x40 ] 64 Item(Main ): Input, data= [ 0x02 ] 2 Data Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Local ): Usage, data= [ 0x04 ] 4 (null) Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x40 ] 64 Item(Main ): Output, data= [ 0x02 ] 2 Data Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Main ): End Collection, data=none Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 10 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 10 Device Status: 0x0000 (Bus Powered) So, I write using ENDPOINT 0x01, and for reading I use 0x81: retVal = libusb_interrupt_transfer(handle,0x81,usb_report,6 4,&transferred, 10000); But even after 10 seconds I get a timeout. As mentioned before writing is no problem at all ..and now I'm pretty much stuck. So, I hope for some comments or hints where I should look for solving this... Kind regards, Alfred. |
From: Daniel D. <ds...@ge...> - 2009-06-27 08:09:45
|
alf...@ad... wrote: > retVal = libusb_interrupt_transfer(handle,0x81,usb_report,6 > 4,&transferred, 10000); > > But even after 10 seconds I get a timeout. As mentioned before writing is > no problem at all ..and now > I'm pretty much stuck. > > So, I hope for some comments or hints where I should look for solving this... It is probably the case that your device is simply not sending data, hence libusb is doing the right thing. To confirm this, you can use usbmon to monitor exactly what is happening, and you can go over the usbmon logs in detail to make sure that your application is generating exactly the right requests. Daniel |
From: alfredbos <alf...@ad...> - 2009-06-27 12:05:16
|
Hi Daniel, Daniel Drake wrote: > > It is probably the case that your device is simply not sending data, > hence libusb is doing the right thing. > > To confirm this, you can use usbmon to monitor exactly what is > happening, and you can go over the usbmon logs in detail to make sure > that your application is generating exactly the right requests. > Ok, I tried it....but to me looks like the call is not correct ? My device is on Bus 3:005 I made a small test function with: void test(void) { libusb_device_handle *handle; int transferred; int retVal; handle = Usb_IO16II_Open(); usb_report[0] = 0x01; usb_report[1] = 0xAA; usb_report[2] = 0x55; retVal = libusb_interrupt_transfer(handle,0x01,usb_report,64,&transferred, 100); assert(retVal == 0); assert(transferred == 64); usb_report[0] = 0x02; usb_report[1] = 0x12; usb_report[2] = 0x34; retVal = libusb_interrupt_transfer(handle,0x01,usb_report,64,&transferred, 100); assert(retVal == 0); assert(transferred == 64); retVal = libusb_interrupt_transfer(handle,0x81,usb_report,64,&transferred, 1000); assert(retVal == 0); assert(transferred == 64); } And then used USBMON to see what's going on: c44aa480 2068488267 S Io:3:005:1 -115:8 64 = 01aa5500 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c44aa480 2068490417 C Io:3:005:1 0:8 64 > c44aa480 2068490641 S Io:3:005:1 -115:8 64 = 02123400 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c44aa480 2068498416 C Io:3:005:1 0:8 64 > c44aa480 2068498555 S Ii:3:005:1 -115:8 64 < c44aa480 2069500207 C Ii:3:005:1 -2:8 0 It looks to me that it want to write to endpoint 0x01 not 0x81 ? Also, I use libusb_open_device_with_vid_pid(..) to open the device. Are here perhaps known issues with ? Regards, Alfred. -- View this message in context: http://www.nabble.com/libusb-1.0-times-out-when-reading-from-HID-device%2C-write-%3D-ok-%21-tp24230913p24232715.html Sent from the LibUSB Dev mailing list archive at Nabble.com. |
From: Daniel D. <ds...@ge...> - 2009-06-27 14:31:08
|
alfredbos wrote: > And then used USBMON to see what's going on: > > c44aa480 2068488267 S Io:3:005:1 -115:8 64 = 01aa5500 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 > c44aa480 2068490417 C Io:3:005:1 0:8 64 > > c44aa480 2068490641 S Io:3:005:1 -115:8 64 = 02123400 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 > c44aa480 2068498416 C Io:3:005:1 0:8 64 > > c44aa480 2068498555 S Ii:3:005:1 -115:8 64 < > c44aa480 2069500207 C Ii:3:005:1 -2:8 0 > > It looks to me that it want to write to endpoint 0x01 not 0x81 ? usbmon only prints the endpoint number, not the direction. However I don't think it's legal for an interrupt endpoint to have 2 directions. Only control can do that. Daniel |
From: Alan S. <st...@ro...> - 2009-06-27 14:33:30
|
On Sat, 27 Jun 2009, alfredbos wrote: > Ok, I tried it....but to me looks like the call is not correct ? > > My device is on Bus 3:005 > > I made a small test function with: > > void test(void) > { > libusb_device_handle *handle; > int transferred; > int retVal; > > handle = Usb_IO16II_Open(); > usb_report[0] = 0x01; > usb_report[1] = 0xAA; > usb_report[2] = 0x55; > > retVal = > libusb_interrupt_transfer(handle,0x01,usb_report,64,&transferred, 100); > > assert(retVal == 0); > assert(transferred == 64); > > usb_report[0] = 0x02; > usb_report[1] = 0x12; > usb_report[2] = 0x34; > > retVal = > libusb_interrupt_transfer(handle,0x01,usb_report,64,&transferred, 100); > assert(retVal == 0); > assert(transferred == 64); > > retVal = > libusb_interrupt_transfer(handle,0x81,usb_report,64,&transferred, 1000); > assert(retVal == 0); > assert(transferred == 64); > > > } > > And then used USBMON to see what's going on: > > c44aa480 2068488267 S Io:3:005:1 -115:8 64 = 01aa5500 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 > c44aa480 2068490417 C Io:3:005:1 0:8 64 > > c44aa480 2068490641 S Io:3:005:1 -115:8 64 = 02123400 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 > c44aa480 2068498416 C Io:3:005:1 0:8 64 > The two writes completed successfully. > c44aa480 2068498555 S Ii:3:005:1 -115:8 64 < > c44aa480 2069500207 C Ii:3:005:1 -2:8 0 And the read timed out after 1 second. > It looks to me that it want to write to endpoint 0x01 not 0x81 ? The endpoint number reported by usbmon is just the number (0 - 15) without the high-bit direction flag. So this is correct. You can tell the direction from the "Io" (interrupt-OUT) or "Ii" (interrupt-IN) fields. I think Daniel's suggestion earlier was correct. Your read is timing out because the device doesn't have any data to send -- so it doesn't send anything. > Also, I use libusb_open_device_with_vid_pid(..) to open the device. Are here > perhaps known issues with ? It must have worked. Otherwise you wouldn't have been able to do the interrupt-OUT transfers. Alan Stern |
From: Alan S. <st...@ro...> - 2009-06-27 14:35:36
|
On Sat, 27 Jun 2009, Daniel Drake wrote: > > It looks to me that it want to write to endpoint 0x01 not 0x81 ? > > usbmon only prints the endpoint number, not the direction. However I > don't think it's legal for an interrupt endpoint to have 2 directions. > Only control can do that. No, this is perfectly legal. It's not one endpoint with two directions; it's two different endpoints each with one direction. Alan Stern |
From: alfredbos <alf...@ad...> - 2009-06-27 18:23:31
|
OOOOO MMMMMYYYYY GODDDDDD !!!! <STOPS SMASHING HEAD TO WALL> %-| I found the problem....libusb is NOT to blame...I should have realized this when people wrote the there was simply no data from the device ! My USB device will not offer any data by itself...I first have to make a request for data !!!! So: 1. Send request for daa 2. Read the data ! AAAAAARRRRRGHHHHHH....:,( Words can not describe how stupid I know feel....sorry for wasting the time of the readers...I've worked on this for 8 hours !!!! :blush: Well on the upside I've learned a lot about libusb...including the source and how to debug... Anyway, thanks everybody who gave me help...in the end I did solve my (stupid) problem...:handshake: Regards, Alfred. -- View this message in context: http://www.nabble.com/libusb-1.0-times-out-when-reading-from-HID-device%2C-write-%3D-ok-%21-tp24230913p24235492.html Sent from the LibUSB Dev mailing list archive at Nabble.com. |