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. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
