Messages in this thread | | | Date | Sun, 16 Oct 2011 09:25:56 +1100 | From | NeilBrown <> | Subject | Re: [: [RFC] wake up notifications and suspend blocking (aka more wakelock stuff)] |
| |
On Sat, 15 Oct 2011 14:45:37 -0400 (EDT) Alan Stern <stern@rowland.harvard.edu> wrote:
> On Sat, 15 Oct 2011, NeilBrown wrote: > > > On Thu, 13 Oct 2011 11:16:23 -0400 (EDT) Alan Stern > > <stern@rowland.harvard.edu> wrote: > > > > > On Thu, 13 Oct 2011, NeilBrown wrote: > > > > > > > Nope, but I'm keen for you to convince me. Identify a wakeup event that > > > > cannot be made visible to poll (or to user-space by some other > > > > mechanism) before the wakeup_source needs to be deactivated. Or if I've > > > > misunderstood what sort of notification is problematic, help me understand. > > > > > > Here's an example (just for kicks, not completely relevant to your > > > discussion): A USB keyboard key release. Unlike key presses, key > > > releases need not generate input events. If no processes are > > > monitoring the raw keyboard event queue then the release is not visible > > > to userspace at all, hence not visible before the wakeup_source needs > > > to be deactivated. > > > > > > Alan Stern > > > > As you say, not completely relevant. > > > > If a tree falls in a forest with no one to here, does it make a sound? > > > > similarly if an event happens that no-one is looking for, is it visible? > > It doesn't really matter. > > That's a different question, but I'll answer it anyway: Yes, it does > matter. If the kernel is unable to _know_ that nobody is looking for > an event, it has to _assume_ that somebody is. Then what should happen > if it turns out that nobody really is looking for it?
Same answer - it doesn't really matter. In every case, the kernel's responsibility is to make the sure the event is visible to any watching user-space process before it releases the wakeup_source. What user-space does then is up to user-space. If no-one is watching the kernel is free to drop it at any stage - as soon as it discovers no-one is watching. When the input layer gets an event, it iterated through a list of fds which are open on the event source and queues it to each one. This list might be empty - no big deal. It was still a wakeup_event. If we were suspended, the write to /sys/power/state will now complete, the suspend daemon will go back around its loop, nothing will seem to be happening, so the system will go back to sleep.
> > > So at most this is a case of "is not made visible" rather than "cannot be > > made visible". > > In this case it's the same thing. How can a key release be made > visible?
/dev/input/eventX?? the evdev driver presents key-down and key-up events separately.
> > > The key-release just needs to clear the "key is pressed" state so that > > auto-repeat stops and if it was a modifier, the modification is discarded. > > That is all trivially done in some kernel driver while the wakeup_source is > > active. > > In other words, if the event is discarded from within the kernel then > the wakeup_source can be deactivated at that time. That's fine -- but > it indicates that your original request above was phrased wrongly. You > should have asked for an example of a wakeup_source which the kernel > must not deactivate without a userspace handshake, but which cannot be > made visible by poll or some other similar mechanism.
Yes, I agree that is more precise statement of what I was trying to say - and precision is important here.
Thanks!
NeilBrown
[unhandled content-type:application/pgp-signature] | |