On Mon, Oct 11, 2010 at 12:53:11PM -0400, Alan Stern wrote: > On Mon, 11 Oct 2010, Dmitry Torokhov wrote: > > > > > This means messing up with the currently set timeout. If userspace could > > > > have an option of "accelerating" expiring of the current timeout that > > > > would be better. > > > > > > Accelerating the expiration of the timeout _is_ a form of messing with > > > the currently-set timeout. It can't be "better". > > > > I was thinking about the case where timeout is user-supplied setting. > > Instead of having application store the original value, write 0, and > > later on restore it, I thought it would be better (as in simpler) to > > have a separate sysfs entry to "expire" the original timeout > > immediately. > > What you're suggesting can be added. For example, writing a blank line > to power/autosuspend_delay_ms could be defined to have this effect. > I'm not sure how beneficial it would turn out to be in the long run. > > > > Can you give any examples where "sticky off" is really useful (other > > > than just for debugging)? > > > > > > > A mobile device might have a set of keys that, once device is put into > > lower power mode, should not bring the device out of that mode. This I > > would call a "sticky off" case. > > But here the "sticky off" refers to the entire mobile device, not to > any particular driver. Where did I say that? The device is still running, playing your favorite song collection for example. Still you probably do not want your car keys compose and e-mail for you while you are jogging, thus the main keypad would be forced off. -- Dmitry -- 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
