[PATCH 2/2] input: make the Input Core be the last in the poller queue

[Sascha Hauer]

On Fri, Mar 04, 2016 at 01:18:08PM +0300, Aleksey Kuleshov wrote:
> Hi Sascha,
> 
> 04.03.2016, 10:19, "Sascha Hauer" <s.hauer at pengutronix.de>:
> > On Thu, Mar 03, 2016 at 06:17:10PM +0300, Aleksey Kuleshov wrote:
> >>  This prevents the case when Input Core and event providers
> >>  have to run "at one time" so Input Core will work with non-relevant
> >>  data since it will be called first.
> >>  ---
> >>   drivers/input/input.c | 3 ++-
> >>   1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > I tested the approach to add a .poll callback into struct input_device
> > and to let the input core register one poller for all input devices
> > rather than one poller for each device. This also gives the input core
> > better control when the input devices are polled. Would that approach go
> > into the right direction?
> 
> I don't understand the rules of "drivers/input/*".
> 
> All drivers register themselves as pollers? It seems yes.

Yes, currently they do. Since all drivers do this and all drivers *must*
do it as there is no interrupt support, this could equally well be done
by the input core instead of the drivers.

> 
> All drivers should be regular polled? No, because, for example, USB keyboard
> should be polled once per N ms.
> 
> All drivers could be polled per some-driver-specific N ms? Yes.
> For example, one USB keyboard asks for 10 ms, the other - for 5 ms.

That's some adhoc value. Could be 5ms, 10ms, there's probably no good
reason for one or the other. It must be somewhere between not-too-often
to not slow down barebox and not-too-seldom to not introduce noticable
delays in the reaction to the keys.

> 
> What about GPIO keyboards? Can they be polled once per N ms?
> It seems "why not?".
> 
> So we have some pollers with, for example, 5ms, 10ms and regular callings.
> Do you want to handle this inside the Input Core?

Yes, but all should have the same timeout.

> 
> --------------------------------
> Or may be it will be enough to poll every driver per 10 ms? Actually, why not?
> If that's the case, then your approach is in the right direction.

ok

> 
> Anyway, you will still have to do async call for repeating keys - and that's
> 400ms for the first press event, and then 40ms for subsuquent.
> 
> So, I guess, you will have two "poller_register" in Input Core (input.c):
> 1) for 10ms polling drivers - "driver poller";
> 2) for key repeating - "repeat poller".

Not necessarily. It could be one poller which does something like:

	if (is_timeout(last_time, 10 * MSECOND))
		/* Not too often */
		return;

	last_time = get_time_ns();

	for_each_input_device(idev) {
		if (status_changed(idev)) {
			/* first key press */
			idev->repeat_timeout = 400 * MSECOND;
			idev->repeat = get_time_ns();
			send_key(idev);
		} else if (is_timeout(idev->repeat, idev->repeat_timeout)) {
			/* repeat key press */
			send_key(idev);
			idev->repeat = get_time_ns();
		}
	}

> 
> Just make sure that "driver poller" registers first and after it you register "repeat poller".
> --------------------------------
> 
> 
> > I have no ready-to-post patch for this approach, partly because it doesn't
> > solve the double-return problem and I currently don't understand why.
> 
> The whole problem of double-return is here:
> 
> static void input_console_repeat(void *ctx)
> {
>         struct input_console *ic = ctx;
> 
>         if (ic->current_key) {
>                 kfifo_putc(ic->fifo, ic->current_key);
>                 poller_call_async(&ic->poller, 40 * MSECOND,
>                                   input_console_repeat, ic);
>         }
> }
> 
> This function is ASYNC. All what you have to do is to make sure that
> this function gets called AFTER all input-driver-providers will be polled.

I thought that aswell and thought I should have fixed this issue in my
patch, but it didn't work as expected so there's still something wrong,
either in my thoughts or in my implementation.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |