From owner-freebsd-usb@FreeBSD.ORG Tue Oct 30 13:31:46 2012 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A313D0C for ; Tue, 30 Oct 2012 13:31:46 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from msgw001-01.ocn.ad.jp (msgw001-01.ocn.ad.jp [180.37.203.70]) by mx1.freebsd.org (Postfix) with ESMTP id E1F4D8FC0C for ; Tue, 30 Oct 2012 13:31:45 +0000 (UTC) Received: from localhost (p15069-ipngn100303sizuokaden.shizuoka.ocn.ne.jp [114.176.38.69]) by msgw001-01.ocn.ad.jp (Postfix) with ESMTP id CCBB944DDAE; Tue, 30 Oct 2012 22:31:38 +0900 (JST) Date: Tue, 30 Oct 2012 22:31:38 +0900 (JST) Message-Id: <20121030.223138.71086080.toshi@ruby.ocn.ne.jp> To: hselasky@c2i.net Subject: Re: isochronous transfer for UVC camera From: SAITOU Toshihide In-Reply-To: <201210301341.00350.hselasky@c2i.net> References: <20121030.000648.193690728.toshi@ruby.ocn.ne.jp> <20121030.202247.226801724.toshi@ruby.ocn.ne.jp> <201210301341.00350.hselasky@c2i.net> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 13:31:46 -0000 In message: <201210301341.00350.hselasky@c2i.net> Hans Petter Selasky writes: > On Tuesday 30 October 2012 12:22:47 SAITOU Toshihide wrote: >> In message: <20121030.000648.193690728.toshi@ruby.ocn.ne.jp> >> >> SAITOU Toshihide writes: >> > In message: <201210291436.08940.hselasky@c2i.net> >> > >> > Hans Petter Selasky 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: >> > > > Hi, > >> > #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 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