Hi Alan,
> > I ran across such a device not so long ago. Could you post your patch (or
> > send it to me directly) so that I could test it ?
>
> A preliminary version of the patch is available here:
>
> http://marc.theaimsgroup.com/?l=linux-usb-users&m=109717585508982&w=2
>
> It includes an extra
On Wed, 13 Oct 2004, Greg KH wrote:
> I'm glad someone raised the point about speed, the "windows" way of
> enumerating a device is very slow compared to ours. Which is one nice
> comment that I hear all the time from users, "Linux is faster at
> recognizing my USB device!"
It depends on the dev
On Tue, Oct 12, 2004 at 11:29:08AM -0700, Pete Zaitcev wrote:
> On Tue, 12 Oct 2004 10:12:01 -0400 (EDT)
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > > > Simply because there may be devices that work with the old scheme but not
> > > > with the new one.
> > >
> > > I considered this, and I see i
On Tue, 12 Oct 2004, Pete Zaitcev wrote:
> On Tue, 12 Oct 2004 10:12:01 -0400 (EDT)
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > > > Simply because there may be devices that work with the old scheme but not
> > > > with the new one.
> > >
> > > I considered this, and I see it as a textbook case
On Tue, 12 Oct 2004 10:12:01 -0400 (EDT)
Alan Stern <[EMAIL PROTECTED]> wrote:
> > > Simply because there may be devices that work with the old scheme but not
> > > with the new one.
> >
> > I considered this, and I see it as a textbook case of compatibility with
> > unknown. We will never know u
On 12 Oct 2004, David Meggy wrote:
> If the device has a 8 or 16 byte endpoint 0 fifo (full-speed device),
> then the device will want to send more data, while the host is trying to
> send ZLP. This could create a large numbers of NAKs, and result in an
> extra few seconds of initialization. At
On Fri, 2004-10-08 at 09:08, Alan Stern wrote:
> The new scheme (the "Windows" scheme) is the one used by current Microsoft
> operating systems (and therefore supported by virtually every USB device,
> one would hope):
>
> Reset the device
> Set endpoint 0 maxpacket to {8, 64, 64} fo
On Mon, 11 Oct 2004, Pete Zaitcev wrote:
> > Simply because there may be devices that work with the old scheme but not
> > with the new one.
>
> I considered this, and I see it as a textbook case of compatibility with
> unknown. We will never know unless we give up the traditional sequence,
> if
On Mon, 11 Oct 2004 23:18:28 -0400 (EDT)
Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 11 Oct 2004, Pete Zaitcev wrote:
>
> > On Fri, 8 Oct 2004 12:08:55 -0400 (EDT)
> > Alan Stern <[EMAIL PROTECTED]> wrote:
> >
> > > Clearly we should support both schemes. [...]
> >
> > This is not obvious t
On Mon, 11 Oct 2004, Pete Zaitcev wrote:
> On Fri, 8 Oct 2004 12:08:55 -0400 (EDT)
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > Clearly we should support both schemes. [...]
>
> This is not obvious to me. Please share your line of reasoning with me.
> Why is it not possible to cut over to the d
On Fri, 8 Oct 2004 12:08:55 -0400 (EDT)
Alan Stern <[EMAIL PROTECTED]> wrote:
> Clearly we should support both schemes. [...]
This is not obvious to me. Please share your line of reasoning with me.
Why is it not possible to cut over to the different scheme at certain
release?
-- Pete
-
On Mon, Oct 11, 2004 at 04:40:48PM -0400, Alan Stern wrote:
> On Mon, 11 Oct 2004, Ben Dooks wrote:
>
> > I am reasonably sure that the _proper_ way to do this is close to the
> > windows way with two resets, I have found a number of FTDI based
> > devices do not like a single reset either. (I ca
On Mon, 11 Oct 2004, Ben Dooks wrote:
> I am reasonably sure that the _proper_ way to do this is close to the
> windows way with two resets, I have found a number of FTDI based
> devices do not like a single reset either. (I can't rember where I
> saw the double-reset, can't find it in the usb1.1
On Sat, 9 Oct 2004, Laurent Pinchart wrote:
> > The patch has been tested and it works. In particular, Sony camcorders
> > work with the Windows scheme but not with the Linux scheme. Probably
> > other devices will act similarly; it's common for vendors to test only for
> > Windows compatibility
On Fri, Oct 08, 2004 at 12:08:55PM -0400, Alan Stern wrote:
> I've got a patch that's almost ready for submission, to change the way USB
> devices are initialized. The trickiest part is determining the maxpacket
> value for endpoint 0. The number is fixed at 8 for low-speed and 64 for
> high-s
On Sat, 9 Oct 2004, David Brownell wrote:
> On Friday 08 October 2004 9:08 am, Alan Stern wrote:
>
> > Clearly we should support both schemes. One thing my patch does is change
> > the total number of tries (SET_CONFIG_TRIES) from 2 to 4, trying the Linux
> > scheme twice and the Windows schem
On Friday 08 October 2004 9:08 am, Alan Stern wrote:
> Clearly we should support both schemes. One thing my patch does is change
> the total number of tries (SET_CONFIG_TRIES) from 2 to 4, trying the Linux
> scheme twice and the Windows scheme twice.
>
> The question is, in what order should t
Hi Alan,
> I've got a patch that's almost ready for submission, to change the way USB
> devices are initialized. The trickiest part is determining the maxpacket
> value for endpoint 0. The number is fixed at 8 for low-speed and 64 for
> high-speed devices, but for full-speed devices it can be an
Date: Fri, 08 Oct 2004 14:21:30 -0700
The current scheme (the "Linux" scheme) goes like this:
Reset the device
Set endpoint 0 maxpacket to {8, 8, 64} for {low, full, high}-speed
Send SET-ADDRESS (an 8-byte SETUP with no message body)
Send 8-byte GET-DEVICE-DESCRIPTOR
Am Freitag, 8. Oktober 2004 18:08 schrieb Alan Stern:
> The question is, in what order should the schemes be tried? The
> conservative approach would be to use the Linux scheme twice, then the
> Windows scheme twice. But maybe that's not such a good choice; the Sony
> camcorders respond to the
20 matches
Mail list logo
