Lars Doelle wrote:
> Hmm, i have another suggestion:
>
> I had a look at the descriptors, and found three interfaces, but each in a
> different alternate setting and same endpoints. This is really a hack. HP
> should have provided two interfaces with a printer and a scanner class with
> differ
Now usb_alloc_urb() has a second paramater, mem_flags.
Thanks to Oliver for the majority of this patch.
I've included all 5 patches in one message. They are split up on my
kernel.org directory if you only want to grab one of them.
On Wed, Feb 13, 2002 at 05:55:30PM -0800, Greg KH wrote:
> [EMA
On Wed, Feb 13, 2002 at 05:55:30PM -0800, Greg KH wrote:
> [EMAIL PROTECTED], 2002-02-13 17:18:52-08:00, [EMAIL PROTECTED]
> usb vicam driver:
> - fix for memory leak.
>
> drivers/usb/vicam.c |7 ++-
> 1 files changed, 6 insertions(+), 1 deletion(-)
# This is a BitKeeper genera
On Wed, Feb 13, 2002 at 05:55:30PM -0800, Greg KH wrote:
> [EMAIL PROTECTED], 2002-02-13 17:15:28-08:00, [EMAIL PROTECTED]
> usb hpusbscsi driver fixes:
> - special case for REQUEST_SENSE
> - reset handling won't work properly -> disabled
> - error reporting corrected
>
> dri
On Wed, Feb 13, 2002 at 05:55:30PM -0800, Greg KH wrote:
> [EMAIL PROTECTED], 2002-02-13 17:12:38-08:00, [EMAIL PROTECTED]
> [PATCH] USB OHCI powerbook fix (v2.5.4)
>
> The patch below fixes a compile problem in the USB OHCI HCD driver on
> powerbooks, namely that the ohci_hcd structure d
Hi everyone,
I've been trying to get a logitech usb optical mouse working with mandrake
8.1.
The mouse seems to work but its laggy to the point that it is unusable.
When I plug the mouse in I get the message usb_control/bulk_msg: timeout
Could this be the source of my problems? I have not been
Hi!
As Linus included ALSA in 2.5.5, will it impact USB audio?
BR,
Jacek
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Pull from: bk://linuxusb.bkbits.net/linus-2.5
drivers/bluetooth/hci_usb.c |8 +++
drivers/input/joystick/iforce.c |6 ++---
drivers/isdn/hisax/st5481_usb.c |6 ++---
drivers/media/video/cpia_usb.c |4 +--
drivers/usb/CDCEther.c |6 ++---
drivers/usb
Hi
I've been looking at the usbdevfs stuff for writing a user mode
driver to a simple device. I had questions.
The device has interrupt endpoints. I see special transfer ioctls
for bulk, but not interrupt. I've been assuming that I need to
submit a usbdevfs_urb and then go and reap it. Does that
On Wed, Feb 13, 2002 at 05:33:13PM -0600, Matthew Fredrickson wrote:
> More data: IIRC, on the vanilla uhci.c driver, ISOC sucks. Sucks really
> badly. Kind of funny though, 'cause I was helping somebody with writing a
> driver for something that used BULK transfers, and the usb-uhci driver
>
On Thu, Feb 14, 2002, Martin Diehl <[EMAIL PROTECTED]> wrote:
> On Wed, 13 Feb 2002, Greg KH wrote:
>
> > > Yes, I do totally agree with David: there is absolutely _no_ debounce
> > > interval (connect-detect-to-port-reset) implemented in 2.4.18-pre9 hub.c
> >
> > Good catch. I'll send out a pa
On Wed, 13 Feb 2002, Greg KH wrote:
> > Yes, I do totally agree with David: there is absolutely _no_ debounce
> > interval (connect-detect-to-port-reset) implemented in 2.4.18-pre9 hub.c
>
> Good catch. I'll send out a patch in a bit to fix this.
Me too - see below
> > struct usb_port_status
On Wed, Feb 13, 2002, Matthew Fredrickson <[EMAIL PROTECTED]> wrote:
> On Wed, 13 Feb 2002 [EMAIL PROTECTED] wrote:
> > transfers for incoming data. I've already reported here performance
> > problems with BULK IN on UHCI chipsets. These performance problems do
> > not go away with the 2.4.18.pre9
On Wed, Feb 13, 2002 at 11:30:35PM +0100, Martin Diehl wrote:
>
> Yes, I do totally agree with David: there is absolutely _no_ debounce
> interval (connect-detect-to-port-reset) implemented in 2.4.18-pre9 hub.c
> According to USB 7.1.7.1 this is mandatory and must be TATTDB > 100 ms.
> It is also
On Wed, Feb 13, 2002 at 04:58:50PM +0100, Oliver Neukum wrote:
> Hi,
>
> this fixes a race where timeout would request an asynchronous unlink and
> disconnect expects a synchronous.
> Furthermore this change set has a compilation fix for hpusbscsi.
Can you just send me a patch for the kaweth dr
On Wed, 13 Feb 2002 [EMAIL PROTECTED] wrote:
> transfers for incoming data. I've already reported here performance
> problems with BULK IN on UHCI chipsets. These performance problems do
> not go away with the 2.4.18.pre9 build. Can anyone comment on the
> maturity/robustness of the ISO handling c
On Wed, 13 Feb 2002, Greg KH wrote:
> > Yes, I'm referring to 7-29. I don't have the source handy and my
> > "information" is anecdotal. It might be a problem with a particular
> > implementation that is not the "standard" USB package for Linux.
> >
> > If you say it's there, I'll believe you.
> > I'm glad to see some more fixes to kaweth. I'm curious
> > why the new block-til-unlink code is only in disconnect()
>
> AFAIK only disconnect and timeout need to unlink
> a transmitting URB.
close() may too ...
> > Also, I suspect it'd be better to use "struct completion"
> > synchroniza
The device I'm working with (USB ADSL modem) will also support ISO
transfers for incoming data. I've already reported here performance
problems with BULK IN on UHCI chipsets. These performance problems do
not go away with the 2.4.18.pre9 build. Can anyone comment on the
maturity/robustness of the
On Wednesday 13 February 2002 22:17, David Brownell wrote:
> FYI: I find that patch format hard to use/read -- have to edit
> the email and remove the "#" prefixes before it applies
> or can be read.
I can't help it. Bitkeeper produces such output.
If I post a pure diff the comments are lost.
>
>
> > If you say it's there, I'll believe you. On the other hand, if some kind
> > person would send me the source for hub.c I could check for myself. ;-)
>Looks like the delay is 10ms, not 100. [From hub.c, 2.4.18pre4]
>
>There is a 400ms delay for low speed device connection as well
Well I do
FYI: I find that patch format hard to use/read -- have to edit
the email and remove the "#" prefixes before it applies
or can be read.
I'm glad to see some more fixes to kaweth. I'm curious
why the new block-til-unlink code is only in disconnect()
though. There may be lurking bugs there; kawet
> From: Brad Hards <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>, "'Greg KH'" <[EMAIL PROTECTED]>
> Date: Thu, 14 Feb 2002 07:56:37 +1100
> > Yes, I'm referring to 7-29. I don't have the source handy and my
> > "information" is anecdotal. It might be a problem with a particular
> > implementati
Hum, maybe that should be fixed? Also, I don't understand having different
values for FS and LS devices. Anyone got a guess as to why that was put in?
Oh, and while I have your attention, I'd like to ask for one more piece of
information. Is the timeout reset on each "bounce" (i.e. each time t
On Thu, 14 Feb 2002 07:08, David Wooten wrote:
> Greg,
>
> Yes, I'm referring to 7-29. I don't have the source handy and my
> "information" is anecdotal. It might be a problem with a particular
> implementation that is not the "standard" USB package for Linux.
>
> If you say it's there, I'll bel
On Wed, Feb 13, 2002 at 12:08:17PM -0800, David Wooten wrote:
> Greg,
>
> Yes, I'm referring to 7-29. I don't have the source handy and my
> "information" is anecdotal. It might be a problem with a particular
> implementation that is not the "standard" USB package for Linux.
>
> If you say it'
> > In fact as it stands, I think this area needs some work because the
> > device probe loop during enumeration isn't actually telling devices
> > what altsetting to use, if it's anything other than the default after
> > setting the configuration...
>
> IMHO, if a device comes with multiple AS a
Greg,
Yes, I'm referring to 7-29. I don't have the source handy and my
"information" is anecdotal. It might be a problem with a particular
implementation that is not the "standard" USB package for Linux.
If you say it's there, I'll believe you. On the other hand, if some kind
person would sen
On Wed, Feb 13, 2002 at 10:42:46AM -0800, David Wooten wrote:
> I was recently informed that the USB driver doesn't allow 100ms of debounce
> time after each connect event before it generates a USB bus reset as is
> required by the USB specification. Is this true?
Are you referring to Figure 7-2
I was recently informed that the USB driver doesn't allow 100ms of debounce
time after each connect event before it generates a USB bus reset as is
required by the USB specification. Is this true?
David Wooten
___
[EMAIL PROTECTED]
To unsubscribe, us
Hi,
this fixes a race where timeout would request an asynchronous unlink and
disconnect expects a synchronous.
Furthermore this change set has a compilation fix for hpusbscsi.
The race probably exists in all ethernet usb drivers save usbnet.
This is the kind of trouble why I'd prefer to have as
On Tue, 12 Feb 2002, Greg KH wrote:
> > this is a patch to prevent usb_set_interface() from erroneously resetting
> > the toggles for all endpoints instead of only the affected ones from the
>
> I'll add this to 2.5.x and let's see what happens. If no one complains,
> send it to me again when 2
On Tue, 12 Feb 2002, Greg KH wrote:
> > The driver has all the knowledge to do so - I don't see how the device
> > probe loop should know, which AS some driver would like to see on probing.
> > Drivers bind on the level of USB device or interface abstraction, not AS.
>
> Driver bind at the inter
33 matches
Mail list logo
