On Tue, 2002-05-21 at 21:46, Allen Curtis wrote:
> I am interested in getting involved with the USB development but I believe
> there is a lot of studying that I need to do first. Could someone please
> point me to the relevant documents/specs. What areas need the most help at
> this time?
The e
On Tue, 2002-05-21 at 21:57, Ben Simkin wrote:
> I'll be setting up a DirecPC USB Modem tomorrow.
> Could I have a program that captures data from the USB Port (if
> possible), so I can log it.
> I'll hav a look at the data, and pass it on to someone in the group who
> wants to hav a look also.
>
On Wed, May 22, 2002 at 04:28:22AM +0200, [EMAIL PROTECTED] wrote:
> == Andries, what kind of USB problems did you have with 2.5.16?
>
> Yes, I must keep coming back until this is cleared up.
>
> 2.5.14 works.
> 2.5.15 works.
> 2.5.16 hangs upon insmod usb-storage
> 2.5.16 with the usb/storage d
On Wed, May 22, 2002 at 12:29:21AM -0400, Kevin wrote:
> Yes, the patch for pre8 only has the ID for the two port device. This
> is the 0x2204 value that's #defined as USB_DEVICE_ID_ATEN_2PORTKVM. The
> value for my 4 port device is 0x2205, which I had to add to get my KVM
> to work.
Sorry, I j
On Tue, May 21, 2002 at 06:04:21PM -0700, Maksim (Max) Krasnyanskiy wrote:
>
> >IMO, I think testing with usb-uhci.c and uhci.c is still useful, but
> >testing with the -hcd variants is the most ideal since that will be the
> >final code base.
>
> Ok. Here is feedback on 2.5.17 uhci-hcd and usb-
I'll be setting up a DirecPC USB Modem tomorrow.
Could I have a program that captures data from the USB Port (if
possible), so I can log it.
I'll hav a look at the data, and pass it on to someone in the group who
wants to hav a look also.
I am interested in writing some software to communicate
I am interested in getting involved with the USB development but I believe
there is a lot of studying that I need to do first. Could someone please
point me to the relevant documents/specs. What areas need the most help at
this time?
THX
_
Maksim (Max) Krasnyanskiy wrote:
>
> One-shot interrupt transfers are broken in *-hcd drivers. core/hcd.c
> returns EINVAL if urb->interval==0.
Hmm, eventually that automagic resubmit model needs to go away,
in favor of a straight queued transfer model -- where in effect
there are _only_ "one s
Yes, the patch for pre8 only has the ID for the two port device. This
is the 0x2204 value that's #defined as USB_DEVICE_ID_ATEN_2PORTKVM. The
value for my 4 port device is 0x2205, which I had to add to get my KVM
to work.
Cheers,
-kevin
On Tue, 2002-05-21 at 17:07, Greg KH wrote:
> On Mon, M
hello,
At the moment when an usbdevfs urb completes, the programmer has the option of
letting usbdevfs
deliver a RT signal to the task that submitted the urb.
I would like to suggest not to deliver to the submitting task but to the
'owner' of the file
descriptor. This can be se
>>Simple fix: just make control urbs queue, rather than reporting the
>>need to do so as an error ... :)
>
> Well spoken, you lucky OHCI programmer ;-) But Intel thought: "10K gates
> for an USB controller are enough, let the driver writers do the rest...".
Yeah, that _almost_ felt like cheatin
[EMAIL PROTECTED] wrote
>
> You ask: what silly code - why write things that way?
> I agree entirely. But this silly code occurred five times,
> and after the patch it occurs once. That is a much better
> starting point if one wants to improve this code.
Like for example, it's now practical to m
== Andries, what kind of USB problems did you have with 2.5.16?
Yes, I must keep coming back until this is cleared up.
2.5.14 works.
2.5.15 works.
2.5.16 hangs upon insmod usb-storage
2.5.16 with the usb/storage directory replaced by that from 2.5.15 works
The patch from 2.5.15 to 2.5.16 is 130
> However, "uhci-hcd" and "usb-uhci-hcd" did
> not want to bind the audio driver: reading the config descriptor
> (in audio.c) stalled rather consistently. That failure was seen
> with the other USB 1.1 drivers too, but not as consistently.
Just to be clear, that's wholly unrelated to a
Hi,
Given the discussions of last week, this removes urb->next from
the USB core API. This change simplifies the driver API by getting
rid of a superfluous feature (and related new-developer confusion),
gets rid of a hidden failure mode (drivers can now see resubmit
failures), lets us get rid of
Hi,
This is the 2.5 version of the sample driver patch I sent around
last week. It updates one video driver to work with the updated
ISO API: no urb->next (explicit resubmit, with error detection)
and explicit transfer interval (HCs must remove 1 msec limit).
The 2.4 version is known to work,
Hi,
This sets urb->interval in two places it hadn't previously been set,
allowing things like SOX and XMMS to play through usb audio.
Using this and the previous patches, I was able to verify playback
of some Ogg Vorbis encoded music using most of the 2.5.17 host
controller drivers. However, "u
Hi,
This makes the hcds stop expecting urb->next to exist.
ehci-hcd ... remove obsolete sanity check
usb-uhci-hcd ... remove code (wouldn't be called)
Two "old style" drivers got updated too (uhci, usb-uhci)
so that folk can use them in case of problems with their
"new style" an
>IMO, I think testing with usb-uhci.c and uhci.c is still useful, but
>testing with the -hcd variants is the most ideal since that will be the
>final code base.
Ok. Here is feedback on 2.5.17 uhci-hcd and usb-uhci-hcd.
I did not notice any difference in behavior. Both have the same
performance,
On Tue, 2002-05-21 at 17:05, Jacek Pliszka wrote:
> On Wed, 22 May 2002, Brad Hards wrote:
>
> > is too difficult to support it cleanly. Perhaps there could be a usbview
> > option added to "download update from net"?
>
> And "report unknown device" ?
Public Wiki server sounds like the best o
On Wed, 22 May 2002, Brad Hards wrote:
> is too difficult to support it cleanly. Perhaps there could be a usbview
> option added to "download update from net"?
And "report unknown device" ?
BR,
Jacek
___
Don't miss the 2002 Sprin
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.584 -> 1.585
# drivers/usb/storage
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.583 -> 1.584
# drivers/usb/Makefil
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.582 -> 1.583
# drivers/usb/net/peg
Pull from: bk://linuxusb.bkbits.net/linus-2.5
drivers/usb/Makefile| 18 -
drivers/usb/net/pegasus.c |2
drivers/usb/net/pegasus.h |3
drivers/usb/storage/Makefile| 10
drivers/usb/storage/datafab.c | 340 +++
On Wed, May 22, 2002 at 07:26:59AM +1000, Brad Hards wrote:
> On Wed, 22 May 2002 07:21, Greg KH wrote:
> > And is anyone stepping up to volunteer to keep all of the future usb ids
> > in some kind of database? As someone who has watched the pci ids in the
> > kernel constantly struggle to keep u
On Tue, 21 May 2002, Greg KH wrote:
> And is anyone stepping up to volunteer to keep all of the future usb ids
> in some kind of database? As someone who has watched the pci ids in the
> kernel constantly struggle to keep up to date, I really don't want to
> mess with this kind of thing myself.
On Wed, 22 May 2002 07:21, Greg KH wrote:
> And is anyone stepping up to volunteer to keep all of the future usb ids
> in some kind of database? As someone who has watched the pci ids in the
> kernel constantly struggle to keep up to date, I really don't want to
> mess with this kind of thing mys
On Wed, May 22, 2002 at 07:06:52AM +1000, Brad Hards wrote:
> On Wed, 22 May 2002 06:53, Greg KH wrote:
> > Now Brad's patch is quite nice
> Surely you're joking! It was a 20 minute hack :)
But it was a nice hack :)
> But we do have a single file (already used for usbutils), and I don't think i
> One minor nit, can you make sure I can
> apply the patch using '-p1'?
Yes - I generate my patches still in Linus-pre-BK style.
Will change.
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Veg
>Please test the latest version of the drivers. Both uhci and usb-uhci
>have had various bug fixes. I'm sure the performance problems you've had
>with uhci have been fixed for a little while now.
Yep. I did a quick test with Intel, Ericsson and Broadcom devices.
Both HCDs have the same performanc
On Mon, May 20, 2002 at 10:07:12PM -0400, Kevin wrote:
> Greetings,
>
> I just got a 4-port IOGear KVM and quickly found that it didn't work
> with my linux machine. After doing some research I found out that the
> fix was suppose to be in the latest kernel (2.4.19-pre8). I installed
> that and
On Wed, 22 May 2002 06:53, Greg KH wrote:
> Now Brad's patch is quite nice
Surely you're joking! It was a 20 minute hack :)
But we do have a single file (already used for usbutils), and I don't think it
is too difficult to support it cleanly. Perhaps there could be a usbview
option added to "
On Tue, May 21, 2002 at 01:54:27PM -0700, Matthew Dharm wrote:
> Well, okay. But you have to understand my skepticism... I've communicated
> with literally dozens of people who were very eager and willing to work on
> usb-storage, and they (at most) contributed one patch and then disappeared.
He
On Tue, May 21, 2002, Maksim (Max) Krasnyanskiy <[EMAIL PROTECTED]> wrote:
>
> > > So basically I vote for usb-uhci. However some things will have to be
> > > fixed. We (Bluetooth folks) have couple
> > > of devices that refuse to work with usb-uhci (I didn't test the latest
> > > usb-uhci though
On Sun, May 19, 2002 at 11:39:50PM +0200, [EMAIL PROTECTED] wrote:
> Created the first of a series of usb-storage patches
> this afternoon. Please find it below or on ftp.XX.kernel.org
> under people/aeb/2.5.16-us-patch .
> It removes 5% of the usb-storage code, but should, if I made
> no mistake,
On Mon, May 20, 2002 at 11:42:58PM -0700, Jacek Pliszka wrote:
> On Mon, 20 May 2002, Greg KH wrote:
>
> > usbview only displays what the device itself says it is. So if the
> > Product string in the device does not say "Nomad II", usbview can not
> > know to say this.
>
> Hmm, I have another i
Well, okay. But you have to understand my skepticism... I've communicated
with literally dozens of people who were very eager and willing to work on
usb-storage, and they (at most) contributed one patch and then disappeared.
Let's merge the patch and see where it takes us.
Matt
On Tue, May 21,
> I don't quite understand your reasoning for not completing
> the code consolidation.
Not so impatient.
The perfect development model is small steps, frequent updates.
If there is a bug in 2.5.N+1 and things work in 2.5.N and the
change between them is a simple and obvious one, then it is very
> > So basically I vote for usb-uhci. However some things will have to be
> > fixed. We (Bluetooth folks) have couple
> > of devices that refuse to work with usb-uhci (I didn't test the latest
> > usb-uhci though).
>
>Sorry for the confusion, but both usb-uhci.c and uhci.c will be deleted
>anywa
And that would be a fair answer. But:
(a) If that's the case, I'd like to _know_ it (instead of your guess).
(b) I'd also like to know that he _really_ intends to take the next few
steps.
Other than that, the patch looks fine. But I'd really hate to introduce a
couple of new files only to have
On Tue, May 21, 2002 at 10:23:15AM -0500, Timothy E. Jedlicka - wrk wrote:
> [EMAIL PROTECTED] said:
> > Ok, now that 2.5.16 is out, we have a total of 4 different USB UHCI
> > controller drivers in the kernel! That's about 3 too many for me :)
>
> Stupid follow-up question for you. Is it possi
On Tue, May 21, 2002 at 12:58:02PM -0700, Matthew Dharm wrote:
> Andries --
>
> I don't mean to sound as if you're inventing functions... I just mean that,
> if you're going to reduce 5 copies to 2, why not reduce 5 copies to one
> instead?
>
> I don't quite understand your reasoning for not com
On Tue, May 21, 2002 at 12:41:39PM -0700, Maksim (Max) Krasnyanskiy wrote:
> Greg,
>
> I'm gonna speak for Bluetooth USB devices.
> I do have bunch of things like Kodak digi camera, Sony DV camcorder, CF
> reader, etc. But they don't
> seem to care much about which HCD is used and work equally w
On Tue, May 21, 2002, Maksim (Max) Krasnyanskiy <[EMAIL PROTECTED]> wrote:
> I'm gonna speak for Bluetooth USB devices.
> I do have bunch of things like Kodak digi camera, Sony DV camcorder, CF
> reader, etc. But they don't
> seem to care much about which HCD is used and work equally well with bo
Andries --
I don't mean to sound as if you're inventing functions... I just mean that,
if you're going to reduce 5 copies to 2, why not reduce 5 copies to one
instead?
I don't quite understand your reasoning for not completing the code
consolidation.
Matt
On Tue, May 21, 2002 at 09:07:44PM +02
On Tue, May 21, 2002 at 12:41:39PM -0700, Maksim (Max) Krasnyanskiy wrote:
> fixed. We (Bluetooth folks) have couple
> of devices that refuse to work with usb-uhci (I didn't test the latest
> usb-uhci though).
If that is the "device not accepting new address"-problem: This seems to be
a timing
On Tue, May 21, 2002 at 06:37:08PM +0200, [EMAIL PROTECTED] wrote:
> It is this couple that usb-uhci-hcd.c:uhci_urb_enqueue() complains
> about saying "propably device driver bug...".
> (Or, rather, there are many such couples, but this is the first
> occurrence.)
I have checked it. The ENXIO (
Greg,
I'm gonna speak for Bluetooth USB devices.
I do have bunch of things like Kodak digi camera, Sony DV camcorder, CF
reader, etc. But they don't
seem to care much about which HCD is used and work equally well with both
usb-uhci and uhci drivers.
I used to be a uhci driver fan :). But start
On Tue, May 21, 2002 at 11:38:59PM +0530, Avinash natarajan wrote:
>
> hi...
> when i run simultaneous uploads and downloads on my usb modem(for which i have a
>driver)
What driver are you using?
greg k-h
___
Don't miss the 2002
Okay, now I'm seeing where you are headed...
So why are you creating all these new functions and not just using the
control/bulk messaging functions in transport.c, which do all the
scatter-gather management for you?
Matt
Well, you see, in my own tree I h
hi...
when i run simultaneous uploads
and downloads on my usb modem(for which i have a driver)
the download sessions die after some time while the
upload sessions are intact...when i analysed
i saw that introducing download sessions affect
uplad rates very minimally(for instance a sing
Okay, now I'm seeing where you are headed...
So why are you creating all these new functions and not just using the
control/bulk messaging functions in transport.c, which do all the
scatter-gather management for you?
Matt
On Tue, May 21, 2002 at 12:21:51PM +0200, [EMAIL PROTECTED] wrote:
> Ach,
> IIRC, hid_submit_report submits an interrupt URB, not control.
Please read 2.5.17:hid-core.c line 1161.
Andries
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintp
> From: [EMAIL PROTECTED]
> Date: Tue, 21 May 2002 18:37:08 +0200 (MEST)
> T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0
> D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
> P: Vendor=05e3 ProdID=000a Rev= 0.00
> C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr= 48mA
> I: If#= 0
: > But this problem is new, AFAIR I only changed the message, not the
: > detection. Thus the HID driver has more than one control URB outstanding...
: > I will look into that...
: Or it could be ...
I missed the original mail, but I have a little bit of information
on the situation.
The devic
[EMAIL PROTECTED] said:
> Ok, now that 2.5.16 is out, we have a total of 4 different USB UHCI
> controller drivers in the kernel! That's about 3 too many for me :)
Stupid follow-up question for you. Is it possible for me to stay on 2.4.18,
but test the 2.5.16 USB subsystem? I really don't wan
On Tue, May 21, 2002 at 07:47:25AM -0700, David Brownell wrote:
> >But this problem is new, AFAIR I only changed the message, not the
> >detection. Thus the HID driver has more than one control URB outstanding...
> >I will look into that...
>
> Or it could be he's running into that problem where
> But this problem is new, AFAIR I only changed the message, not the
> detection. Thus the HID driver has more than one control URB outstanding...
> I will look into that...
Or it could be he's running into that problem where sometimes hotplugging
does things at the same time the HID driver does.
On Tue, 21 May 2002 19:30, Jacek Pliszka wrote:
> On Tue, 21 May 2002, Brad Hards wrote:
> > On Tue, 21 May 2002 16:42, Jacek Pliszka wrote:
> > > If no string is reported by the device, usbview would lookup this
> > > simple database (preferrably simple text file
> > > VendorId:ProductId String
Ach, too quick.
> diff -urb
that should have been "diff -urbN". Sorry about that.
Am not going to send the diff once more. Below the new files.
raw_bulk.h
#ifndef _USB_STORAGE_RAW_BULK_H_
#define _USB_STORAGE_RAW_BULK_H_
/* usb bulk */
extern int usb_storage_send_control(
str
>> Matt, you asked for a diff -b. But can't you make that yourself?
> I could, in theory, make a diff -b myself. However, then I would have an
> extra development tree on my machine to keep track of, and that's something
> I like to avoid.
Hmm. I just typed
% cd /tmp
% tar xfz /linux/2.5/linux
On Mon, May 20, 2002 at 08:16:17PM -0700, Greg KH wrote:
> > Initializing USB Mass Storage driver...
> > usb.c: registered new driver usb-storage
> > usb-uhci-hcd.c: ENXIO (Control) 8400, flags 0, urb ce1b9120, burb ce1b90c0,
>propably device driver bug...
> > input: USB HID v1.00 Device [
On Tue, 21 May 2002, Brad Hards wrote:
> On Tue, 21 May 2002 16:42, Jacek Pliszka wrote:
> > If no string is reported by the device, usbview would lookup this
> > simple database (preferrably simple text file
> > VendorId:ProductId String to be displayed ).
> Note that we already have such a dat
On Tue, 21 May 2002 16:42, Jacek Pliszka wrote:
> If no string is reported by the device, usbview would lookup this
> simple database (preferrably simple text file
> VendorId:ProductId String to be displayed ).
Note that we already have such a database, on the linux-usb website.
Brad
--
http://
65 matches
Mail list logo