[RFC patch pcf50633-core] Android resume on one click patch

[Michael Trimarchi]

Hi,

Werner Almesberger wrote:
> 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.
>   
What do you thing about this type of change? (the code is not tested):
/* Make sure we don't pass on any ONKEY events to
 * userspace now */
 pcf_int[1] &= ~(PCF50633_INT2_ONKEYR | PCF50633_INT2_ONKEYF);

/* generate a userspace notification */
sysfs_notify(&pcf->dev->kobj, NULL, "resume_reason");

This not change the beahvior but notify the change to the userspace.

> 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.
>   
I don't know sorry.
> 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 ?
>   
The problem is that the android platform is designed around a specific
android kernel part. Each part during resume, consume the event on the 
device
and acquire the wake lock. If the resume is a sporadic resume the system 
go to sleep
again. It can be possible rewrite the resume/suspend part in a hardware 
abstraction
layer and put this patch in the official openmoko kernel is not 
necessary, but now
give the possibility to the user-programmer to find better solution and 
other
people to use the phone now.
> Or do you just generally prefer to change things in the kernel than
> in user space ?
>   
Well, I think that if the kernel does the right thing the userspace must 
change.
> - Werner
>
>   
Michael