[laptop-mode] usbhid autosuspend

[list at phuk.ath.cx]

> The problem really lies in the drivers that expose that they can suspend but 
> go haywire when triggered. Unfortunately the kernel devs feel them to be 
> broken hardware.
That's right. The device reports that it supports autosuspend when its
autosuspend implementation is actually broken (e.g. my Logitech MX500
that just turns its light off and only wakes up when pressing a button,
or keyboards that drop keystrokes). As I understand it, the driver is
working correctly and everything is in spec. Don't know if the spec says
the user interaction for waking up a device must be totally casual and
generally NOT be realized by the users. If it doesn't say that, those
broken devices would even be within spec.
So it's actually just a design decision that userspace has to cope with
broken hardware.

> 
> Thus I'm not very sure if we want a blacklist. There can be multiple usb 
> devices, served by the same driver, but with different behavior.
I thought about that, too, but then I thought that we should "emulate"
the pre-2.6.30 behaviour at first, to avoid exposing users to the broken
behaviour of their devices. But of course, there might be usbhid devices
that actually implement autosuspend correctly.

So I think these are the options:

1. No blacklist:
Still some cases where people be annoyed. For example, I see many people
using a USB mouse when working on battery. You might just go with that
and wait for complaints, but please keep in mind that the number of
people complaining is just a small fraction of those that are out there
getting angry because something is not working when it should.

2. Blacklist with old behaviour by default:
That's what my patch does. This would minimize the number of annoyed
people, but might disable autosuspend for devices that actually work
correctly.

3. Blacklist by device-name and/or USB-ID:
Empty blacklist by default, and if you've got a broken device, you put
it in the blacklist. This is the technically "perfect" solution, but
with the gotcha-effect of users having to realize their hardware is
broken and they need to put it in a blacklist. This *might* put a tiny
little bit of extra pressure on vendors when people realize their hw is
broken.

Of course, there might also be a combination of all three. I'm willing
to implement all this if you tell me you have decided you *do* want to
have a blacklist.

> In 1.50, with LM/NOLM options, the problem can be minimized a lot. 
> So I would prefer getting the drivers fixed instead.
As I said, it's not the drivers, it's broken hardware, and we'll have to
live with that.

> PS: With bash too, you can test scripts in sh mode. Just run the scripts with 
> "sh" as the program name. Example: "sh foo.sh"
I see. Thanks. Then the code should be compliant.

thanks for your time so far...