On Mon, 21 Sep 2015, Dmitry Torokhov wrote:

On Mon, Sep 21, 2015 at 10:38:46AM -0400, Alan Stern wrote:

quoted

On Mon, 21 Sep 2015, Pavel Machek wrote:

quoted

quoted

quoted

In fact, then, what you need seems to be the feature discussed by Alan
and me some time ago allowing remote wakeup do be disabled for runtime
PM from user space as that in combination with autosuspend should
address your use case.

That, plus they want the touchscreen to go into runtime suspend 
whenever the screen is off (was this not the main reason for the 
patch?).

It seems to me that it should be possible to arrange for this to happen 
simply by making userspace close the touchscreen device when the screen 
is turned off.  Or am I missing something?

Well... that's not what existing userspace expects. Your X windows
server will not close the touchscreen.

Surely that's a userspace issue, rather than a kernel problem?  The X
server does have some notion of power management and power savings; why
not extend that notion to include touchscreens?

It is not really practical: there are many consumers of input events, if
we build infrastructure to control it and proxy all users through it,
why not have it in kernel? Plus, there are users of input events
directly in the kernel, such as legacy VT/keyboard, or Android/ChromeOS
cpufreq_interactive governor that monitors user activity and bumps up
CPU speed when user actively interacts with the device. They would keep
input devices active even though user might not be actually able to
use some input devices.

It sounds like you are suggesting there should be a general mechanism
for userspace to tell the kernel (or the input core) to ignore all
events from a particular input device -- or even from all input devices
-- thereby allowing those devices to go to low power.

I don't like to think of this as "forcing runtime suspend".  It's more
like telling the kernel that a device is no longer being used, so the
natural runtime PM mechanism can put it in runtime suspend.

Perhaps another way to think about it is that these input devices 
should not increment their runtime usage counter as part of the open 
routine; they should use something other than the number of open file 
references to indicate when they can go into runtime suspend.  (I'm not 
sure what else they should use, though.)

Alan Stern