On Thu, 1 May 2014, Dave Mielke wrote:
> A further question:
>
> I'm quite sure that the read is supposed to deliver more than 64 bytes, and I
> know for sure that the endpoint descriptor specifies a pacaket size of 64
> bytes. My understanding is that this is still okay, but that the endpoint
A further question:
I'm quite sure that the read is supposed to deliver more than 64 bytes, and I
know for sure that the endpoint descriptor specifies a pacaket size of 64
bytes. My understanding is that this is still okay, but that the endpoint is
supposed to split the larger packet up into a
[quoted lines by Alan Stern on 2014/04/30 at 16:00 -0400]
>Have you tried 3.14? 3.5 is getting old.
That's somewhat beyond my control. I'm logged in remotely to a system which
doesn't belong to me but which is where the device is. It's also a holiday
there, so, even if the owner is willing to
On Wed, 30 Apr 2014, Dave Mielke wrote:
> The kernel being used is 3.5.0-17-generic.
Have you tried 3.14? 3.5 is getting old.
> I'm working with a device for which this operation is known to work on
> Windows.
What operation?
> When I use usbfs, however, the bulk input transfer is yielding
The kernel being used is 3.5.0-17-generic.
I'm working with a device for which this operation is known to work on Windows.
When I use usbfs, however, the bulk input transfer is yielding ETIME (error
62). This is true both synchronously (using ioctl[USBDEVFS_BULK]) and
asynchronously (in which c
