Re: [RFC] input: syfs switches for SKE keypad

Dmitry Torokhov
2010-10-11T17:07:33Z

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