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

[Aleksey Kuleshov <rndfax@yandex.ru>]

Hi Sascha,

04.03.2016, 10:19, "Sascha Hauer" <s.hauer@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.

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.

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?

--------------------------------
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.

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".

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.
Or in other words make sure that the state is relevant when this function
gets called.
OR in other words there should be priority queue in which input_console_repeat
will have the lowest priority in respect to input-driver-providers.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox