* Poll rate change and closing indication to polled input device
@ 2009-10-09 12:02 Onkalo Samu
2009-10-09 12:12 ` Mark Brown
0 siblings, 1 reply; 6+ messages in thread
From: Onkalo Samu @ 2009-10-09 12:02 UTC (permalink / raw)
To: linux-input
Hi
I would like to change the polling rate of the polled input device
on the fly depending on the use case. One possible way is to directly
modify poll_interval from my driver. However, I would like to introduce
functions which can be used to set / get polling rate like
input_polled_device_set_rate(...)
input_polled_device_get_rate(...)
Another missing thing is an indication when the polled device is closed.
This can be used to turn off the HW which is not used anymore.
What do you think, is it ok to introduce these additions to the polled
input device?
-Samu Onkalo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Poll rate change and closing indication to polled input device
2009-10-09 12:02 Poll rate change and closing indication to polled input device Onkalo Samu
@ 2009-10-09 12:12 ` Mark Brown
2009-10-09 16:27 ` Dmitry Torokhov
0 siblings, 1 reply; 6+ messages in thread
From: Mark Brown @ 2009-10-09 12:12 UTC (permalink / raw)
To: Onkalo Samu; +Cc: linux-input
On Fri, Oct 09, 2009 at 03:02:59PM +0300, Onkalo Samu wrote:
> I would like to change the polling rate of the polled input device
> on the fly depending on the use case. One possible way is to directly
> modify poll_interval from my driver. However, I would like to introduce
> functions which can be used to set / get polling rate like
> input_polled_device_set_rate(...)
> input_polled_device_get_rate(...)
> Another missing thing is an indication when the polled device is closed.
> This can be used to turn off the HW which is not used anymore.
> What do you think, is it ok to introduce these additions to the polled
> input device?
It'd be really good to have this control exposed to user space in a
standard fashion. Other devices that generate constant data rates like
touchscreens could also benefit from it, changing their output rate
depending on the needs of user space to give a power saving.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Poll rate change and closing indication to polled input device
2009-10-09 12:12 ` Mark Brown
@ 2009-10-09 16:27 ` Dmitry Torokhov
2009-10-09 18:10 ` Mark Brown
0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Torokhov @ 2009-10-09 16:27 UTC (permalink / raw)
To: Mark Brown; +Cc: Onkalo Samu, linux-input
On Fri, Oct 09, 2009 at 01:12:02PM +0100, Mark Brown wrote:
> On Fri, Oct 09, 2009 at 03:02:59PM +0300, Onkalo Samu wrote:
>
> > I would like to change the polling rate of the polled input device
> > on the fly depending on the use case. One possible way is to directly
> > modify poll_interval from my driver. However, I would like to introduce
> > functions which can be used to set / get polling rate like
>
> > input_polled_device_set_rate(...)
>
> > input_polled_device_get_rate(...)
>
> > Another missing thing is an indication when the polled device is closed.
> > This can be used to turn off the HW which is not used anymore.
>
The reason that this is missing is because polled devices are expected
to be extremely dumb. Since even many interrupt-driven devices can't be
shut off I did not expect that polled devices would need it.
> > What do you think, is it ok to introduce these additions to the polled
> > input device?
>
> It'd be really good to have this control exposed to user space in a
> standard fashion.
I'll take the patches.
> Other devices that generate constant data rates like
> touchscreens could also benefit from it, changing their output rate
> depending on the needs of user space to give a power saving.
Not sure if this belongs to the input core as such. It seems that what
you want here is dynamic power-management which works on the level below
input core (individual devices on particular buses).
--
Dmitry
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Poll rate change and closing indication to polled input device
2009-10-09 16:27 ` Dmitry Torokhov
@ 2009-10-09 18:10 ` Mark Brown
2009-10-13 1:08 ` Dmitry Torokhov
0 siblings, 1 reply; 6+ messages in thread
From: Mark Brown @ 2009-10-09 18:10 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Onkalo Samu, linux-input
On Fri, Oct 09, 2009 at 09:27:18AM -0700, Dmitry Torokhov wrote:
> On Fri, Oct 09, 2009 at 01:12:02PM +0100, Mark Brown wrote:
> > It'd be really good to have this control exposed to user space in a
> > standard fashion.
> I'll take the patches.
Yes, I was planning on doing some - I've got a touchscreen driver to do
soon and was hoping to have time to look at this while working on that
driver.
> > Other devices that generate constant data rates like
> > touchscreens could also benefit from it, changing their output rate
> > depending on the needs of user space to give a power saving.
> Not sure if this belongs to the input core as such. It seems that what
> you want here is dynamic power-management which works on the level below
> input core (individual devices on particular buses).
It definitely needs to be implemented in the drivers but they need to
present an interface to userspace which seems best placed in the core to
factor out code and help make sure that the interface is standardised.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Poll rate change and closing indication to polled input device
2009-10-09 18:10 ` Mark Brown
@ 2009-10-13 1:08 ` Dmitry Torokhov
2009-10-13 9:19 ` Mark Brown
0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Torokhov @ 2009-10-13 1:08 UTC (permalink / raw)
To: Mark Brown; +Cc: Onkalo Samu, linux-input
On Fri, Oct 09, 2009 at 07:10:12PM +0100, Mark Brown wrote:
> On Fri, Oct 09, 2009 at 09:27:18AM -0700, Dmitry Torokhov wrote:
> > On Fri, Oct 09, 2009 at 01:12:02PM +0100, Mark Brown wrote:
>
> > > It'd be really good to have this control exposed to user space in a
> > > standard fashion.
>
> > I'll take the patches.
>
> Yes, I was planning on doing some - I've got a touchscreen driver to do
> soon and was hoping to have time to look at this while working on that
> driver.
>
> > > Other devices that generate constant data rates like
> > > touchscreens could also benefit from it, changing their output rate
> > > depending on the needs of user space to give a power saving.
>
> > Not sure if this belongs to the input core as such. It seems that what
> > you want here is dynamic power-management which works on the level below
> > input core (individual devices on particular buses).
>
> It definitely needs to be implemented in the drivers but they need to
> present an interface to userspace which seems best placed in the core to
> factor out code and help make sure that the interface is standardised.
It seems to me that this kind of functionality belongs to PM core.
Userspace probably does not really care about output rate and other
details but rather wants to putsome devices into a low power mode in
general.
--
Dmitry
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Poll rate change and closing indication to polled input device
2009-10-13 1:08 ` Dmitry Torokhov
@ 2009-10-13 9:19 ` Mark Brown
0 siblings, 0 replies; 6+ messages in thread
From: Mark Brown @ 2009-10-13 9:19 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Onkalo Samu, linux-input
On Mon, Oct 12, 2009 at 06:08:42PM -0700, Dmitry Torokhov wrote:
> On Fri, Oct 09, 2009 at 07:10:12PM +0100, Mark Brown wrote:
> > It definitely needs to be implemented in the drivers but they need to
> > present an interface to userspace which seems best placed in the core to
> > factor out code and help make sure that the interface is standardised.
> It seems to me that this kind of functionality belongs to PM core.
> Userspace probably does not really care about output rate and other
> details but rather wants to putsome devices into a low power mode in
> general.
That's useful as well and having this doesn't preclude other forms of
runtime power management but there is also value in this kind of
subsystem specific control too.
In the case of touchscreens we should be able to get some useful
information out of userspace - applications like handwriting recognition
will want 150-200 samples/second but for something like a finger
operated menu 10-20 samples/second will be enough. This should result
in a win, especially bearing in mind that each point is going to
translate into a wakeup for the application layer, and also reduces the
amount of manual tuning that might be required.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-10-13 9:20 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-09 12:02 Poll rate change and closing indication to polled input device Onkalo Samu
2009-10-09 12:12 ` Mark Brown
2009-10-09 16:27 ` Dmitry Torokhov
2009-10-09 18:10 ` Mark Brown
2009-10-13 1:08 ` Dmitry Torokhov
2009-10-13 9:19 ` Mark Brown
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.