Re: [linux-usb-devel] error to be returned while suspended

[Oliver Neukum <oliver@neukum.org>]

Am Sonntag, 8. Oktober 2006 02:03 schrieb David Brownell:
> > A simple timeout solution has drawbacks.
> 
> Plus lots of advantages, including the not-to-be-underrated simplicity.

That simplicity means setting up timers in kernel space and determining when
a device is "active". You only simplify the interface.

> > - there's no guarantee the user wants wakeup (think laptop on crowded table)
> 
> In which case the /sys/devices/.../power/wakeup flag can be
> marked as disabled.  No wakeup ... but of course, no power
> savings either.  (One can still unplug the mouse...)

I can have suspend without wakeup. It just means that I need to
hit a key to make X notice me again.

> > - you want to suspend immediately when you blank the screen (or switch to
> > a text console)
> 
> Unrelated to USB or any other specific subsystem; the system

That is exactly the point.

> suspends by "echo mem > /sys/power/state" regardless.  (That is,
> once the bugs in ACPI, and sometimes drivers, get fixed.)

What allows you to assume that I want to suspend the whole system?
That power/latency tradeoff is not a policy to be set in kernel.

> > - you want to consider all devices' activity. I am not pleased if my mouse
> > becomes less responsive just because I used only the keyboard for a
> > few minutes. Coordinating this inside the driver is hard as some input
> > devices might well be not usb (eg. bluetooth mouse, usb tablet)
> 
> The reasons X11 becomes unresponsive have very little to do with USB
> or autosuspend; happens all the time with PS2 mice, trackpads, etc.
> Again, those issues are unrelated to USB, or to the API you said you
> wanted to see.

I did not speak about X11. I can keep X pretty busy with keyboard and
touchpad. Nevertheless my mouse has no business going to sleep even
if I don't move it and it is the only usb device.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/