Hi, Sorry to be jumping in late. My few comments dispersed with individual replies >-----Original Message----- >From: Dmitry Torokhov [mailto:dmitry.torokhov@xxxxxxxxx] >Sent: Tuesday, October 12, 2010 3:39 AM > > >I do not believe there is a generic answer - different devices, >different options. For example I could see buttons split into 2 groups - >"important" ones that bring the system from sleep or "stupor" and "not >so important" that gets to be ignored. Or user woudl need to "flick" >the screen. Or toss the phone into a corner cussing :) > Yes. At least on the U8500 (and couple of OMAPs as well), it is the always-on power button on AB8500/TWLs that is the necessary event to turn off the display/keypad. The entire display/keypad themselves cannot wakeup the system. But on the older phones, we generally had to have the menu + star combination to unlock the phone, which falls into the main keypad. >The point is that there seems to be a need for kicking devices into low >power mode and I woudl like to have generic interface for that, >preferrably reusing (as far as kernel drivers go) existing PM >infrastructure. Coming in late, I would just like to summarize some of the points; please correct if I am wrong: - user space intervention is required to communicate specific events to individual devices to put them into an appropriate power state. - auto suspend isn't the correct choice for input devices as they may conflict with system suspend (touch screen off/idle needs to be sync'ed with system suspend as with a lock switch) - PM ATM doesn't provide a sysfs attribute for enabling/disabling or forcing an individual device into low power mode unlike for platform. However a new "suspend_ondemand" flag can enable such devices to be put into appropriate states via a /sys/devices/.../power/ by the user space. If my above summarization is correct, I personally feel the on demand flag is a clean option for the current requirement. Cheers! Sundar -- 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
