> From: Pavel Machek [mailto:pavel@xxxxxx] > Sent: Tuesday, February 10, 2009 7:15 AM > > Not sure this is your point. But when doing PowerTop based debug in our > Linux userspace we found several applications using select() (or some variant) > with a much short timeout than needed. In effect they were polling and > keeping the system alive. > > > > In the cases it was an application in our control we converted it to > something sane. > > > > No, that's something different. > > 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. Regards, Richard W. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
