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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
