On Mon, 25 Jun 2007, Oliver Neukum wrote:
I grabbed a random HUB (usbhub4c from Linksys) and this made it work
nicely even on UHCI-based system I am testing on.
Is it a 1.1 hub or a 2.0 hub?
1.1, the device is still handled by uhci_hcd.
--
Jiri Kosina
Am Montag, 25. Juni 2007 schrieb Jiri Kosina:
On Fri, 22 Jun 2007, Oliver Neukum wrote:
could you please run two tests?
1. set the autosuspend timeout to 0 (this'll kill usb mice)
And it kills also my testing keyboard on the UHCI system. After the
keyboard gets suspended and I hit a
On Fri, 22 Jun 2007, Oliver Neukum wrote:
could you please run two tests?
1. set the autosuspend timeout to 0 (this'll kill usb mice)
And it kills also my testing keyboard on the UHCI system. After the
keyboard gets suspended and I hit a key, it wakes up (the LEDs come up),
but no
Am Montag, 25. Juni 2007 schrieb Jiri Kosina:
On Mon, 25 Jun 2007, Oliver Neukum wrote:
I grabbed a random HUB (usbhub4c from Linksys) and this made it work
nicely even on UHCI-based system I am testing on.
Is it a 1.1 hub or a 2.0 hub?
1.1, the device is still handled by uhci_hcd.
On Mon, 25 Jun 2007, Oliver Neukum wrote:
1.1, the device is still handled by uhci_hcd.
That indicates that something's wrong in uhci's root hub code.
Just for completness, below is what dev_dbg gives.
This is the case which is OK - I turn the autosuspend on, let the keyboard
suspend, wait
On Mon, 25 Jun 2007, Oliver Neukum wrote:
Am Montag, 25. Juni 2007 schrieb Jiri Kosina:
On Fri, 22 Jun 2007, Oliver Neukum wrote:
could you please run two tests?
1. set the autosuspend timeout to 0 (this'll kill usb mice)
And it kills also my testing keyboard on the UHCI system.
On Mon, 25 Jun 2007, Alan Stern wrote:
That indicates that something's wrong in uhci's root hub code.
Could well be. I'll try duplicating the experiment: suspend the
keyboard and less than 2 seconds later type some keys. I don't have the
HID-autosuspend patch installed, but a manual
On Mon, 25 Jun 2007, Jiri Kosina wrote:
On Mon, 25 Jun 2007, Oliver Neukum wrote:
1.1, the device is still handled by uhci_hcd.
That indicates that something's wrong in uhci's root hub code.
Just for completness, below is what dev_dbg gives.
This is the case which is OK - I turn
On Mon, 25 Jun 2007, Alan Stern wrote:
These logs look correct. The difference might have something to do with
the timing of the USB messages relative to the keystrokes. Or maybe the
keyboard itself has some weird 2-second timer.
Hi Alan,
thanks for looking at it. I have tried with two
Am Montag, 25. Juni 2007 schrieb Jiri Kosina:
Just for completness, below is what dev_dbg gives.
This is the case which is OK - I turn the autosuspend on, let the keyboard
suspend, wait for more than 2 seconds, hit a few keys, everything works:
What does the trace look like if you increase
On Mon, 25 Jun 2007, Jiri Kosina wrote:
On Mon, 25 Jun 2007, Alan Stern wrote:
These logs look correct. The difference might have something to do with
the timing of the USB messages relative to the keystrokes. Or maybe the
keyboard itself has some weird 2-second timer.
Hi Alan,
On Mon, 25 Jun 2007, Alan Stern wrote:
With usbmon it's possible to see exactly what packets are transferred.
The packets used for doing the resume always follow the same pattern.
The only difference is the Interrupt data carrying the keystroke
information. The device simply does not
On Mon, 25 Jun 2007, Jiri Kosina wrote:
On Mon, 25 Jun 2007, Alan Stern wrote:
With usbmon it's possible to see exactly what packets are transferred.
The packets used for doing the resume always follow the same pattern.
The only difference is the Interrupt data carrying the keystroke
I tried another test, this time using Oliver's patch. With both UHCI
and OHCI controllers the results were about the same. Sometimes my
keystrokes would be received and sometimes they wouldn't. It may have
been connected with how quickly I typed, but there also appeared to be
a certain degree
Am Freitag, 22. Juni 2007 schrieb Jiri Kosina:
On Mon, 28 May 2007, Oliver Neukum wrote:
Sure, it still could be a HW issue (I have experienced this with two
random keyboards I used for testing), but I'd guess it would be
something different than what you describe. What do you think?
On Mon, 28 May 2007, Oliver Neukum wrote:
Sure, it still could be a HW issue (I have experienced this with two
random keyboards I used for testing), but I'd guess it would be
something different than what you describe. What do you think?
Have you varied the computer or only the keyboard?
On Wed, 23 May 2007, Alan Stern wrote:
I suspect it is keyboard-dependent. For example, the keyboard's
internal buffer might be able to hold no more than one event,
because the designers expected the host to poll frequently. Since
the polling can't occur during the wakeup
Am Montag, 28. Mai 2007 16:37 schrieb Jiri Kosina:
Sure, it still could be a HW issue (I have experienced this with two
random keyboards I used for testing), but I'd guess it would be something
different than what you describe. What do you think?
Have you varied the computer or only the
On Mon, 28 May 2007, Jiri Kosina wrote:
Hi Alan,
you are right, however there is still a reason I think that this is not
the case.
What I am seeing is that the keypresses are lost only if I hit a key (and
thus wake the autosuspended keyboard up) only after a short time it goes
to
Hi,
this may be it.
open issues:
- waiting on Jiri's comment about what to do if waiting for io gets
a timeout during suspend()
Other than that it has all features I planned for and were requested.
It should work now. I am now taking comments on coding style :-)
I request testing and remind
On Wed, 23 May 2007, Oliver Neukum wrote:
- waiting on Jiri's comment about what to do if waiting for io gets
a timeout during suspend()
Hi Oliver,
I think that whenever usbhid_wait_io() times out during suspend, it is
fine to kill the URB, as it doesn't seem to make any more harm compared
Am Mittwoch, 23. Mai 2007 13:36 schrieb Jiri Kosina:
On Wed, 23 May 2007, Oliver Neukum wrote:
- waiting on Jiri's comment about what to do if waiting for io gets
a timeout during suspend()
Hi Oliver,
I think that whenever usbhid_wait_io() times out during suspend, it is
fine to
On Wed, 23 May 2007, Oliver Neukum wrote:
I have quite a lot of things pending, but will test this ASAP.
I've tested normal operations on OHCI and EHCI and STR with a mouse,
a keyboard and a PID joystick (just plugged in)
Hi Oliver,
well, I remember to having this reported also against one
Am Mittwoch, 23. Mai 2007 16:23 schrieb Jiri Kosina:
On Wed, 23 May 2007, Oliver Neukum wrote:
I have quite a lot of things pending, but will test this ASAP.
I've tested normal operations on OHCI and EHCI and STR with a mouse,
a keyboard and a PID joystick (just plugged in)
Hi Oliver,
On Wed, 23 May 2007, Oliver Neukum wrote:
well, I remember to having this reported also against one of the very
first versions of your patch - I still experience loss of events from
the device that is being woken up shortly after it goes to suspend.
I.e. as soon as the device goes to
Am Mittwoch, 23. Mai 2007 16:37 schrieb Jiri Kosina:
On Wed, 23 May 2007, Oliver Neukum wrote:
well, I remember to having this reported also against one of the very
first versions of your patch - I still experience loss of events from
the device that is being woken up shortly after
On Wed, 23 May 2007, Oliver Neukum wrote:
I will debug. Maybe just this particular keyboard is clumsy. I will try
with various different hardware. But if there are lots of HID hardware out
there which expose this broken behavior, it would be bad.
No, I cannot replicate this. I see all
On Wed, 23 May 2007, Alan Stern wrote:
I suspect it is keyboard-dependent. For example, the keyboard's
internal buffer might be able to hold no more than one event, because
the designers expected the host to poll frequently. Since the polling
can't occur during the wakeup interval,
On Wed, 23 May 2007, Jiri Kosina wrote:
On Wed, 23 May 2007, Alan Stern wrote:
I suspect it is keyboard-dependent. For example, the keyboard's
internal buffer might be able to hold no more than one event, because
the designers expected the host to poll frequently. Since the polling
29 matches
Mail list logo
