Michael Trimarchi wrote: > is it a standard behavior having the reason but not having the event?
I think we're defining the standard here :-) I don't particularly care which way it's done, just that it's done consistently. And I really don't want a new config option :-) It seems that it would be slightly easier and cleaner for user space expecting an onkey event on resume to generate that from the wakeup reason than it would be for user space that doesn't want such an event to look at the wakeup reason and to suppress the next onkey event coming from the kernel. Is this assumption of mine true ? Or would it be excessively difficult to do this ? Another reason for not changing the current behaviour would be that existing code probably expects things to behave as they do. By the way, a general question about Android-specific API changes: how hard or easy is it for you to change Android's platform-specific glue code (or have someone else change it for you) ? Some of your patches try to make the kernel behave in a way that matches very specific expectations of user space, which seems to suggest that it's very difficult for you to change user space. Is this the case ? Or do you just generally prefer to change things in the kernel than in user space ? - Werner
