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, Oliver Neukum wrote:
del_timer_sync(usbhid-io_retry);
+ cancel_work_sync(usbhid-restart_work);
flush_scheduled_work();
Hi Oliver,
isn't the call to flush_scheduled_work() after cancel_work_sync()
redundant?
Also, we could very probably use the
Am Mittwoch, 30. Mai 2007 17:25 schrieb Jiri Kosina:
On Wed, 23 May 2007, Oliver Neukum wrote:
del_timer_sync(usbhid-io_retry);
+ cancel_work_sync(usbhid-restart_work);
flush_scheduled_work();
Hi Oliver,
isn't the call to flush_scheduled_work() after cancel_work_sync()
Am Mittwoch, 30. Mai 2007 17:25 schrieb Jiri Kosina:
On Wed, 23 May 2007, Oliver Neukum wrote:
del_timer_sync(usbhid-io_retry);
+ cancel_work_sync(usbhid-restart_work);
flush_scheduled_work();
Hi Oliver,
isn't the call to flush_scheduled_work() after cancel_work_sync()
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
Am Dienstag, 22. Mai 2007 18:50 schrieb Jiri Kosina:
I think that this is unfortunately not true. Let's take system with
multiple keyboards and their LEDs as an excellent example again. If you
kill the interrupt URB, there is nothing what will prevent other keyboard
(PS/2 or even USB
Am Dienstag, 22. Mai 2007 19:18 schrieb Alan Stern:
On Tue, 22 May 2007, Oliver Neukum wrote:
Yes, but if you are in pre_reset, chances are something is wrong
with the devices. Outright slaughter of all outstanding URBs is better
than waiting for them to complete.
Fair enough. I
Am Dienstag, 22. Mai 2007 18:50 schrieb Jiri Kosina:
On Tue, 22 May 2007, Alan Stern wrote:
But if you kill the interrupt URB then there will be no more inputs and
hence nothing to generate any more output. Thus, when suspending you
should kill the inputs and wait for the outputs 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, Oliver Neukum wrote:
That gives me an idea.
Resumption of a device has to be done in task context. So if I allocate
a private freezable work queue for HID resumption, the freezer would
guard against illicit resumptions, wouldn't it?
You can use the ksuspend_usb_wq
Am Mittwoch, 23. Mai 2007 17:42 schrieb Alan Stern:
On Wed, 23 May 2007, Oliver Neukum wrote:
That gives me an idea.
Resumption of a device has to be done in task context. So if I allocate
a private freezable work queue for HID resumption, the freezer would
guard against illicit
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
Hi,
(on0001)
this version uses usbcore pm workqueue as Alan suggested. It is relative
to the last patch I sent, which I retroactively christen on.
Regards
Oliver
--- linux-2.6.22-rc2/include/linux/hid.h2007-05-22 14:50:58.0
+0200
+++
Hi,
this is the newest version of autosuspend for HID devices. It fixes:
- Pete: removal of dead members of a struct
- Alan: open/suspend race
- Jiri: PID devices are exempt
- Jiri: any device that is served by hiddev is exempt
- fixed a race between close and resume
- proper error handling in
On Tue, 22 May 2007, Oliver Neukum wrote:
- Jiri, is there a _category_ of HID devices that should not be
autosuspended at all?
Hi Oliver,
thanks for updating the patch. I am not quite sure right now whether I can
come up with a category that should not be suspended at all, but I will
Am Dienstag, 22. Mai 2007 13:28 schrieb Jiri Kosina:
Hi,
There is a principal issue. What is to be done with output requests?
Starting the queue as soon as one arrives seems the safest thing to do,
but it is fatal in a subset of situations, that is, it must not be done
during
Hi,
this is the newest version of autosuspend for HID devices. It fixes:
- Jiri: shifting code around
- forgot to kill output urbs upon suspend
- pre/post_reset methods
Regards
Oliver
--
--- linux-2.6.22-rc2/include/linux/hid.h2007-05-22 14:50:58.0
On Tue, 22 May 2007, Oliver Neukum wrote:
- Alan, do you have strong feelings about putting all conditions
for failing to suspend into one condition? I consider it conceptually
cleaner to have seperate branches for wanting to check for failure
It looks like you've got two conditions for
Am Dienstag, 22. Mai 2007 16:59 schrieb Alan Stern:
On Tue, 22 May 2007, Oliver Neukum wrote:
On the other hand, I still think you'd be better off with only one
spin_lock_irq() call in hid_suspend(). After all, you always have to
synchronize with the error handler, no matter what kind of
On Tue, 22 May 2007, Alan Stern wrote:
But if you kill the interrupt URB then there will be no more inputs and
hence nothing to generate any more output. Thus, when suspending you
should kill the inputs and wait for the outputs to drain (or else
explicitly plug the output queue). Then it
On Tue, 22 May 2007, Oliver Neukum wrote:
TODO
- pre/post_reset is currently broken, it can no longer be a parasite
on suspend/resume
Why not? The only difference I can see is that you're allowed to fail
a suspend but not a pre_reset.
Yes, but if you are in pre_reset,
On Tue, 22 May 2007, Alan Stern wrote:
- adapt to hibernate
What adaptations are needed?
Do I need to kill remote wakeup?
No. It should be handled at a higher level. (Right now we don't
really handle it properly; this is partly the fault of the PM core.)
This isn't is bad
On Mon, 21 May 2007, Oliver Neukum wrote:
- what to do with devices with force feedback? (or PID devices in
general). The effect could have up to infinite duration (until it is
stopped by appropriate stop method), and we definitely absolutely
must not autosuspend a device that is
Am Mittwoch, 16. Mai 2007 17:20 schrieb Alan Stern:
@@ -592,8 +604,21 @@ static int hid_get_class_descriptor(stru
int usbhid_open(struct hid_device *hid)
{
struct usbhid_device *usbhid = hid-driver_data;
+ int res;
- hid-open++;
+ mutex_lock(hid_open_mut);
+
Hi Oliver,
what about something like
int hidinput_has_ff(struct hid_device *hid)
{
struct hid_input *hidinput;
list_for_each_entry(hidinput, hid-inputs, list)
if (test_bit(EV_FF, hidinput-input-evbit))
Am Mittwoch, 16. Mai 2007 15:07 schrieb Pete Zaitcev:
On Wed, 16 May 2007 07:37:04 +0200, Oliver Neukum [EMAIL PROTECTED] wrote:
+ /* Task context for reporting idleness */
+ struct work_struct idle_work;
This does not seem to be used anywhere.
Yes. Killed.
Thanks
On Mon, 21 May 2007, Oliver Neukum wrote:
Am Mittwoch, 16. Mai 2007 17:20 schrieb Alan Stern:
@@ -592,8 +604,21 @@ static int hid_get_class_descriptor(stru
int usbhid_open(struct hid_device *hid)
{
struct usbhid_device *usbhid = hid-driver_data;
+ int res;
-
Am Montag, 21. Mai 2007 17:32 schrieb Alan Stern:
On Mon, 21 May 2007, Oliver Neukum wrote:
Am Mittwoch, 16. Mai 2007 17:20 schrieb Alan Stern:
Don't you need to do usb_autopm_get_interface() before hid_start_in()?
hid_start_in() takes the spinlock and checks for a suspension. In the
Am Montag, 21. Mai 2007 17:49 schrieb Oliver Neukum:
But this code runs whenever a process opens the device file. If the
device is suspended at that time, there might not be a remote wakeup
request pending. So you'd run into trouble unless you did an
autoresume before calling
On Mon, 21 May 2007, Oliver Neukum wrote:
I guess it's just a theoretical problem. The whole point of the
last_busy field is to prevent autosuspend too soon after any I/O. So
if an URB does complete and nevertheless the device is suspended a few
milliseconds later, then last_busy hasn't
Am Mittwoch, 16. Mai 2007 15:41 schrieb Jiri Kosina:
On Wed, 16 May 2007, Pete Zaitcev wrote:
I did not verify the function in detail, but the patch looks sane at a
quick glance.
Hi Pete and Oliver,
(BTW, why was I again dropped from CC? :) )
I consider the things below crucial
Oliver Neukum schrieb:
Am Dienstag, 15. Mai 2007 16:43 schrieb Robert Marquardt:
Oliver Neukum schrieb:
The main problem implementing this is LEDs. HID has the very though
property of initiating output to them without user space's involvement
from interrupt context to all attached devices.
Am Mittwoch, 16. Mai 2007 08:41 schrieb Robert Marquardt:
Oliver Neukum schrieb:
Am Dienstag, 15. Mai 2007 16:43 schrieb Robert Marquardt:
Oliver Neukum schrieb:
The main problem implementing this is LEDs. HID has the very though
property of initiating output to them without user
Oliver Neukum schrieb:
Writing reports to a device from kernel? Why would that be needed?
It is in my experience mainly needed for setting and clearing the LEDs.
But I don't claim to know all input devices in the kernel tree.
Does hat really have to be handled on low-level? It should be
Am Mittwoch, 16. Mai 2007 10:24 schrieb Robert Marquardt:
Oliver Neukum schrieb:
Writing reports to a device from kernel? Why would that be needed?
It is in my experience mainly needed for setting and clearing the LEDs.
But I don't claim to know all input devices in the kernel tree.
On Wed, 16 May 2007, Robert Marquardt wrote:
Writing reports to a device from kernel? Why would that be needed?
It is in my experience mainly needed for setting and clearing the LEDs.
But I don't claim to know all input devices in the kernel tree.
Does hat really have to be handled on
On Tue, 15 May 2007, Oliver Neukum wrote:
this is autosuspend for HID devices. It uses the new last_busy facility
for USB devices. And for a few functions the pm counter.
Hi Oliver,
just a quick immediate note - I just tested it on my testing box, and it
doesn't seem to work for me - the
Jiri Kosina schrieb:
first, why did you remove me from CC when responding?
Sorry, on too many lists with widely varying reply rules. Just goofed.
Anyway, what would be your proposal here? Currently the output reports
(for changing the keyboard LEDs, for example) are being submitted as soon
Am Mittwoch, 16. Mai 2007 11:24 schrieb Jiri Kosina:
On Tue, 15 May 2007, Oliver Neukum wrote:
this is autosuspend for HID devices. It uses the new last_busy facility
for USB devices. And for a few functions the pm counter.
Hi Oliver,
just a quick immediate note - I just tested it on
On Wed, 16 May 2007, Robert Marquardt wrote:
Anyway, what would be your proposal here? Currently the output reports
(for changing the keyboard LEDs, for example) are being submitted as
soon as the corresponding input event occurs (on different keyboard),
which makes sense. Could you be
Am Mittwoch, 16. Mai 2007 11:24 schrieb Jiri Kosina:
just a quick immediate note - I just tested it on my testing box, and it
doesn't seem to work for me - the USB keyboard still seems to be awake
(leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order
to suspend it
On Wed, 16 May 2007, Oliver Neukum wrote:
just a quick immediate note - I just tested it on my testing box, and
it doesn't seem to work for me - the USB keyboard still seems to be
awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs
in order to suspend it immediately.
On Wed, 16 May 2007, Oliver Neukum wrote:
And as a sanity check, please check with lsusb whether your keyboard can
do remote wakeup. I've never seen one that doesn't but it is within
spec.
Suspending of this keyboard used to work with older versions of your
patches you sent me some
Jiri Kosina schrieb:
just a quick immediate note - I just tested it on my testing box, and it
doesn't seem to work for me - the USB keyboard still seems to be awake
(leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order
to suspend it immediately.
Ah, that was nagging
On Wed, 16 May 2007, Robert Marquardt wrote:
just a quick immediate note - I just tested it on my testing box, and
it doesn't seem to work for me - the USB keyboard still seems to be
awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs
in order to suspend it
Am Mittwoch, 16. Mai 2007 11:41 schrieb Jiri Kosina:
On Wed, 16 May 2007, Oliver Neukum wrote:
And as a sanity check, please check with lsusb whether your keyboard can
do remote wakeup. I've never seen one that doesn't but it is within
spec.
Suspending of this keyboard used to work
Am Mittwoch, 16. Mai 2007 11:40 schrieb Robert Marquardt:
Jiri Kosina schrieb:
just a quick immediate note - I just tested it on my testing box, and it
doesn't seem to work for me - the USB keyboard still seems to be awake
(leds are on), even if I echo 0 into 'autosuspend' file in sysfs
Am Mittwoch, 16. Mai 2007 11:48 schrieb Jiri Kosina:
On Wed, 16 May 2007, Robert Marquardt wrote:
just a quick immediate note - I just tested it on my testing box, and
it doesn't seem to work for me - the USB keyboard still seems to be
awake (leds are on), even if I echo 0 into
Oliver Neukum schrieb:
Am Mittwoch, 16. Mai 2007 11:40 schrieb Robert Marquardt:
Jiri Kosina schrieb:
just a quick immediate note - I just tested it on my testing box, and it
doesn't seem to work for me - the USB keyboard still seems to be awake
(leds are on), even if I echo 0 into
On Wed, 16 May 2007, Oliver Neukum wrote:
Actually, there's currently a race in the code that can trigger if you
It is my understanding that a PID effect can be active long after the
message went out to the device. Is that correct?
Yes, I am afraid you can't assume that the effect playback
Am Dienstag, 15. Mai 2007 16:37 schrieb Alan Stern:
Can you break this up into two patches? If the first adds the queuing
code and the second adds autosuspend support, it will be much easier to
appraise and test them.
Here's part #2, the core autosuspend.
Regards
Am Mittwoch, 16. Mai 2007 12:01 schrieb Robert Marquardt:
A suspended bus-powered USB device cannot drive LEDs so suspending an
USB keyboard with CAPS LOCK on means it gets out of sync.
How much power does an LED need? You have 2mA in suspended mode.
A standard LED uses about 20 mA
On Wed, 16 May 2007, Oliver Neukum wrote:
Suspending of this keyboard used to work with older versions of your
patches you sent me some weeks/months ago.
Yes, then it should keep working. My keyboard does suspend.
Could you post your syslog?
I have had also one very strange (and broken in
On Wed, 16 May 2007 07:37:04 +0200, Oliver Neukum [EMAIL PROTECTED] wrote:
+ /* Task context for reporting idleness */
+ struct work_struct idle_work;
This does not seem to be used anywhere.
I did not verify the function in detail, but the patch looks sane at
a quick glance.
-- Pete
On Wed, 16 May 2007, Pete Zaitcev wrote:
I did not verify the function in detail, but the patch looks sane at a
quick glance.
Hi Pete and Oliver,
(BTW, why was I again dropped from CC? :) )
I consider the things below crucial before this could be merged:
- what to do with devices with
On Wednesday 16 May 2007, Oliver Neukum wrote:
Am Mittwoch, 16. Mai 2007 11:40 schrieb Robert Marquardt:
A suspended bus-powered USB device cannot drive LEDs so suspending an
USB keyboard with CAPS LOCK on means it gets out of sync.
How much power does an LED need? You have 2mA in
On Wed, 16 May 2007, Oliver Neukum wrote:
Here's part #2, the core autosuspend.
@@ -230,12 +239,14 @@ static void hid_irq_in(struct urb *urb)
switch (urb-status) {
case 0: /* success */
+ usbhid_mark_busy(usbhid);
Hi,
this is autosuspend for HID devices. It uses the new last_busy facility
for USB devices. And for a few functions the pm counter.
The main problem implementing this is LEDs. HID has the very though
property of initiating output to them without user space's involvement
from interrupt context
On Tue, 15 May 2007, Oliver Neukum wrote:
Hi,
this is autosuspend for HID devices. It uses the new last_busy facility
for USB devices. And for a few functions the pm counter.
The main problem implementing this is LEDs. HID has the very though
property of initiating output to them
Oliver Neukum schrieb:
The main problem implementing this is LEDs. HID has the very though
property of initiating output to them without user space's involvement
from interrupt context to all attached devices. Doing this with suspended
devices is problematic.
Is that setting the keyboard
Am Dienstag, 15. Mai 2007 16:37 schrieb Alan Stern:
Can you break this up into two patches? If the first adds the queuing
code and the second adds autosuspend support, it will be much easier to
appraise and test them.
Very well. I'll do so.
Regards
Oliver
--
SUSE
Am Dienstag, 15. Mai 2007 16:43 schrieb Robert Marquardt:
Oliver Neukum schrieb:
The main problem implementing this is LEDs. HID has the very though
property of initiating output to them without user space's involvement
from interrupt context to all attached devices. Doing this with
Am Dienstag, 15. Mai 2007 16:37 schrieb Alan Stern:
Can you break this up into two patches? If the first adds the queuing
code and the second adds autosuspend support, it will be much easier to
appraise and test them.
Hi,
this code implements delayed execution of output requests arriving
Hi!
Can you break this up into two patches? If the first adds the queuing
code and the second adds autosuspend support, it will be much easier to
appraise and test them.
Hi,
this code implements delayed execution of output requests arriving
for suspended HID devices.
usbhid.h
Am Dienstag, 15. Mai 2007 22:45 schrieb Pavel Machek:
Hi!
Can you break this up into two patches? If the first adds the queuing
code and the second adds autosuspend support, it will be much easier to
appraise and test them.
Hi,
this code implements delayed execution of
90 matches
Mail list logo
