Thread (10 messages) 10 messages, 4 authors, 2012-02-16

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

From: Arve Hjønnevåg <arve@android.com>
Date: 2012-02-13 23:52:18
Also in: lkml

2012/2/11 Rafael J. Wysocki [off-list ref]:
Hi,

On Saturday, January 21, 2012, Arve Hjønnevåg wrote:
quoted
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.
I have two questions to start with, if you don't mind:

(1) Does Android user space use an analogous interface right now or is it
   a prototype?
Yes (for the next version), but with a wakelock based implementation.
(2) What exactly are the use cases for it (ie. what problem does it address
   that cannot be addressed in a different way)?
The reason for adding an ioctl versus the old android version with
used a wakelock for all input events, is that not all input events are
wakeup events. Specifically some sensors generate input events at such
a high rate that they prevent suspend while the sensor is on even
though the driver has a suspend hook that turns the sensor off.

If you are asking why input events need to block suspend at all, this
was the example used in the suspend blocker documentation:
- The Keypad driver gets an interrupt. It then calls suspend_block on the
  keypad-scan suspend_blocker and starts scanning the keypad matrix.
- The keypad-scan code detects a key change and reports it to the input-event
  driver.
- The input-event driver sees the key change, enqueues an event, and calls
  suspend_block on the input-event-queue suspend_blocker.
- The keypad-scan code detects that no keys are held and calls suspend_unblock
  on the keypad-scan suspend_blocker.
- The user-space input-event thread returns from select/poll, calls
  suspend_block on the process-input-events suspend_blocker and then calls read
  on the input-event device.
- The input-event driver dequeues the key-event and, since the queue is now
  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
- The user-space input-event thread returns from read. If it determines that
  the key should be ignored, it calls suspend_unblock on the
  process_input_events suspend_blocker and then calls select or poll. The
  system will automatically suspend again, since now no suspend blockers are
  active.


-- 
Arve Hjønnevåg
--
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help