On 2012.06.19 08:28, Peter Stuge wrote:
> Pete Batard wrote:
>> the API is really only one part of it
>
> In a library the API is almost the only thing that matters.
Ergo, you are stating that the resources a project can muster, and users
requests don't matter, as per the exact elements I was bri
Pete Batard wrote:
> the API is really only one part of it
In a library the API is almost the only thing that matters. We've
long ago established that the libusb-1.0 API doesn't fit Windows and
that the Windows code has to jump through hoops because of that.
> balance API requirements with resou
On Mon, Jun 18, 2012 at 4:56 PM, Peter Stuge wrote:
> Peter Stuge wrote:
> > Is there a reason why we would ever not want to set AUTO_CLEAR_STALL?
> >
> > It's done unconditionally now, which seems to be the right way to go
> > so that the 31 error happens for one less reason.
>
> On the other ha
On 2012.06.19 00:07, Peter Stuge wrote:
> Do you know all possible reasons are for that error code?
Do I know the content of MSDN by heart? Do I believe that the WinUSB DLL
designers have documented all the possible reasons under which this
error code to be returned? Do I even believe that the e
Peter Stuge wrote:
> Is there a reason why we would ever not want to set AUTO_CLEAR_STALL?
>
> It's done unconditionally now, which seems to be the right way to go
> so that the 31 error happens for one less reason.
On the other hand, do other backends automatically clear stalls? If
no then Windo
Orin Eman wrote:
> > > > What does GetLastError() return in the relevant cases after the
> > > > WinUsb functions return FALSE?
>
> FWIW, WinUsb_ReadPipe() will return 22 immediately if the device is
> disconnected, BUT a pending overlapped WinUsb_ReadPipe() may* complete
> with error 31 - ERROR_G
On Mon, Jun 18, 2012 at 4:07 PM, Peter Stuge wrote:
> Pete Batard wrote:
> > > What does GetLastError() return in the relevant cases after the
> > > WinUsb functions return FALSE?
> >
> > I'd expect "[22] The device does not recognize the command".
>
> Do you know all possible reasons are for tha
Pete Batard wrote:
> > What does GetLastError() return in the relevant cases after the
> > WinUsb functions return FALSE?
>
> I'd expect "[22] The device does not recognize the command".
Do you know all possible reasons are for that error code?
> > The topic is that transfers don't complete at
On 2012.06.18 20:31, Peter Stuge wrote:
> What does GetLastError() return in the relevant cases after the
> WinUsb functions return FALSE?
I'd expect "[22] The device does not recognize the command".
> In any case, if transfers have been submitted and are on the flying
> list, and if timeouts are
Johannes Stezenbach wrote:
> Doesn't Windows (WinUSB to be precise) return an error code
> indicating the device was unplugged for the submitted transfers?
Can you provide a debug log? I assume you check for submit errors,
and I'm interested in seeing what happens to those later 13.
Thanks!
//P
Pete Batard wrote:
> > Hotplug isn't there yet, and Liam's problem is because the Windows
> > backend doesn't currently implement what the libusb-1.0 API currently
> > offers. Without hotplug. This is a bug in the Windows backend.
>
> Implementing this will require some form of hotplug handling in
On 2012.06.18 16:31, Johannes Stezenbach wrote:
> Doesn't Windows (WinUSB to be precise) return an error code
> indicating the device was unplugged for the submitted transfers?
> If Windows only returns "unlugged" status for one transfer
> and forgets the other ones, can't you just fix this up in t
On 2012.06.18 15:37, Peter Stuge wrote:
> Hotplug isn't there yet, and Liam's problem is because the Windows
> backend doesn't currently implement what the libusb-1.0 API currently
> offers. Without hotplug. This is a bug in the Windows backend.
After 2 similar issues, you still don't get it, so l
On Mon, Jun 18, 2012 at 02:39:45PM +0100, Pete Batard wrote:
> On 2012.06.18 11:50, Peter Stuge wrote:
> >Liam Staskawicz wrote:
> >> This works as intended on OS X, but on Windows I only ever see 3
> >> transfers complete
> >
> > If the later 13 were successfully submitted then that is a bug in th
Hotplug isn't there yet, and Liam's problem is because the Windows
backend doesn't currently implement what the libusb-1.0 API currently
offers. Without hotplug. This is a bug in the Windows backend.
> >> - is this an appropriate way to manage the process of closing my device?
> >
> > Yes, it is.
On 2012.06.18 11:50, Peter Stuge wrote:
>> This works as intended on OS X, but on Windows I only ever see 3
>> transfers complete
>
> If the later 13 were successfully submitted then that is a bug in the
> Windows backend.
Or rather, this is because OS-X has some pre-emptive implementation of
hot
CC libusbx. Maybe Pete and others can give you better answers there.
On Tue, Jun 5, 2012 at 11:09 PM, Liam Staskawicz wrote:
> Hi,
>
> I'm using libusb 1.0.9 on windows7 (building a Qt app with msvc2010), and
> things are largely working just as expected - thanks for a lovely library
> with winus
17 matches
Mail list logo
