From: Bastien Nocera <hadess@hadess.net>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Patrik Fimml <patrikf@chromium.org>,
linux-pm@vger.kernel.org, Dmitry Torokhov <dtor@google.com>,
Benson Leung <bleung@google.com>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Power-managing devices that are not of interest at some point in time
Date: Thu, 17 Jul 2014 01:23:22 +0200 [thread overview]
Message-ID: <1405553002.17757.7.camel@nuvo> (raw)
In-Reply-To: <1463038.d2xocpRFLY@vostro.rjw.lan>
On Thu, 2014-07-17 at 01:33 +0200, Rafael J. Wysocki wrote:
> On Thursday, July 17, 2014 01:13:42 AM Bastien Nocera wrote:
> > On Thu, 2014-07-17 at 01:11 +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:
> > > > (Re-sending with correct mailing list addresses.)
> > > >
> > > > Hi,
> > > >
> > > > When the lid of a laptop is closed, certain devices can no longer
> > > > provide interesting input or will even produce bogus input, such as:
> > > >
> > > > - input devices: touchscreen, touchpad, keyboard
> > > > - sensors: ambient light sensor, accelerometer, magnetometer
> > > > - a video camera mounted on the lid
> > > > - display backlight
> > > >
> > > > Various workarounds cover some of these cases, and we have some ugly
> > > > hacks in ChromeOS to make things work. It would be nice if a userspace
> > > > power management daemon could listen to the lid-close event, and then
> > > > have a way to temporarily power off these devices, potentially through
> > > > sysfs.
> > > >
> > > > I've been discussing this with Dmitry and Benson (cc'd), and we've been
> > > > wondering whether we could come up with a generic solution that could
> > > > benefit multiple device classes.
> > > >
> > > > There's some overlap with runtime PM here. The action to be taken in
> > > > such a situation would probably be similar to a runtime suspend. The
> > > > match is not perfect though, since devices with more than two power
> > > > states might want to enter different states depending on the situation.
> > > >
> > > > It's somewhat difficult to get the semantics right, since handles to
> > > > such devices might still be open. It might be easier to implement
> > > > behavior specific to device classes. On the other hand, it would be nice
> > > > to have a uniform way of shutting devices down, and not introduce
> > > > another possible path for a device to enter a power-saving state.
> > > >
> > > > Rafael, can you give us your opinion on this?
> > >
> > > Let me try to understand the scenario in the first place.
> > >
> > > To start with, a number of devices is in use (that is, open, there are
> > > applications listening/talking to them etc). Now, an event happens, such
> > > as a laptop lid close and you want some of those devices, but possibly
> > > not all of them, to quiesce themselves and go into low-power states.
> > >
> > > Is that correct?
<snip>
> Well, is the scenario I described correct or not? If not, then what
> exactly is the scenario you want to be able to handle?
I don't expect devices to have to know about the lid status, no. Patrik
might feel differently, but I think that all that's being asked is
already possible through existing user-space mechanisms, it's just
missing metadata to be able to implement it.
next prev parent reply other threads:[~2014-07-16 23:23 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-16 1:32 Power-managing devices that are not of interest at some point in time Patrik Fimml
2014-07-16 10:00 ` Bastien Nocera
2014-07-16 14:17 ` Alan Stern
2014-07-16 16:14 ` Dmitry Torokhov
2014-07-16 18:08 ` Alan Stern
2014-07-16 18:55 ` Kevin Cernekee
2014-07-16 21:36 ` Oliver Neukum
2014-07-16 17:12 ` Benson Leung
2014-07-16 23:11 ` Rafael J. Wysocki
2014-07-16 23:13 ` Bastien Nocera
2014-07-16 23:33 ` Rafael J. Wysocki
2014-07-16 23:23 ` Bastien Nocera [this message]
2014-07-16 23:31 ` Dmitry Torokhov
2014-07-17 14:39 ` Alan Stern
2014-07-17 16:59 ` Dmitry Torokhov
2014-07-18 0:43 ` Rafael J. Wysocki
2014-07-18 0:43 ` Dmitry Torokhov
2014-07-18 1:30 ` Rafael J. Wysocki
2014-07-18 1:35 ` Rafael J. Wysocki
2014-07-18 15:19 ` Alan Stern
2014-07-18 17:47 ` Patrik Fimml
2014-07-18 19:00 ` Alan Stern
2014-07-18 19:23 ` Patrik Fimml
2014-07-18 20:09 ` Alan Stern
2014-07-18 21:26 ` Dmitry Torokhov
2014-07-18 21:59 ` Rafael J. Wysocki
2014-07-18 21:45 ` Dmitry Torokhov
2014-07-18 22:19 ` Rafael J. Wysocki
2014-07-18 22:55 ` Rafael J. Wysocki
2014-07-18 23:16 ` Dmitry Torokhov
2014-07-18 23:47 ` Rafael J. Wysocki
2014-07-19 14:51 ` Alan Stern
2014-07-19 15:23 ` Benson Leung
2014-07-19 17:59 ` Alan Stern
2014-07-19 18:21 ` Dmitry Torokhov
2014-07-19 20:19 ` Rafael J. Wysocki
2014-07-21 23:23 ` hadess
2014-07-28 19:58 ` Patrik Fimml
2014-07-28 20:01 ` Patrik Fimml
2014-07-17 6:01 ` Oliver Neukum
2014-07-16 23:17 ` Patrik Fimml
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1405553002.17757.7.camel@nuvo \
--to=hadess@hadess.net \
--cc=bleung@google.com \
--cc=dtor@google.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=patrikf@chromium.org \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).