Re: Problem statement: Opportunistic suspend and i8042 wakeups

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
[off-list ref] wrote:

quoted

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.

quoted

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