Re: [linux-pm] Attempted summary of suspend-blockers LKML thread

[James Bottomley]

On Mon, 2010-08-02 at 08:12 -0400, Ted Ts'o wrote:
> On Sun, Aug 01, 2010 at 06:30:44PM -0500, James Bottomley wrote:
> > That's why you present the user with choices and report on the outcomes.
> > At the end of the day the choice becomes binary: if the mobile optimised
> > browser burns you battery on the power meter, users will either
> > uninstall and move on to the next browser or deny the current browser
> > the ability to block suspend.
> 
> Or they may decide to drop the device which has much worse battery
> lifetime in favor of the hardware that seems to do a much better job
> of controlling power overall... which is why if the Nokia folks want
> to claim that suspend blockers are no good, it's probably not going to
> change what ships with Android, and may be better power management
> strategy win.  :-)
> 
> > Right, but this comes back to the axes of control.  They have to be
> > presented to the user in a simple but meaningful manner.
> 
> In the general case, at least for today, I think it's useful if
> applications are told, "you are on AC mains", "you are on cell phone
> battery", "you are on a laptop battery".  And from a user's
> perspective, I suspect if you are wanting something simple but
> meaningful, it's probably a single linear scale ranging between
> "performance optimized" and "power optimized", with maybe 1-3
> points in between.

Actually, I don't necessarily agree with this.  In fact, I think it's a
dangerous proposition.  The reason is that the only class of
applications I've seen usefully made power aware are some of the system
housekeeping ones (as in don't index my man pages, prelink my binaries
etc. when I'm on battery power).  Perhaps I could see things that have
to poll (like imap without push support on the server) do a "poll when
woken else every X minutes", but the potential for annoying the user by
doing the wrong thing on power environment change is huge.

> Advanced users will want a much finer level of control, though --- I
> can imagine having a number of different sliders that control the
> tradeoff between power vs. performance on a number of different
> scales: networking, GPS performance, scheduler control, schreen
> brightness, etc.
> 
> Android phones have a very simplified version of this widget, which
> allows you to toggle GPS on/off, bluetooth on/off, etc.  And the GPS
> toggle is a good example of what I'm talking about.  If you disable
> the GPS, then even if the application wants to use GPS, tough luck; it
> will have to settle for the less precise cell tower triangulation
> method.  Again, it's the _user_ who gets the final say, not the
> application --- and that's as it should be.

Yes and no; agree about the user not the application but ... I actually
find the current five android "power" toggles to be largely useless.  If
I don't want GPS killing my battery, I don't start GPS using
applications, for instance rather than disabling GPS.  I think this
represents the "axis" problem again ... I like to manage my power in a
particular way, and others want to manage it in different ways.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/