["Woodruff, Richard" <r-woodruff2@xxxxxx>] > > From: Pavel Machek [mailto:pavel@xxxxxx] > > > > Apparently, on android, if there's event ready on one of the input > > devices, system will not go to sleep. That's quite an "interesting" > > behaviour. > > > > Heh, they could rely on it and get rid of the wakelock. Just create > > strange device that disallows system sleep when you select() on it, > > and allows it when you read() from it :-). > > Ok, thanks. When I looked quickly a couple months back I thought they > raised a user space side wake locks on input consumers. These > translated back to the kernel lock and keep the system up. > > Gist was something like you don't want to sleep until user activity > data was processed. Any high latency sleep/suspend would be perceived > by user. The intention is to make sure we hand-off "awakeness" from kernel to userspace when the system is waking up to process an event. Which is why the event dispatcher in the framework select()s, grabs a wakelock if readable (overlapping with the wakelock held when data is in the input queue in the kernel), read()s the events (causing the kernel side to drop its lock when the queue is empty) and dispatches them while holding the wakelock until things are sorted out. Generally, arbitrary processes cannot open input devices in Android, so this being a mechanism for abuse of keeping the system awake has not been an issue thus far. Brian _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
