linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.


  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).