Re: Problem statement: Opportunistic suspend and i8042 wakeups

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Thu, Oct 13, 2011 at 03:25:04PM +0100, Daniel Drake wrote:
> Hi,
> 
> Thanks for not getting bored of this :)
> 
> On Mon, Oct 10, 2011 at 9:38 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > I think input layer releasing keys at resume time is actually in the
> > wrong here, as it meddles with device state after physical device
> > (i8042, atkbd, etc) are fully woken up.
> 
> Yes, that's whats happening here.
> 
> > IIRC I put releasing originally in resume because I was concerned
> > with events getting discarded after S2D because we thew away the state
> > that happens after taking snapshot and there weren't enough granularity
> > in PM callbacks to differentiate between S2D and S2R.
> >
> > I believe if we move release of the keys into suspend handlers then
> > input core should not get into the middle of things for your case as you
> > said that the OLPC device will not suspend with a key still pressed and
> > upon release we would not be doing anything with key state (but
> > restore LED/SOUND only) which you do not care about.
> 
> Not quite.
> 
> The system will suspend, but will resume immediately (because of an
> incoming key press interrupt, which are repeated when the key is held
> down).

Ah, I thought it won't even attempt to suspend while key is depressed.

> So, if Linux fabricates a key release event in the suspend
> handler, userspace would see two key release events: the fabricated
> one, and the one that comes from when the user later releases the key
> resulting in a break interrupt.  This would cause two characters to be
> printed on screen when the user only pressed the key once.

Input core will suppress the 2nd release though so I do not think that
userspace will see it.

Thanks.

-- 
Dmitry