From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Bastien Nocera <hadess@hadess.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:33:50 +0200
Message-ID: <1463038.d2xocpRFLY@vostro.rjw.lan>
User-Agent: KMail/4.11.5 (Linux/3.16.0-rc5+; KDE/4.11.5; x86_64; ; )
In-Reply-To: <1405552422.17757.5.camel@nuvo>
References: <20140716013206.GA13409@google.com> <5611777.bNi5p029gt@vostro.rjw.lan> <1405552422.17757.5.camel@nuvo>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"
Sender: linux-kernel-owner@vger.kernel.org

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?
> 
> FWIW, I wouldn't build all this complication into the kernel, I would
> expect:
> - the kernel to make it easy to detect which of those devices are
> internal to the machine
> - make it easy to detect the state of the whole machine (for some
> laptops like the Yoga, there's no SW_TABLET reporting)
> - let well-behaved user-space handle the combined information (eg. it's
> an internal device + lid is closed = shouldn't be used)
> 
> For input devices for example, I'd build this into gnome-settings-daemon
> or gnome-shell directly, both of which have knowledge about input
> devices used. I'd expect other desktop environments to do similar
> things.
> 
> Applications can already check the lid status (through UPower), and with
> the additional metadata from the kernel, know that the webcam won't be
> usable when the lid is closed. Switching to external webcam, a webcam on
> the outside of the case, or switch off the video stream would then be
> the expected behaviour.

Well, is the scenario I described correct or not?  If not, then what
exactly is the scenario you want to be able to handle?

Rafael

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