Hi,
Something must happen after the first PTP session of libgphoto2 has
finished.
On closing the connection we try to clear stalls by calling
libusb_clear_halt on IN/OUT/INT eps.
The second call then fails to send the bulk transfers at all, just like
a stalled endpoint.
We call PTP specific control eps
ret = gp_port_usb_msg_class_write (camera->port, 0x66, 0x0000, 0x0000,
NULL, 0);
I am not in details with the lowlevel USB protocol here sadly.
Ciao, Marcus
On Wed, Feb 27, 2013 at 01:17:37PM +0100, Sipter Bálint wrote:
> Hi,
> I added Marcus Meissner to the conversation he is the developer of gphoto2,
> I hope it's not a problem and he can help us.
>
>
> Does the camera
> > rely on the reset endpoint control transfer as a sort of soft reset?
>
>
> Any hints on how can I verify this?
>
>
>
> 2013/2/25 Sarah Sharp <sarah.a.sh...@linux.intel.com>
>
> > On Sat, Feb 23, 2013 at 09:18:29PM +0800, Xiaofan Chen wrote:
> > > On Sat, Feb 23, 2013 at 9:06 PM, Sipter Bálint <sp...@sch.bme.hu> wrote:
> > > >
> > > > 2013/2/22 Xiaofan Chen <xiaof...@gmail.com>
> > > >>
> > > >> On Fri, Feb 22, 2013 at 5:31 PM, Sipter Bálint <sp...@sch.bme.hu>
> > wrote:
> > > >> > Hi,
> > > >> > we would like to use gphoto2 with multiple cameras at the same
> > time. The
> > > >> > gphoto2 uses libusb(x) when it is communicating with the cameras.
> > > >> > Last time tried to use our bash script with a notebook that only had
> > > >> > usb3 ports(the cameras are usb2).
> > > >> > Unfortunately we ran into some trouble. When we first run gphoto2
> > > >> > everyting is fine, but after that we cant use it. Replugging the usb
> > > >> > usually helps,
> > > >> > but sometimes we need to restart.
> > > >> > We tried debugging for hours, then we came to the conclusion if we
> > > >> > disable the usb3 ports in the bios(so they work as usb2) everything
> > is
> > > >> > working again.
> > > >> > Tired updating the components to the latest releases(gphoto2:
> > 2.5.1.1,
> > > >> > libghoto: 2.5.1, libusbx git-master,libusb-compat-0.1 git-master,
> > linux
> > > >> > kernel: 3.8-rc7).
> > > >> > We tried compiling things in debug mode: Libusbx, libusb-compat and
> > > >> > linux kernel(USB_DEBUG and XHCI_DEBUG).
> > > >> >
> > > >> > Here are the log files:
> > > >> > Correct run: http://pastebin.com/Nh487CXn
> > > >> > Second run(error): http://pastebin.com/RrcS3f70
> > > >> > Kernel log from the whole time: http://pastebin.com/gL002CrS
> >
> > I note that after several untransferred bytes, the driver attempts to
> > issue a reset endpoint request. However, the endpoints aren't actually
> > stalled according to the xHC hardware, so the xHCI driver ignores the
> > request. Shortly after that, the URB gets canceled. Does the camera
> > rely on the reset endpoint control transfer as a sort of soft reset?
> >
> > Sarah Sharp
> >
> >
> > ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_d2d_feb
> > _______________________________________________
> > libusbx-devel mailing list
> > libusbx-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/libusbx-devel
> >
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
