Re: isochronous transfer for UVC camera

2012-11-01 Thread SAITOU Toshihide 
In message: <20121030.231917.104031274.to...@ruby.ocn.ne.jp>
SAITOU Toshihide  writes:
> In message: <201210301446.43464.hsela...@c2i.net>
> Hans Petter Selasky  writes:
>> On Tuesday 30 October 2012 14:31:38 SAITOU Toshihide wrote:
>>> Is this true about these functions below?
>> 
>> Alternate setting is supported, though if the interface does not exist or 
>> has 
>> already the programmed alternate setting, it will simply do nothing.
> 
> I have no idea... 
> 
> I will build the kernel tomorrow to remove the ugen driver which is
> deactivated in the code though.

Ugen is not separable and not related.

Now I have got the data from UVC cam, \(^-^)/ not yet
examine though.

Thank you HPS for your useful information.


#include 
#include 
#include 

#define VID 0x0458
#define PID 0x7081

#define ConfVal1// Configuration Value
#define IfNum  1// Interface Number
#define AltIfNum   1// Alternate Interface Number

#define PKT_LEN0xc00
#define PKTS_PER_XFER  0x80

#define TIMEOUT 10  // 10 ms


static void cb(struct libusb_transfer *xfer)
{
printf("\nReceived.\n");  // xfer->buffer
libusb_submit_transfer(xfer); // repeat
}


int main( int argc, char **argv)
{
libusb_context *ctx = NULL;
libusb_device *dev = NULL;
libusb_device_handle *handle;
struct libusb_config_descriptor *confDesc;
int numInterfaces;

uint8_t buf[64];
int i;


// get cam device
libusb_init(&ctx);
handle = libusb_open_device_with_vid_pid(ctx, VID, PID);
dev = libusb_get_device(handle);

// if kernel driver is active, detach a kernel driver.
libusb_get_config_descriptor(dev, ConfVal, &confDesc);
numInterfaces = (int)confDesc->bNumInterfaces;
for (i=0; ihttp://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: isochronous transfer for UVC camera

2012-10-30 Thread SAITOU Toshihide 
In message: <201210301446.43464.hsela...@c2i.net>
Hans Petter Selasky  writes:
> On Tuesday 30 October 2012 14:31:38 SAITOU Toshihide wrote:
>> Is this true about these functions below?
> 
> Alternate setting is supported, though if the interface does not exist or has 
> already the programmed alternate setting, it will simply do nothing.

I have no idea... 

I will build the kernel tomorrow to remove the ugen driver which is
deactivated in the code though.

Thank you for your quick response.

---
SAITOU Toshihide
___
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: isochronous transfer for UVC camera

2012-10-30 Thread Hans Petter Selasky 
On Tuesday 30 October 2012 14:31:38 SAITOU Toshihide wrote:
> Is this true about these functions below?

Alternate setting is supported, though if the interface does not exist or has 
already the programmed alternate setting, it will simply do nothing.

--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: isochronous transfer for UVC camera

2012-10-30 Thread SAITOU Toshihide 
In message: <201210301341.00350.hsela...@c2i.net>
Hans Petter Selasky  writes:
> On Tuesday 30 October 2012 12:22:47 SAITOU Toshihide wrote:
>> In message: <20121030.000648.193690728.to...@ruby.ocn.ne.jp>
>> 
>> SAITOU Toshihide  writes:
>> > In message: <201210291436.08940.hsela...@c2i.net>
>> > 
>> > Hans Petter Selasky  writes:
>> >> On Monday 29 October 2012 13:54:34 SAITOU Toshihide wrote:
>> >>> #define PKT_LEN0x1400
>> >> 
>> >> The packet length is not this value I think.
>> >> 
>> >> The 0x1000 is part of the packet multiplier for High-Speed USB's
>> >> wMaxPacketSize.
>> >> 
>> >> It is (1+2) * 0x400. Try that and see what happens.
>> > 
>> > Thank you for your quick response.
>> > 
>> > I can't use the FreeBSD now so I will try this tomorrow.  But Mac OS X
>> > 10.6.8 with libus 1.0.9, callback is not invoked too with some
>> > combination of the value below:
>> > 
> 
> Hi,
> 
>> > #define PKT_LEN0x400
>> > #define PKTS_PER_XFER  8
>> 
> 
> You can compare with output when running webcamd. Make sure webcamd is not 
> running when you start your application!
> 
>> It dose not affect on the FreeBSD.
> 
> PKT_LEN should be 0xC00

Yes, I tried this too because usbdump of the pwcview use this value.
The webcamd is not running when I was logging my code.


>> >> Also there is usbdump -i usbusX -f Y -s 65536 -vvv, which will show the
>> >> actual traffic.
>> 
>> ! This is very useful.
>> 
>>$ usbdump -i usbus2 -f 4.0 -s 65536 -vvv   (unit 4)
> 
> To get both READ and WRITE control requests, you should do:
> 
> usbdump -i usbus2 -f 4.0 -f 4.128 -s 65536 -vvv
> 
>>$ usbdump -i usbus2 -f 4.130 -s 65536 -vvv (unit 4, endpoint 0x82)
>> 
>> I have compared with other application (pwcview).
>> 
>> There are a lot of VS_PROBE_CONTROL transfer than expected. But it may
>> not be a problem because I have tried these transfer reproduced from
>> dump data. The problem I noticed is that the libusb_claim_interface of
>> my code is not logged. Is this function really implemented?
> 
> The claim interface is almost like a NOP under FreeBSD.

Is this true about these functions below?  I compare with pwcview +
webcamd using ``usbdump -i usbus2 -f 4 -s 65536 -vvv'' the noticeable
difference is existence of the SET INTERFACE request.

>>libusb_set_interface_alt_setting(handle, 1, 1);
>>libusb_control_transfer(handle, 0x01, 0x0b, 0x0100, 0x0100, NULL, 0,
>> TIMEOUT);

Thank you.

---
SAITOU Toshihide
___
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: isochronous transfer for UVC camera

2012-10-30 Thread Hans Petter Selasky 
On Tuesday 30 October 2012 12:22:47 SAITOU Toshihide wrote:
> In message: <20121030.000648.193690728.to...@ruby.ocn.ne.jp>
> 
> SAITOU Toshihide  writes:
> > In message: <201210291436.08940.hsela...@c2i.net>
> > 
> > Hans Petter Selasky  writes:
> >> On Monday 29 October 2012 13:54:34 SAITOU Toshihide wrote:
> >>> #define PKT_LEN0x1400
> >> 
> >> The packet length is not this value I think.
> >> 
> >> The 0x1000 is part of the packet multiplier for High-Speed USB's
> >> wMaxPacketSize.
> >> 
> >> It is (1+2) * 0x400. Try that and see what happens.
> > 
> > Thank you for your quick response.
> > 
> > I can't use the FreeBSD now so I will try this tomorrow.  But Mac OS X
> > 10.6.8 with libus 1.0.9, callback is not invoked too with some
> > combination of the value below:
> > 

Hi,

> > #define PKT_LEN0x400
> > #define PKTS_PER_XFER  8
> 

You can compare with output when running webcamd. Make sure webcamd is not 
running when you start your application!

> It dose not affect on the FreeBSD.

PKT_LEN should be 0xC00

> 
> >> Also there is usbdump -i usbusX -f Y -s 65536 -vvv, which will show the
> >> actual traffic.
> 
> ! This is very useful.
> 
>$ usbdump -i usbus2 -f 4.0 -s 65536 -vvv   (unit 4)

To get both READ and WRITE control requests, you should do:

usbdump -i usbus2 -f 4.0 -f 4.128 -s 65536 -vvv

>$ usbdump -i usbus2 -f 4.130 -s 65536 -vvv (unit 4, endpoint 0x82)
> 
> I have compared with other application (pwcview).
> 
> There are a lot of VS_PROBE_CONTROL transfer than expected. But it may
> not be a problem because I have tried these transfer reproduced from
> dump data. The problem I noticed is that the libusb_claim_interface of
> my code is not logged. Is this function really implemented?

The claim interface is almost like a NOP under FreeBSD.

> 
>libusb_set_interface_alt_setting(handle, 1, 1);
>libusb_control_transfer(handle, 0x01, 0x0b, 0x0100, 0x0100, NULL, 0,
> TIMEOUT);

--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: isochronous transfer for UVC camera

2012-10-30 Thread SAITOU Toshihide 
In message: <20121030.000648.193690728.to...@ruby.ocn.ne.jp>
SAITOU Toshihide  writes:
> In message: <201210291436.08940.hsela...@c2i.net>
> Hans Petter Selasky  writes:
>> On Monday 29 October 2012 13:54:34 SAITOU Toshihide wrote:
>>> #define PKT_LEN0x1400
>> 
>> The packet length is not this value I think.
>> 
>> The 0x1000 is part of the packet multiplier for High-Speed USB's 
>> wMaxPacketSize.
>> 
>> It is (1+2) * 0x400. Try that and see what happens.
> 
> Thank you for your quick response.
> 
> I can't use the FreeBSD now so I will try this tomorrow.  But Mac OS X 10.6.8 
> with libus 1.0.9, callback is not invoked too with some combination of the 
> value below:
> 
> #define PKT_LEN0x400
> #define PKTS_PER_XFER  8

It dose not affect on the FreeBSD.

>> Also there is usbdump -i usbusX -f Y -s 65536 -vvv, which will show the 
>> actual 
>> traffic.

! This is very useful.

   $ usbdump -i usbus2 -f 4.0 -s 65536 -vvv   (unit 4)
   $ usbdump -i usbus2 -f 4.130 -s 65536 -vvv (unit 4, endpoint 0x82)

I have compared with other application (pwcview).

There are a lot of VS_PROBE_CONTROL transfer than expected. But it may
not be a problem because I have tried these transfer reproduced from
dump data. The problem I noticed is that the libusb_claim_interface of
my code is not logged. Is this function really implemented?

   libusb_set_interface_alt_setting(handle, 1, 1);
   libusb_control_transfer(handle, 0x01, 0x0b, 0x0100, 0x0100, NULL, 0, 
TIMEOUT);

Thank you.

---
SAITOU Toshihide
___
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: isochronous transfer for UVC camera

2012-10-29 Thread SAITOU Toshihide 
In message: <201210291436.08940.hsela...@c2i.net>
Hans Petter Selasky  writes:
> On Monday 29 October 2012 13:54:34 SAITOU Toshihide wrote:
>> #define PKT_LEN0x1400
> 
> The packet length is not this value I think.
> 
> The 0x1000 is part of the packet multiplier for High-Speed USB's 
> wMaxPacketSize.
> 
> It is (1+2) * 0x400. Try that and see what happens.

Thank you for your quick response.

I can't use the FreeBSD now so I will try this tomorrow.  But Mac OS X 10.6.8 
with libus 1.0.9, callback is not invoked too with some combination of the 
value below:

#define PKT_LEN0x400
#define PKTS_PER_XFER  8

$ ./ex10
libusb: 0.00 info [darwin_open] device open for access
libusb: 0.285678 info [darwin_async_io_callback] an async io operation has 
completed
libusb: 0.286030 info [op_handle_events] checking fd 4 with revents = 0
libusb: 0.286187 info [op_handle_events] checking fd 6 with revents = 1
libusb: 0.286343 info [darwin_handle_callback] handling control completion with 
kernel status 0
1 0 1 1 40 4b 4c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 
libusb: 0.287708 info [darwin_async_io_callback] an async io operation has 
completed
libusb: 0.287751 info [op_handle_events] checking fd 4 with revents = 0
libusb: 0.287761 info [op_handle_events] checking fd 6 with revents = 1
libusb: 0.287775 info [darwin_handle_callback] handling control completion with 
kernel status 0
1 0 1 1 d0 12 13 0 0 0 0 0 0 0 0 0 0 0 0 60 9 0 0 c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 
libusb: 0.288714 info [darwin_async_io_callback] an async io operation has 
completed
libusb: 0.288770 info [op_handle_events] checking fd 4 with revents = 0
libusb: 0.288781 info [op_handle_events] checking fd 6 with revents = 1
libusb: 0.288799 info [darwin_handle_callback] handling control completion with 
kernel status 0
1 0 1 1 d0 12 13 0 0 0 0 0 0 0 0 0 0 0 0 60 9 0 0 c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 
libusb: 0.289960 info [get_endpoints] building table of endpoints.
libusb: 0.290151 info [darwin_claim_interface] interface opened
libusb: 0.292436 info [get_endpoints] building table of endpoints.
libusb: 0.292459 info [get_endpoints] interface: 1 pipe 1: dir: 1 number: 2
libusb: 0.292478 info [ep_to_pipeRef] converting ep address 0x82 to pipeRef and 
interface
libusb: 0.292484 info [ep_to_pipeRef] pipe 1 on interface 1 matches
libusb: 0.297929 info [darwin_async_io_callback] an async io operation has 
completed
libusb: 30.289159 error [do_close] Device handle closed while transfer was 
still being processed, but the device is still connected as far as we know
libusb: 30.289196 error [do_close] A cancellation hasn't even been scheduled on 
the transfer for which the device is closing
libusb: 30.290970 info [event_thread_main] thread exiting

---
SAITOU Toshihide
___
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: isochronous transfer for UVC camera

2012-10-29 Thread Hans Petter Selasky 
On Monday 29 October 2012 13:54:34 SAITOU Toshihide wrote:
> #define PKT_LEN0x1400

Hi,

The packet length is not this value I think.

The 0x1000 is part of the packet multiplier for High-Speed USB's 
wMaxPacketSize.

It is (1+2) * 0x400. Try that and see what happens.

Also there is usbdump -i usbusX -f Y -s 65536 -vvv, which will show the actual 
traffic.

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

isochronous transfer for UVC camera

2012-10-29 Thread SAITOU Toshihide 
I'm trying to get the streaming data from the UVC camera, but isochronous 
transfer callback isn't invoked. Is this lack of parameters to be set or wrong 
coding for my isochronous transfer?

$ uname -a
FreeBSD Kingyo.ens.tut.ac.jp 9.1-RC2 FreeBSD 9.1-RC2 #0 r241106: Mon Oct  1 
18:26:44 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC 
 amd64


/*
 *   $ cc -o ex10 ex10.c -lusb
 *   $ ./ex10 
 *
 * [UVC1.5] Universal Serial Bus Device Class Definition for Video Devices,
 *  (UVC 1.5 Class specification.pdf),
 *  .
 *
 * [USB2.0] USB 2.0 Specification Universal Serial Bus Revision 2.0 
specification,
 *  (usb_20.pdf), .
 */

#include 
#include 
#include 
 
#define VID 0x0458
#define PID 0x7081
#define TIMEOUT 500 // 500 ms
 
#define ConfNum1// Configuration Number
#define IfNum  1// Interface Number
#define AltIfNum   1// Alternate Interface Number


static void cb(struct libusb_transfer *transfer)
{
printf("\nReceived.\n");
libusb_submit_transfer(transfer); // repeat
}


int main( int argc, char **argv)
{
struct libusb_device_descriptor desc;
libusb_context *ctx = NULL;
libusb_device **deviceLst;
ssize_t deviceCnt = 0;
libusb_device *camdev = NULL;
libusb_device_handle *handle;   
int attached = 0;

uint8_t buf[256];
int i;
int rcv;


// populate list with the list of usb devices available.
libusb_init(&ctx);
if ((deviceCnt = libusb_get_device_list(ctx, &deviceLst)) < 0) {
fprintf(stderr, "no usb devices found\n");
return;
}

libusb_set_debug(ctx, 99);

// find device
for (i = 0; i < deviceCnt; i++) {
libusb_get_device_descriptor(deviceLst[i], &desc);
if (desc.idVendor == VID && desc.idProduct == PID) {
camdev = (libusb_device *)deviceLst[i];
break;
}
}

if (!camdev)
{
fprintf(stderr, "device not found.");
return;
}


// open device
if (libusb_open(camdev, &handle) != 0)
{
fprintf(stderr, "Unable to open usb device\n");
return;
}
 
// if kernel driver is active, detach a kernel driver.
if (libusb_kernel_driver_active(handle, 0) == 1)
{
printf("Detaching kernel driver.\n");
libusb_detach_kernel_driver(handle, 0);
attached = 1;
}

// set the active configuration
if (libusb_set_configuration(handle, ConfNum) != 0)
{
fprintf(stderr, "Set configuration failed.");
}


// 
// negotiate the streaming parameters

// Device State Transition [UVC1.5, p. 107]
// Video Probe and Commit Controls [UVC1.5, p. 134]

// set some parameters described to set by the host. [UVC1.5, p. 134]
for (i=0; i<48; i++) {
buf[i] = 0x00;
}
buf[0] = 0x01;  // what fields shall be kept fixed (0x01: 
dwFrameInterval)
buf[1] = 0x00;  // 
buf[2] = 0x01;  // video format index
buf[3] = 0x01;  // video frame index
buf[4] = 0x40;  // interval
buf[5] = 0x4b;  //   propose:   0x4c4b40 (500 ms)
buf[6] = 0x4c;  //   agreement: 0x1312d0 (125 ms)
buf[7] = 0x00;  // 

// VS_PROBE_CONTROL(0x01) [UVC1.5, p. 161], SET_CUR(0x87) [UVC1.5, 
p.158]
libusb_control_transfer(handle, 0x21, 0x01, 0x0100, 0x0001, buf, 48, 
TIMEOUT);
for (i=0; i<48; i++) { printf("%x ", buf[i]); } printf("\n");

// VS_PROBE_CONTROL(0x01) [UVC1.5, p. 161], GET_CUR(0x81) [UVC1.5, 
p.158]
libusb_control_transfer(handle, 0xa1, 0x81, 0x0100, 0x0001, buf, 48, 
TIMEOUT);
for (i=0; i<48; i++) { printf("%x ", buf[i]); } printf("\n");

// VS_COMMIT_CONTROL(0x02) [UVC1.5, p. 161], SET_CUR(0x01) [UVC1.5, 
p.158]
libusb_control_transfer(handle, 0x21, 0x01, 0x0200, 0x0001, buf, 48, 
TIMEOUT);
for (i=0; i<48; i++) { printf("%x ", buf[i]); } printf("\n");

// VS_COMMIT_CONTROL(0x02) [UVC1.5, p. 161], GET_CUR(0x81) [UVC1.5, 
p.158]
//libusb_control_transfer(handle, 0xa1, 0x81, 0x0200, 0x0001, buf, 48, 
TIMEOUT);
//for (i=0; i<48; i++) { printf("%x ", buf[i]); } printf("\n");


// set interface, set alt interface [USB2.0, p. 250]
// are available through synchronous, blocking function
// in the libusb, so can not use libusb_control_transfer.

/