On Wed, Jul 16, 2014 at 4:23 PM, Bastien Nocera [off-list ref] wrote:

On Thu, 2014-07-17 at 01:33 +0200, Rafael J. Wysocki wrote:

quoted

On Thursday, July 17, 2014 01:13:42 AM Bastien Nocera wrote:

quoted

On Thu, 2014-07-17 at 01:11 +0200, Rafael J. Wysocki wrote:

quoted

On Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:

quoted

(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?

Pretty much, although the devices would not listen to events
themselves but rather there will be an entity listening for various
events and requesting certain devices to quiesce themselves in
response for such events.

<snip>

quoted

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.

We are not planning on implementing the policy in kernel, that's
indeed task for userspace; but unless we bring in the heavy hammer of
forcibly unbinding drivers, we do not currently have universal
mechanism of quiescing devices.

Thanks,
Dmitry