Re: libusb10: libusb_bulk_transfer returns LIBUSB_ERROR_OTHER caused by USB_FS_OPEN ioctl in ugen20_tr_open

2010-07-14 Thread Hans Petter Selasky
On Tuesday 13 July 2010 23:40:43 Peer Stritzinger wrote:
 Hi,
 
 with the setup from my post of yesterday I'm trying IN transfers with
 libusb 1.0 and now I'm a bit stuck.
 
 In essence I'm doing:
 
   cnt = libusb_get_device_list(NULL, list);
 
   ... find device - now in found
 
   if (found) {
 libusb_device_handle *handle;
 ...
 rv = libusb_open(found, handle);
 trans_len = 0;
 rv = libusb_bulk_transfer(handle, ep, buf, NBUF, trans_len, 0);
 
 
 What I get is rv - LIBUSB_ERROR_OTHER to get closer to re reason for
 this I debugged the last call into libusb
 
 The error return is caused in ugen20_tr_open():
 
ioctl(xfer-pdev-file, USB_FS_OPEN, temp)
 
returns != 0, errno - EINVAL
 
 Params to this ioctl are:
 
 (gdb) p temp
 $1 = {max_bufsize = 16384, max_frames = 1, max_packet_length = 0,
   dev_index = 0 '\0', ep_index = 24 '\030', ep_no = 6 '\006'}
 
 (gdb) p *xfer
 $2 = {pdev = 0x282033c0, callback = 0x28094190 libusb10_bulk_intr_proxy,
   priv_sc0 = 0x282033c0, priv_sc1 = 0x28221060, ppBuffer = 0x2822208c,
   pLength = 0x28222088, maxTotalLength = 0, maxFrames = 1, nFrames = 0,
   aFrames = 0, timeout = 0, timeComplete = 0, trIndex = 24, maxPacketLen =
  0, flags = 0 '\0', status = 0 '\0', is_opened = 0 '\0', is_pending = 0
  '\0', is_cancel = 0 '\0', is_draining = 0 '\0', is_restart = 0 '\0'}
 (gdb) p *xfer-pdev
 $3 = {ddesc = {LIBUSB20_DEVICE_DESC_FORMAT = 0x2809abd4, bLength = 18
  '\022', bDescriptorType = 1 '\001', bcdUSB = 512, bDeviceClass = 0 '\0',
  bDeviceSubClass = 0 '\0', bDeviceProtocol = 0 '\0',
 bMaxPacketSize0 = 64 '@', idVendor = 1133, idProduct = 49177,
 bcdDevice = 0, iManufacturer = 1 '\001', iProduct = 2 '\002',
 iSerialNumber = 0 '\0', bNumConfigurations = 1 '\001'}, session_data =
  { session_data = 1731721030, tv = {tv_sec = 1731721030, tv_nsec = 0},
  plugtime = 1731721030}, dev_entry = {tqe_next = 0x0,
 tqe_prev = 0x28202030}, methods = 0x2809aac0, beMethods = 0x2809aa80,
   pTransfer = 0x28209c00, privBeData = 0x28215300, privLuData = 0x28207100,
   claimed_interface = 0 '\0', file = 12, file_ctrl = 11, debug = 0,
   nTransfer = 64, bus_number = 3 '\003', device_address = 2 '\002',
   usb_mode = 0 '\0', usb_speed = 3 '\003', is_opened = 1 '\001',
   usb_desc = ugen3.2: CY7C68001 Cypress at usbus3, '\0' repeats 57
  times}
 
 BTW usb_desc is showing the right device.
 
 Any suggestions?

IN endpoints must be OR'ed with 0x80. Could you dump the configuration 
descriptor of your device? Also you might need to claim the interfaces.

--HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org


Re: libusb10: libusb_bulk_transfer returns LIBUSB_ERROR_OTHER caused by USB_FS_OPEN ioctl in ugen20_tr_open

2010-07-14 Thread Peer Stritzinger
Hi,

On Wed, Jul 14, 2010 at 9:35 AM, Hans Petter Selasky hsela...@c2i.net wrote:
 On Tuesday 13 July 2010 23:40:43 Peer Stritzinger wrote:
 What I get is rv - LIBUSB_ERROR_OTHER to get closer to re reason for

 IN endpoints must be OR'ed with 0x80.

That was the problem, from the documentation (fbsd man page and
sourceforge) it wasn't clear that this has to be done.  OTOH it might
have occurred to me that libusb_bulk_transfer couldn't always guess
the direction so it must be told somehow.

It works now quite well now. Thanks a lot!

 Could you dump the configuration
 descriptor of your device? Also you might need to claim the interfaces.

Claiming the interface or not didn't make any difference (both ways it works).

Looking at the code of libusb_claim_interface it doesn't do much, and
claiming doesn't prevent other processes accessing the interface (I
can start the program that claims the interface multiple times without
problem).

Actually what I would like to do is reading one endpoint of a
interface in one process and writing in another process -- saves me
polling an/or doing async i/o.

It looks like it might just work but somehow I have the impression
that it wouldn't be the right way to do it and might break in future
versions of FreeBSD.

Best regards
-- Peer
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org