On Mon, 30 Nov 2009, Ferenc Wagner wrote: > > Just out of curiosity, how do you decide when the input should be > > muted and unmuted? > > That's application logic. For example, the user touches the "Lock" > button, then slips the gadget into his pocket. Then most other buttons > (like volume control) are muted until the device is unlocked again by > some very specific action. My mobile phone doesn't work like this, it > reacts to each button even when it's locked (though of course does > nothing but says how to unlock it). Okay. This wasn't clear to me before. > Well, I thought runtime PM is intended to have some "common sense" > semantics, so it can be automatic. After all, it's perfectly reasonable > for somebody else to want the "normal" runtime PM for gpio-keys: to > autosuspend when not in use. If we stole the callbacks for our purpose, > the "expected" behaviour couldn't be implemented later. In other words, > the wanted behaviour is not device specific, but usage specific. And > the runtime suspend behaviour of a device can't be usage specific, it > should match common expectations (to the extent it's possible to talk > about common expectations wrt. runtime PM -- but you may still want to > build one up). Are these fears unfounded? Is runtime PM not what I > think it is? No, you are right. Runtime PM is not well suited for this purpose. Alan Stern -- 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
