[UPSTREAM 0/2] pcf50633 changes
mwester at dls.net
Sun Nov 16 23:57:13 CET 2008
Werner Almesberger wrote:
> Balaji Rao wrote:
>> 4. Emergency 8s shutdown has been temporarily removed from the driver
>> as it certainly does not belong there.
> What's the plan for this one ? Lots of people seem to feel a strong
> emotionally attachment to having the equivalent of ctrl-alt-del :)
I'm rather concerned; it's all too easy to have this functionality get
lost in the shuffle if it's not implemented up front.
>> 5. 'Suppress onkey events on resume' - must be a better way to handle
>> this. Can't it be done from userspace ?
> It seems that whoever has initiated the suspend should also take care
> of the consequences, yes. This is only about user space, not the
> hang-on-resume Matt has fixed recently, right ?
This is the use-case where something initiated a suspend, and the user
depressed the power key to awaken the device. In order to do this in
user-space, someone will need to devise a fool-proof algorithm for
user-space that can ensure that whatever process reads the power key
event can distinguish between a power-key event that is real versus a
power key event that is to be ignored, because it was just the remnants
of the wake event.
I rather suspect that the algorithm to do that will need to know the
wake reason (which is yet to be implemented, according to Balaji's email).
The big problem I see with leaving this to user space is that it means
that we need to track down every bit of user-space code that might ever
read the onkey event, and add logic to that code to inspect the wake
reason and decide if the event is to be ignored. Besides, it just
"feels wrong" -- the button push was to wake up the hardware and nothing
more; since the user is not intending to signal anything to user space,
it just seems rational to have the kernel suppress that event after it
has done its job. Other wise it's just a spurious event from the point
of view of an application.
More information about the openmoko-kernel