Mike (mwester) wrote: > 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.
What's the status of this -- has this missing functionality been returned? >>> 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. Same question for this one. I know everyone on this list would like to see userspace adopt the new kernel; this will be a very visible regression for the users. > 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. > > Mike (mwester) Mike (mwester)
