Re: [PATCH] Input: Add ioctl to block suspend while event queue is not empty.

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Tuesday, February 14, 2012, NeilBrown wrote:
> On Fri, 20 Jan 2012 18:24:16 -0800 Arve Hjønnevåg <arve@android.com> wrote:
> 
> > Add an ioctl, EVIOCSSUSPENDBLOCK, to block suspend while the event
> > queue is not empty. This allows userspace code to process input
> > events while the device appears to be asleep.
> > 
> > Signed-off-by: Arve Hjønnevåg <arve@android.com>
> 
> This is exactly the sort of "feature creep" that I worried about in my reply
> to Rafael's recent "autosleep" patches.
> 
> A particular issue here:  This patch allows any process that can open an
> input device to keep the device awake - by not reading an event that has
> arrived (whether due to incompetence or malice).
> 
> So either we would need strict controls on who can open /dev/input/eventX,
> or be happy that any process can disable suspend.
> Or add some extra feature-creep to provide access control.

I actually think the approach almost correct, because if there are any events
coming from a wakeup device and there is any user space client interested in
them, the kernel should really stay awake until those events are removed from
the client's queue.

So, if they are not read, either we drop them entirely, or we don't suspend
_automatically_.

The problem I have with the $subject patch is that it doesn't check if the
device is a wakeup one and it adds ioctls allowing user space to use the event
queue of a non-wakeup device as a "wakeup source".

> (or just keep this stuff out of the kernel and let a user-space daemon make
> those decisions).

Which is never going to really work, IMHO.

Realistically, do you know of any distro, vendor, whoever, who tried to
actually do that in a released product (or even in a release candidate,
or milestone, or whatever different from a prototype running only on one's
personal desktop)?  I don't.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html