Some weeks before I have already reported about problems with
my USB Remote control.
I got a remote control and a IR Receiver with an USB cable, which
I plug into my computer. I expect receiving the events through
/dev/input/eventx but it does not work out.
The only time, i get an event is
* i pl
Alan Stern wrote:
> It depends what you want to use it for. For some purposes it is better to
> use the maxpacket value instead of the report size.
>
> Alan Stern
In this case definitely the report size is needed. I will change the
variable name to reflect that. As soon as i know where to get
On Tuesday 20 February 2007 12:27 pm, [EMAIL PROTECTED] wrote:
>
> This patch turns off periodic list processing in the EHCI controller for
> the duration of processor frequency changes.
Did you test this with any kind of isochronous device active, like
a set of USB speakers playing? ISO transfe
On Tue, Feb 20, 2007 at 03:48:03PM +0100, Robert Marquardt wrote:
> I just found a bug in the IOWarrior hardware. It can report a wrong
> wMaxPacketSize on interface 0. The diff fixes that in the driver.
>
> 781a782,784
> > if((dev->interface->cur_altsetting->desc.bInterfaceNumber == 0) &&
>
This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 10 hours on the queue on
externalmx-1.sourceforge.net.
The message identifier is: 1HJTHF-0006gl-Me
The subject of the message i
This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 10 hours on the queue on
externalmx-1.sourceforge.net.
The message identifier is: 1HJW66-0006ER-CA
The subject of the message i
On Tue, 20 Feb 2007, Pete Zaitcev wrote:
> What are we going to do about iowarror specifically? It would not be the
> first time we work around broken descriptors.
Until/unless other examples show up, I'd say to use the patch written by
Robert Marquardt (provided he submits it in the proper forma
On Tue, 20 Feb 2007 14:36:33 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> Here's the argument for using the maxpacket size:
I am not completely persuaded... But at least I see what you're thinking,
thanks for the explanation.
What are we going to do about iowarror specifically? It would
Many interrupt transactions to low/full speed devices are getting
QTD_STS_MMF from the EHCI controller because the split transaction isn't
completed in time. This happens when the EHCI controller tries to read
main memory during a CPU frequency change, and it can't get the data
back in time, pres
This patch (as861) adds sysfs attributes to expose the autosuspend
delay value for each USB device. If the user changes the delay from 0
(no autosuspend) to a positive value, an autosuspend is attempted.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
---
Index: usb-2.6/drivers/usb/core/sysfs.c
=
This patch (as860) adds two new sysfs routines:
sysfs_add_file_to_group() and sysfs_remove_file_from_group().
A later patch adds code that uses the new routines.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Cc: Maneesh Soni <[EMAIL PROTECTED]>
---
Index: usb-2.6/fs/sysfs/file.c
This patch (as859) makes the default USB autosuspend delay a module
parameter of usbcore. By setting the delay value at boot time, users
will be able to prevent the system from autosuspending devices which
for some reason can't handle it.
The patch also stores the autosuspend delay as a per-devic
This patch (as858) makes some minor cleanups to sysfs.c in usbcore.
Unnecessary tests are removed and a few temp variables are added.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
---
This isn't directly related to the autosuspend changes in the rest of the
patch series in terms of functionalit
Greg:
Experience with 2.6.20 has shown that there is some buggy USB equipment
out there which doesn't like to be suspended and resumed. This means that
users need a way to manage the newly-added autosuspend/autoresume
facilities. At the very least, it has to be possible to prevent certain
device
On Tue, 20 Feb 2007, Pete Zaitcev wrote:
> On Tue, 20 Feb 2007 11:57:14 -0500 (EST), Alan Stern <[EMAIL PROTECTED]>
> wrote:
> > On Tue, 20 Feb 2007, Guido Körber wrote:
>
> > > There is no situation where a USB device sends multiple reports in
> > > the same packet.
> >
> > I've never seen
On Tue, 20 Feb 2007 11:57:14 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> On Tue, 20 Feb 2007, Guido Körber wrote:
> > There is no situation where a USB device sends multiple reports in
> > the same packet.
>
> I've never seen it happen myself, but Pete Zaitcev says he has:
>
> http://
On Tue, 20 Feb 2007, Guido Körber wrote:
> OK, I am starting to understand where that comes from.
>
> First of all USB does not allow to send two reports in a single
> transfer.
That's right. Section 8.4 of the USB HID specification explicitly says:
Only one report is allowed in a si
OK, I am starting to understand where that comes from.
First of all USB does not allow to send two reports in a single
transfer.
The effect that was described in the forum is likely something that
happens in the buffers of the host controller. Since he writes that
he had to ignore interrupt
On Tue, 20 Feb 2007, Guido Körber wrote:
> There is no situation where a USB device sends multiple reports in
> the same packet.
I've never seen it happen myself, but Pete Zaitcev says he has:
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=116545264427365&w=2
Alan Stern
-
Am 20.02.2007 um 17:17 schrieb Alan Stern:
> On Tue, 20 Feb 2007, Guido Körber wrote:
>
>> Using maxPacketSize instead of ReportSize is never an option.
>>
>> maxPacketSize signifies the maximum physical transfer size supported
>> by an individual endpoint. This value may be lower, equal, or highe
Please configure your email client to wrap long lines after about 75
columns.
On Mon, 19 Feb 2007, Mukesh Kohli wrote:
> > After seeing the transactions by hooking analyzer in between I am seeing
> > the failure happening due to ACK not being sent by the controller in
> > response to data (512 b
On Tue, 20 Feb 2007, Guido Körber wrote:
> Using maxPacketSize instead of ReportSize is never an option.
>
> maxPacketSize signifies the maximum physical transfer size supported
> by an individual endpoint. This value may be lower, equal, or higher
> than ReportSize. In the last case multiple
Using maxPacketSize instead of ReportSize is never an option.
maxPacketSize signifies the maximum physical transfer size supported
by an individual endpoint. This value may be lower, equal, or higher
than ReportSize. In the last case multiple transfers will be
conducted to transfer a single
On Tue, 20 Feb 2007, Robert Marquardt wrote:
> Robert Marquardt wrote:
> > I just found a bug in the IOWarrior hardware. It can report a wrong
> > wMaxPacketSize on interface 0. The diff fixes that in the driver.
>
> To clarify. This is not a bug in the hardware. It is an inconsistency,
> but i
On Tue, 20 Feb 2007, Thibaud Hulin wrote:
> Hi,
>
> > I don't know what you did wrong. CONFIG_4KSTACKS is that last item on the
> > Kernel Hacking menu when you run "make menuconfig".
>
> I've changed too the file drivers/usb/core/usb.h to HZ*60. Then, I've
> verified that CONFIG_4KSTACKS is
Robert Marquardt wrote:
> I just found a bug in the IOWarrior hardware. It can report a wrong
> wMaxPacketSize on interface 0. The diff fixes that in the driver.
To clarify. This is not a bug in the hardware. It is an inconsistency,
but it is valid. The problem is that the driver uses wMaxPacket
I just found a bug in the IOWarrior hardware. It can report a wrong
wMaxPacketSize on interface 0. The diff fixes that in the driver.
781a782,784
> if((dev->interface->cur_altsetting->desc.bInterfaceNumber == 0) &&
(dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW56))
> dev->pa
Hi,
> I don't know what you did wrong. CONFIG_4KSTACKS is that last item on the
> Kernel Hacking menu when you run "make menuconfig".
I've changed too the file drivers/usb/core/usb.h to HZ*60. Then, I've
verified that CONFIG_4KSTACKS is not active in my .config. So, it's
good, because it mean
Add device IDs for the JVC-PRX1 port replicator. Additionally cleans up
the tabs on a few of other IDs in the list.
Reported by: Reuben Thomas <[EMAIL PROTECTED]>
Signed-off-by: David Hollis <[EMAIL PROTECTED]>
--
David Hollis <[EMAIL PROTECTED]>
--- a/drivers/usb/net/asix.c 2007-02-20 07:57:4
An e-mail you sent with message-id NOQUEUE
was modified by our mail scanning software.
The recipients were: <[EMAIL PROTECTED]>
Here are the details of the modification:
The attachment 'website.pif' was deleted due to a virus.
The output of the virus scanner was:
Found the W32/Sality.x
30 matches
Mail list logo
