[laptop-mode] usbhid autosuspend

[Ritesh Raj Sarraf]

--nextPart624355904.S4HSUR4Nou
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

On Monday 27 Jul 2009 18:18:17 list at phuk.ath.cx wrote:
> > 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.
>

The pre-2.6.30 behavior just fooled all of us. While it said that it was=20
saving power, it never really did. That's what the bugzilla says, that you=
=20
linked in the original post.

> 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.
>
This is the current case. And it indeed doesn't help. And yes, the use case=
 is=20
very valid.

> 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.
>
Yes, and that is what is not good. The purpose of laptop-mode-tools is to s=
ave=20
power. :-(

> 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.
>
I think what you propose here is something very nice.
Customizing the default setup (that includes finding the kernel module et=20
cetera) is not the job of a noob. So I think it should be perfectly fine to=
 go=20
with 3, if we can.

> 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.
>
That'd be nice. I'd appreciate if you could submit a patch.

> > 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.
>
IMO, the driver maintainer should be the actual person blacklisting flaky=20
devices in the driver itself.
It is already being done in the kernel.

Regards,
Ritesh
=2D-=20
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

--nextPart624355904.S4HSUR4Nou
Content-Description: This is a digitally signed message part.
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.samwel.tk/pipermail/laptop-mode/attachments/20090727/af30c6f4/attachment.pgp>

--nextPart624355904.S4HSUR4Nou--