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

Alan Stern
2010-10-11T16:53:11Z

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. In other words, it isn't a runtime-PM issue.

An example of runtime-PM "sticky off" would be a mouse that gets set to
low power and is forced to remain that way even when the user moves or
clicks it. I don't see how that would be useful.

Alan Stern