On Wed, 12 Jul 2006, Ajay Jain wrote:
> Hi,
>
> The windows host enumerates my proprieatry device (running linux & my
> driver) in the following sequence:
>
> 1. Reset
> 2. Get Dev Desc 64 bytes
> 3. Reset
> 4. Set Address
> 5. Get Dev Desc 18 bytes
> 6. Get Config Desc 9 bytes
> 7. Get Config D
Hi,
The windows host enumerates my proprieatry device (running linux & my
driver) in the following sequence:
1. Reset
2. Get Dev Desc 64 bytes
3. Reset
4. Set Address
5. Get Dev Desc 18 bytes
6. Get Config Desc 9 bytes
7. Get Config Desc 0xff bytes
8. Get Device Qualifier Desc
9. Get Dev Desc 18
On Fri, 6 Aug 2004, Kyle Harris wrote:
> Alan,
>
> Finally got a chance to look at this some more. I basically used only the
> first portion of your patch. For full_speed devices (I'm assuming this is the
> only ones that need this), I call usb_get_descriptor() before
> usb_set_address() in or
Alan,
Finally got a chance to look at this some more. I basically used only the
first portion of your patch. For full_speed devices (I'm assuming this is the
only ones that need this), I call usb_get_descriptor() before
usb_set_address() in order to get the length of the descriptor and max pack
On Tue, 27 Jul 2004, David Brownell wrote:
> Periodically I think about changing how Linux does this -- to do exactly
> that: request 18 bytes of device descriptor right away to determine
> ep0 maxpacket, and assume it's 64 bytes at first (usually is!) rather
> than just 8 bytes. But I lack time
On Saturday 24 July 2004 11:36, Alan Stern wrote:
> And I don't see why you had to modify your code... You should send the
> first 8 bytes, then wait for another IN so you can send the second eight
> bytes. When you get an OUT instead of an IN you can pretty much do
> whatever you want (excep
On Thursday 22 July 2004 08:15, Kyle Harris wrote:
> I have a check scanner device (serial function):
>
> P: Vendor=1136 ProdID=3231 Rev= 1.00
> S: Manufacturer=CTS Electronics
> S: Product=USB CTS LS100
>
> If setup requests 8 bytes during the initial get_descriptor the device will
> return
On Sat, 2004-07-24 at 11:38, Alan Stern wrote:
> On 23 Jul 2004, David Meggy wrote:
> > Just elaborating a little. The National 9603/4 chips have 1 fifo for
> > end point 0 that is in either tx or rx mode or disabled. So I can't be
> > queuing up the fifo to send data, when the host wants to send
On 23 Jul 2004, David Meggy wrote:
> Just elaborating a little. The National 9603/4 chips have 1 fifo for
> end point 0 that is in either tx or rx mode or disabled. So I can't be
> queuing up the fifo to send data, when the host wants to send data(ZLP)
> too.
Sure you can. You just shouldn't e
On 23 Jul 2004, David Meggy wrote:
> Neither. Actually now that I think about it, the Windows approach makes
> less sense. Windows makes a request larger than 8 bytes. Having only
> an 8 byte fifo, I send 8 bytes. At this point I had to modify my code
> so I wouldn't send anymore data, and it
On Fri, 2004-07-23 at 14:38, David Meggy wrote:
> Neither. Actually now that I think about it, the Windows approach makes
> less sense. Windows makes a request larger than 8 bytes. Having only
> an 8 byte fifo, I send 8 bytes. At this point I had to modify my code
> so I wouldn't send anymore d
On Fri, 2004-07-23 at 07:36, Alan Stern wrote:
> On 22 Jul 2004, David Meggy wrote:
>
> > I needed a check for this when working on the national 9604 gadget
> > driver. The National chip only has an 8 byte fifo on end point 0.
> > Until the device is in the configured state I had to change wLeng
On 22 Jul 2004, David Meggy wrote:
> I needed a check for this when working on the national 9604 gadget
> driver. The National chip only has an 8 byte fifo on end point 0.
> Until the device is in the configured state I had to change wLength to
> 8, if I read a greater value.
I don't understand
On Thu, 2004-07-22 at 14:39, Alan Stern wrote:
> I don't know whether the patch I sent will really work. There's a problem
> with the initial 64-byte get_descriptor and it's not clear how Windows
> works around it. The problem is that after the device sends its first
> 8-byte packet and is rea
On Thu, 22 Jul 2004, Kyle Harris wrote:
> It looks like the windows driver performs the initial get_descriptor with a
> maximum to determine the actual descriptor size. Then it resets the device
> and uses the actual length. This particluar device appears not to work with a
> request of less th
Kyle:
Here's an initial try at a patch for 2.6.0. Anything that finally gets
accepted will undoubtedly be a good deal different from this, but it's a
start.
Alan Stern
--- 2.6.0/drivers/usb/core/usb.c.orig Thu Jul 22 15:56:29 2004
+++ 2.6.0/drivers/usb/core/usb.cThu Jul 22 17:17:1
On Thursday 22 July 2004 05:00 pm, Alan Stern wrote:
>
> By the way, do you know what the SE0 entries in that report mean? Do they
> indicate a port reset?
My understanding is that the SE0 state is a port reset (D- = D+ = 0).
> If they do, I would expect the second reset to
> erase the device
On Thu, 22 Jul 2004, Kyle Harris wrote:
> The device is full speed. I tried 2 other devices, both FS, and the sequence
> is similar (se0, get, se0, set, get, ...). I don't have any LS or HS devices.
> Just curious, why did you think the devide was LS?
That was something of a guess. Low speed d
On Thursday 22 July 2004 03:32 pm, Alan Stern wrote:
> On Thu, 22 Jul 2004, Kyle Harris wrote:
> > I have a USB Tracker. It's not very sophisticated (cheap$), but does show
> > frame data. I can send you a screen grab of the output (didn't buy the
> > export feature), if that would be helpful. The
On Thu, 22 Jul 2004, Kyle Harris wrote:
> I have a USB Tracker. It's not very sophisticated (cheap$), but does show
> frame data. I can send you a screen grab of the output (didn't buy the export
> feature), if that would be helpful. The sequence on Windows is:
>
> SE0
> GetDescriptor
>SET
On Thursday 22 July 2004 01:51 pm, Alan Stern wrote:
> On Thu, 22 Jul 2004, Kyle Harris wrote:
> > I have a check scanner device (serial function):
> >
> > P: Vendor=1136 ProdID=3231 Rev= 1.00
> > S: Manufacturer=CTS Electronics
> > S: Product=USB CTS LS100
> >
> > If setup requests 8 bytes duri
On Thu, 22 Jul 2004, Kyle Harris wrote:
> I have a check scanner device (serial function):
>
> P: Vendor=1136 ProdID=3231 Rev= 1.00
> S: Manufacturer=CTS Electronics
> S: Product=USB CTS LS100
>
> If setup requests 8 bytes during the initial get_descriptor the device will
> return 8 bytes, b
I have a check scanner device (serial function):
P: Vendor=1136 ProdID=3231 Rev= 1.00
S: Manufacturer=CTS Electronics
S: Product=USB CTS LS100
If setup requests 8 bytes during the initial get_descriptor the device will
return 8 bytes, but then continously NAKs the following OUT transaction. I
On Thu, 15 Apr 2004, Oliver Neukum wrote:
> Am Donnerstag, 15. April 2004 22:51 schrieb [EMAIL PROTECTED]:
> > I am doing a usb project and I am interested in the device enumeration
> > process. Where is the enum process carried out? I have been to umpteen
> > Linux usb related sites and so far co
Am Donnerstag, 15. April 2004 22:51 schrieb [EMAIL PROTECTED]:
> I am doing a usb project and I am interested in the device enumeration
> process. Where is the enum process carried out? I have been to umpteen
> Linux usb related sites and so far come up dry. Is it in a kernel module or
> something
I am doing a usb project and I am interested in the device enumeration process. Where
is the enum process carried out? I have been to umpteen Linux usb related sites and so
far come up dry. Is it in a kernel module or something in the file system? I'm lost.
Thanks.
Dave
--
On Sat, 25 Oct 2003, Heiko Rosemann wrote:
> Hi everyone,
>
> I'm not quite sure whether this is exactly the right list to ask, but I
> didn't find any better one...
>
> My problem is as follows: I am developing a USB device (using a Motorola
> 68HC908LD64, just for reference). Windows [98|XP] f
Hi everyone,
I'm not quite sure whether this is exactly the right list to ask, but I
didn't find any better one...
My problem is as follows: I am developing a USB device (using a Motorola
68HC908LD64, just for reference). Windows [98|XP] finally is able to detect
the built-in hub and the embedded
Yeah,
Ignore the reduenent sniffer message . I wrote that Friday, and sent it out
this morning before reading the list.
Quoting "Stephen J. Gowdy" <[EMAIL PROTECTED]>:
> This question was raised a few days ago, see (and the various
> followups);
>
> http://marc.theaimsgroup.com/?l=linux-usb-
This question was raised a few days ago, see (and the various followups);
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=106339758818614&w=2
On Mon, 15 Sep 2003 [EMAIL PROTECTED] wrote:
> Hey, I feel like a jerk asking the list this question, but I have looked high
> and low, and found little
Hey, I feel like a jerk asking the list this question, but I have looked high
and low, and found little or nothing.
I have a device that is getting a bad idVendor and idProduct in Linux, but not
in windows.*
I think that sniffing the USB connection would help me figure it out, but after
30 google
random snippage...
> > I as well have noticed the only chipsets I have problems with are
the VIA
> > uhci chipsets. As I said previously, I know a "special" UHCI driver
was
> > released by Microsoft/VIA that corrected a lot of problems that were
being
> > had with VIA's chipset. I would persue
On Wed, Feb 20, 2002, Matthew Fredrickson <[EMAIL PROTECTED]> wrote:
> > I've been getting similar reports from users of the ov511 driver: error
> > -84 (babble), error -110 (timeout), and truncated frames. The common
> > variable in all cases is a VIA chipset. I would try to track the problem
> uhci chipsets. As I said previously, I know a "special" UHCI driver was
> released by Microsoft/VIA that corrected a lot of problems that were being
> had with VIA's chipset. I would persue a fix for it myself, but I don't
The old VIA random bit stuff is covered in the Linux USB
> know enoug
> I've been getting similar reports from users of the ov511 driver: error
> -84 (babble), error -110 (timeout), and truncated frames. The common
> variable in all cases is a VIA chipset. I would try to track the problem
> down, but my host controllers are all either OHCI or Intel UHCI.
I as we
[EMAIL PROTECTED] wrote:
>hi,
>
>thanks for the reply. it is reassuring to know that i am not alone now let me see
>if i get this right:
>
>1) you assume that we are talking via chipset
> (correct: my mainboard is some MSI* based on VIA chips and i could find out but
>not while at work
mats wolpers wrote:
>hello,
>
> matthew dharm suggested i should inform you of the following:
>
>i had all manner of trouble connecting/mounting my hp318 digital camera using
>suse 7.2. (freeze in usb) so i asked (first greg then) matt for help.
>
>after upgradig from kernel 2.4.4 to 2.4.1
hello,
matthew dharm suggested i should inform you of the following:
i had all manner of trouble connecting/mounting my hp318 digital camera using
suse 7.2. (freeze in usb) so i asked (first greg then) matt for help.
after upgradig from kernel 2.4.4 to 2.4.16, there was no longer any f
38 matches
Mail list logo
