Message-ID: <Pine.LNX.4.44L0.1110152136460.19724-100000@netrider.rowland.org>
Date:	Sat, 15 Oct 2011 21:49:44 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	NeilBrown <neilb@...e.de>
cc:	markgross@...gnar.org, <linux-kernel@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, <arve@...roid.com>,
	<amit.kucheria@...aro.org>, <farrowg@...ibm.com>,
	"Dmitry Fink (Palm GBU)" <Dmitry.Fink@...m.com>,
	<linux-pm@...ts.linux-foundation.org>, <khilman@...com>,
	Magnus Damm <damm@...nsource.se>, <mjg@...hat.com>,
	<peterz@...radead.org>
Subject: Re: [markgross@...ngar.org: [RFC] wake up notifications and suspend
 blocking (aka more wakelock stuff)]

On Sun, 16 Oct 2011, NeilBrown wrote:

> > > > 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.

All right, let's make things a little more complicated.

Here's what actually happens when a USB keyboard generates a wakeup 
request.  The system wakes up, of course, but there's no particular 
indication of the cause.  In particular, the usbhid driver has no way 
to know directly that the keyboard was the reason for the wakeup.

In addition, usbhid can't poll keyboards to see if they have an event
to report.  (In theory it could -- the HID protocol allows for this --
but many keyboards don't support that part of the protocol properly.)  
It has to wait until the keyboard gets around to reporting the event, 
which can take 10 ms or more.

Taken together, this means usbhid must activate a wakeup_source every
time it wakes up.  If a keyboard event report is received reasonably
quickly then good, it can deactivate the wakeup_source at the right
time.  But if not, all the driver can do is time out the wakeup_source
after some delay.  I don't see any way to avoid it.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists