Am Dienstag, 28. Oktober 2008 19:08:36 schrieb Yi Yang:

On Tue, 2008-10-28 at 01:47 -0700, Oliver Neukum wrote:

quoted

Am Dienstag, 28. Oktober 2008 17:26:02 schrieb Yi Yang:

quoted

quoted

This uses the USB busy mechanism for aggessive autosuspend of USB
HID devices. It autosuspends all opened devices supporting remote wakeup
after a timeout unless

- output is being done to the device
- a key is being held down (remote wakeup isn't triggered upon key release)
- LED(s) are lit

Why we shouldn't autosuspend it if it has LED lit?

If you suspend LEDs go dark. You'd hit e.g. caps lock, the LED would go
bright and two seconds later dark. That's no good.

we can set longer intervel to aviod it to autosuspend in short interval.

I don't think lighting LED is one reason we can't autosuspend, display
is a good example for this, the system will suspend to ram or hibernate
if the user leaves very long although display is bright.

You can set a longer period and override the LED restriction by means
of a module parameter if you like. But the driver has to work with short
timeouts and by default it cannot reduce functionality.

It is possible that we would suspend the device after a secondary longer
timeout even if LEDs are lit. But I don't see why the driver should initiate
this. It should probably be left to user space.
I see this issue as orthogonal to "true" kernel space autosuspend.
I am not sure what interface would be best suited to that task.

	Regards
		Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html