Hi, Thanks for not getting bored of this :) On Mon, Oct 10, 2011 at 9:38 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> 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). 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. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
