On Tuesday 30 October 2012 12:22:47 SAITOU Toshihide wrote:
> In message: <20121030.000648.193690728.to...@ruby.ocn.ne.jp>
> SAITOU Toshihide <to...@ruby.ocn.ne.jp> writes:
> > In message: <201210291436.08940.hsela...@c2i.net>
> > Hans Petter Selasky <hsela...@c2i.net> writes:
> >> On Monday 29 October 2012 13:54:34 SAITOU Toshihide wrote:
> >>> #define PKT_LEN 0x1400
> >> 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_LEN 0x400
> > #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,
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"